I made a static version of a Wordpress page, which has fewer requests, a smaller overall size, and a lower time to first byte than the original. It’s hosted on a Cloudflare Worker. It loads faster on webpagetest.org and in other tests.
New page: WebPageTest - Running web page performance and optimization tests...
Original page: WebPageTest - Running web page performance and optimization tests...
In the Google Analytics Page Timings section, Avg. Document Interactive Time and Avg. Document Content Loaded Time went down significantly and stayed down for the new page.
But the Avg. Page Load Time actually went UP after implementing this page. This is with more than a month of data, 300-400 page timings per day, no data sampling. (About 6.25 seconds to load on the old version, 7.5 seconds to load on the new version.)
There seems to be a huge variance from day to day in Avg. Page Load Times. One day, on iOS the page may take 35 seconds to load on average. Another day, the same might happen for non-iOS mobile devices. In general, huge ups and downs, with the ups increasing the average.
How come average page load time did not go down, despite having a much smaller page?
1 Like
I have similar weirdness in my Google Analytics page speed section. I think it is because a few bad outlier results have a much bigger effect on the averages for low traffic pages (300 views/day).
Those bad outlier times may be coming from distant countries, or from a few users on really slow connections, or from a few users with really outdated weak devices.
Maybe try segmenting the results by device or location to see if you can spot the outlier sources?
1 Like
If your new page does have lower Document Interactive Time (and lower DOM Content loaded time), then you know the page is performing faster, but some of your later loading assets are taking their sweet time. So the HTML itself and content itself is pretty fast… but what comes after that content?
I noticed the waterfall on your new page is still very staggered going from top left to bottom right like a staircase. Not much parallelization. I see that most of the 2nd half of your waterfall is all marketing/tracking stuff. Google Analytics, Google Ads, Google Audiences… also noticed you had Google Tag Manager up above. So you have at least 4 tracking things going on.
So my guess is visually the site is performing ok (document interactive time you mentioned) and that all this tracking and marketing stuff is dragging out particularly on slower devices. You might try running the webpage tests on some resource constrained devices to see what it does to the CPU/connection saturation. It looks like the cpu utilization is relatively high throughout all that tracking code on a standard test (so put it on a small arm processor and it may choke up more and cause further delays).
Then can decide after further testing whether you want to analyze further and improve or if the site is ok for you. You have to decide if you really need all the tracking, or only some of it. Can you defer some portions? Change the priority order? Do you really need GoogleTagManager? etc…
1 Like