Discrepancy In Page Load Time On GTmetrix Tests
I am facing a big discrepancy in load times on my website tests, sometimes it says that it takes 5 secs to fully load, and if I retest it says that it takes 25 secs to load. I didnt make any changes in the website whiles testing.
Also got some different results in other tools (I know it may vary from some tools to another (one checks fully load times, other checks initial load times etc) but i will leave the links below in case it helps):
Essentially, as I am not an expert on analysing those datas and insights from gtmetrx, I want to know why this discrepancy is happening on GTmetrix, since I dont make changes in the websites or in the tests parameters. Sometimes I also notice this loading time difference while reloading the website in my browser. Whats wrong with my website? Is there any "corrupted" file or request that I cant see?
I appreciate any kind of help Thanks in advance
Looking at the waterfall tab on the two GT Metrix archives you shared, the first big difference that I noticed is on the file
rt.application.scss.css - on the slow load, this file was
waiting for roughly 6.5 seconds
.scss files into regular
.css files, so my initial suspicion is that the file is set up inefficiently and that Shopify caches the results for some amount of time. The quick loads would be Shopify serving you a cached file, the slow loads would be Shopify needing to rebuild the file because its internal cache had expired.
rt.application.scss.liquid) file in your assets folder is huge, you may want to try making it more efficient (note: the file in 'Assets' will not include the
.css ending. If the file has a
.liquid ending it means Shopify needs to parse liquid code when it builds the file, but
.liquid will not be included in the final file name).
Shopify's parser needs to apply any liquid code (if the file has a
.liquid ending) and then convert from
.scss format to regular
.css code. If you're comfortable working with either or both of these syntaxes, you could try paring down the file to see if that helps.
You could also look at the parsed contents of the rendered css file (https://cdn.shopify.com/s/files/1/0076/6931/7690/t/10/assets/rt.application.scss.css?8094593948347511375) and save the contents of that file to a separate CSS file, then use that file instead of the dynamic one. If this really is the primary culprit, you should see that your page test times become more consistent.
More generally, when looking at your GT Metrix results, you can use the waterfall view to look for any loading bars that seem excessively long compared to other files. Files with long waiting times (coded purple) indicate that Shopify is the source of the delay, probably because of a file that's fairly server-intensive. Long receiving times would mean that the file is itself quite large and could possible be compressed or reduced.
Hope this helps!
- → should I choose reactjs+f7 or f7+vue.js?
- → dynamic php title depends on page id and using of "if (isset"
- → JSPerf, For Loop vs While Loop
- → Performance issue for inline ALL styles in React.jS?
- → More performant way of sorting by selected first
- → Fastest way to find a value inside a multi-dimensional array?
- → How to convert all css links in inline styles using smarty - seo speed optimization
- → Using ReactDOM.render inside an event handler to avoid rendering expensive components
- → Blackfire instantly fails when I have JMeter running
- → Is alt the same as alt=""?