I really don’t get why now ~400ms is spend between downloaded the page and the start of rendering it, especially with a tiny amount of inline CSS and a page size of just 3.23kb. If anything, I’d expect the gap between load and start render to shrink (and not increase).
[quote=“clubberz, post:3, topic:10334”]
I’m not sure why you would want to optimize the site that much as those improvements won’t be noticeable to end users. Unless it’s just an exercise for it’s own sake.[/quote]
That’s true, it’s more like a hobby and challenge for me than anything else. Plus I want to get at least as good of a performance when I started implementing speed tweaks, because otherwise the additional work (like creating image sprites) doesn’t need to be done in the future.
[quote=“clubberz, post:3, topic:10334”]
It’s best to run a few tests (at least 3) to get an overall picture, as there will always be some variability.[/quote]
Thanks, I’ll take that more into consideration.
Yesterday I’ve already tested different ways to load JS (async, defer, or DOM script injection) but performance didn’t seem to differ much.
I’ve just tested inlining all CSS versus putting all CSS in a separate file. I don’t see much differences; the first five bars are with CSS inline, the last 5 are the results for putting the CSS in a separate file.
The worst performance when inlining all CSS is as worse as putting all CSS in a separate file. And the typical performance difference seems to be in the tens of milliseconds. If it wasn’t for that single orange bar that showed good performance when inlining all CSS, I’d say the performance doesn’t matter for the webpage I tested.
What are your thoughts on choosing which webperformance to use when the results are virtually identical?
That’s probably true, but I host Google Analytics locally so that I can set it a caching higher than 2 hours, which is something that Google Pagespeed would otherwise complain about. I agree that normal website visitors don’t notice performance benefits from this (and likely already have it in their browser cache), but am not sure how search engines look upon that (i.e., the Pagespeed score).
I didn’t even know about that graph. Thanks for sharing that. There’s still something blocking the rendering can you:
Move the async js to the footer before the closing html tag (there’s so little of this you could actually inline this and the css file)
Remove the data-uris for images and set the data-src to src for the images. Chrome will download the elements it think it needs when it first receives the html file. In this case the image src links are being added via js so are being downloaded later in the waterfall. Hence why the images load after the js file and not in parallel.
Change the connection speed to FIOS to see what the time would be like on a fast connection.
I wouldn’t worry about the PageSpeed Insights score, it’s not directly related to the load time eg a higher score doesn’t mean it’s faster nor does it relate to SEO. It doesn’t take into account the performance benefits of http/2 either at the moment. It’s just suggestions on what could be slowing down your site, better to analyse the waterfall instead to see the load impact of each resource.
Thanks for your reply. I’ve removed the data-uris for the images, but I’m a bit on the fence how much this helped, also because the effect of cache MISS is bigger now for images. But the effect might be cumulative once I change the JS code delivery.
However, if I should summarise this topic in one question it will be: how to get the start render time before the load time?
(It’s of course debatable how bad it is that a user has to wait 1 second before the blank page starts showing something, but I’d like to get the start render time around or before the load time.)
I’m getting a bit confused here.
I learned here that the domContentLoaded event happens when both the DOM and CCSOM are ready. My domContentLoaded happens at 0.302s and domInteractive occurs at the same time.
The DOM and CCSOM are then combined into the render tree, whose layout is then painted on the screen.
Does that mean that my tiny inline CSS and small HTML page take almost 0.7 seconds to render (start render time - domContentLoaded)? That’s very long, especially since this webpagetest was performed on a desktop browser (mobile would be much slower to process, I figure).
Thank you very much for this comment! It really helped me to put things into perspective; I was too tied up in using that testing location and considering the webpagetest results as “the truth”.
After seeing that test result I’ve become a bit more sceptical of the webpagetest results (in other words, not relying on it too much) and made a couple of website changes:
No more hosting of Google analytics locally (like mentioned earlier in this thread).
No more JS file that’s loaded deferred, but load the JS async now (for earlier fetching). (I found that the start render time is really held up by the CSS and HTML itself, not the JS so I might as well load it async without script injection.)
Removed one JS file and the JSON request.
Put all CSS in one file that’s referenced externally.
I know that latter is not the very best approach, since inlining the CSS would/should give better performance for the first page view. However, when I look at the load time of the CSS file and the small amount of CSS that I’d otherwise defer loaded, I estimate that this costs around 75-100ms of the initial page load.
I could optimize that further, but with that small benefit I’d rather have the CSS external for better browser caching: my pages have a browser cache of 30 minutes, while my CSS is cached in the visitors browser for 6 months.
My remaining question: Is there an optimisation I have overlooked so far? I’d of course would still like to improve the start render time if that’s possible, but I feel that I checked most boxes (that I can influence) even though Webpagetest doesn’t agree yet.