Some of the parameters/ scores make relevance(or need to be prioritised ) depending on your app and its purpose. If you are using your meteor app site as a means of customer conversion or stickiness then yes quick loading is important otherwise they may loose interest.
In other words take a call based on your end goal. This does not mean performance is not important, it is upto you to decide which parameter your end user looks for and focus on it.
I found the link responsive and it seems fine. But then performance depends on so many other things and they change over a period of time.
Meteor Framework itself brings its constraint so focus on solving that is possible to be solved. And not all things have to be done on day one.
Also, note gtmetrix server is based out of Canada, not sure where your server is …it will add to latency.
Using bundle-visualizer I just managed to find a serious problem with react-icon, which made the packaged file shrink by 40% and reduced its speed by 1 second for the first opening and 600 milliseconds for the second opening
However, I also have a problem to solve, using the above code, SSR function is invalid, SSR is not supported, according to the @nathanschwarz prompt, do not use react on the server side, but I do not understand, has not been successful
First of all, you should run bundle visualizermeteor --extra-packages bundle-visualizer --production and go to http://localhost:3000 to understand what exactly should be extracted from main js bundle.
Probably your ../../Routes/Routes file contains many imports, which can be dynamically loaded.
The second improvement which we’r now implementing - cut off React+React-dom from the main bundle and load it after DOM ready.
Lets see example, based on your code.
I move your code from project_name/client/index.jsx(maybe another file, IDK) to project_name/client/react.jsx;
project_name/client/react.jsx:
import React from 'react';
import {render} from 'react-dom';
import {BrowserRouter as Router} from "react-router-dom";
import {HelmetProvider} from 'react-helmet-async';
import Routes from "../../Routes/Routes";
const helmetContext = {};
render(
<HelmetProvider context={helmetContext}>
<Router>
<Routes/>
</Router>
</HelmetProvider>
,
document.getElementById('App')
);
Rename index.jsx → index.js and add a new code:
import { Meteor } from 'meteor/meteor';
// Custom splash screen/loading indicator
// You can use css animation, more complex HTML etc.
const splashScreen = document.createElement('div');
splashScreen = `Loading...`;
const showSplashScreen = () => {
document.body.appendChild(splashScreen);
}
const hideSplashScreen = () => {
document.body.removeChild(splashScreen);
}
Meteor.startup(async () => {
showSplashScreen(); //also we can call it in DOMContentLoaded event
await import('./react.jsx'); //import our react's stuff dynamically
hideSplashScreen(); //hide loading indicator
});
react-dom should be removed from the main bundle after these changes. If not - it means that some meteor package uses it and should be lazy loaded, as I described above.
To understand my approach, I suggest to create an empty project and try to improve the bundle size.
For our project, we expect that bundle size should be 400-500kb after such optimisation, and our routes file with react-dom - another 200-300kb.
I followed exactly this example, but it did not change.
I checked the packages, packages like react-bootstrap and ostrio: files are relatively large.
Now exactly how can I implement them with lazy?
As I understand it, I do not have to do anything special, but that package must take the necessary measures.
Thank you for explaining on a package with an example
I need an example and a full explanation about lazy.
How is it used in different packages?
How exactly should I start?
An example and explanation that can clarify the issue.
From what I’ve read so far it seems that people are getting relaxed with around 1.4-1.5MB and less, but there is no established hard limit.
Also mind that there is a related problem in Meteor, the bundled css. All css/scss that is not explicitly imported gets compiled into the css bundle, meaning that if you don’t import any, all of your css/scss get compiled into this bundle. It is then referenced in your main.html's <head> section via a <link> tag.
The problem with that is that such a css reference represents a blocking resource, which will ultimately delay the client app’s startup, thus adding to the time until FCP, First Contentful Paint, and, maybe even more importantly the LCP, Largest Contentful Paint. This is bad for SEO and should be taken very seriously since the introduction of Google’s Web Vitals.
LCP (largest contentful paint): The amount of time to render the largest content element visible in the viewport, from when the user requests the URL. The largest element is typically an image or video, or perhaps a large block-level text element. This is important because it tells the reader that the URL is actually loading.
Currently the website is on Heroku, which comes with a machine having 512 MB ram, but not sure which parameter will get improvement in case I would change the RAM of the machine, please let me know if this would many any difference
Regarding Reduce initial load time, here I observed that all the package we have in packages (inside the .meteor folder) combines and give us one single file. Is there any approach we can decide whether we want a particular package on a page?
@mixmatric
The strategy of increasing RAM and CPU does not work.
I tried many times, it does not have much effect.
Of course I use prerender and nginx proxies it.
I’m not exactly sure if prerender might not work well.