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
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
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?
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.