Dag Kristof;
It’s all a question of what KPI’s you focus on, but in general I advise against “fully loaded” and prefer “onLoad” (load time), First Contentful
Paint and Speed index (or Last Painted Hero).
Reason; goal should be for a page to start rendering and for it to “look” finished asap. Time used to render invisible resources (as below the fold or without visual impact) is included in “fully loaded” but from a user experience pov it is pretty irrelevant.
Now to be able to comment what your are describing I would need to see the result URL’s of 2 (or more) multi-run (3 test runs minimum, 5 or more preferred) tests on webpagetest.org and compare the different KPI’s.
Groeten uit het Ledehof in Lokeren 😉
Frank
Dag Frank,
Thank you for responding so quickly!
I agree with your vision that Load Time is more important than Fully Loaded.
I have done tests with each time 5 runs, these are the Load Times.
Without plugin 2.952s
With plugin All Settings Off 2.911s
Optimize JavaScript Code – Aggregate JS-files OFF 2.058s
Optimize JavaScript Code – Aggregate JS-files ON 2.076s
Optimize CSS Code – Aggregate CSS-files ON 2.025s
Optimize CSS Code – Also aggregate inline CSS? 1.951s
Optimize HTML Code 1.775s
Lazy Loading 1.881s
Lazy Loading OFF again –
Google Fonts – Combine and link in head 1.877s
Google Fonts – Combine and preload in head 1.968s
and First Contentful Paint
Without plugin –
With plugin All Settings Off 1.515s
Optimize JavaScript Code – Aggregate JS-files OFF 1.376s
Optimize JavaScript Code – Aggregate JS-files ON 1.346s
Optimize CSS Code – Aggregate CSS-files ON 1.310s
Optimize CSS Code – Also aggregate inline CSS? 1..155s
Optimize HTML Code 1.075s
Lazy Loading 1.242s
Lazy Loading OFF again
Google Fonts – Combine and link in head 1.279s
Google Fonts – Combine and preload in head 1.082s
Groetjes uit Windhaarstraat Lokeren
Can you share the result URL’s instead Kristof, easier when I have all details 🙂
So went down the rabbit-hole and through all the numbers (mainly comparing the 2 last ones) the only thing I can think of is that due to the low number of images you’re not seeing any improvement and that due to the fact that there is some overhead in lazyloading (loading lazysizes + parsing & executing the JS) you indeed have some KPI’s that indicate not lazyloading is better (although the speedindex seems somewhat better when lazyload is active).
All in all, based on all of this you might indeed be better off without lazyloading, except if you have pages where more images are (or will be) used, in which case you might want to test that scenario as well.
frank
Hi Frank,
Thank you for taking the time to dig deep. If will keep Lazy Loading off then.
One last question, do you have any thoughts on why I was unable to get the same speed results as I had before I turned on Lazy Loading? As you can see, the last few test are a bit slower then this one https://www.webpagetest.org/result/190903_MM_950436996434a74ad20a9cfd7ef09178/
I have cleared all caches, but that did not help. No other settings were changed.
well, if lazyload is off then all should be as before, but not “a bit slower” (or “a bit faster”) might not be statistically relevant + there are also external factors might impact results (load on the server, load on the wpt testnode, network conditions, …). so if just a bit slower I think you can safely ignore.
True!
I just disabled “Also aggregate inline CSS” and now I am back to
Document Complete 1.712s // 16 requests // Page Size 617 KB
Best result yet.
nice!
maybe have a look at “inline & defer CSS”, which can help reduce the first paint/ start render times 🙂
