I am currently working for Spreadshirt in the role of a Performance Engineer and we recently released a new version of our marketplace. Currently, we are trying to identify things we can further improve and in order to do that I run a couple of tests with WebpageTest on our pages to get metrics that describe the current state.
In general, I run 5 tests per test with Chrome browser and Cable from the Dulles, VA - Thinkpad T430 location. I also made a copy of our live list page that runs without Javascript and can be found here [b]https://www.spreadshirt.de/Public/esi/ump-list-progressive-jpg.php[/b].
The problem with the WebpageTest result is that the Start Render time for the 5 tests I make toggles between 1 and 2.5 seconds which make the test result not very reliable ([url=http://www.webpagetest.org/result/160718_EY_1AEP/]http://www.webpagetest.org/result/160718_EY_1AEP/[/url]). When running the same test with Firefox, IE11 or Safari I get a pretty consistent Start Render time around 1 second ([url=http://www.webpagetest.org/result/160718_4G_1A0Y/]http://www.webpagetest.org/result/160718_4G_1A0Y/[/url]).
Has someone an idea on why the Start Render time toggles in Chrome? Is this a problem related to my page or is this a problem with Chrome in general? Any ideas?
If you go to the “Chrome” tab in the advanced settings you can capture a dev tools timeline which would give some visibility into what Chrome is doing right before the delayed start render which might provide visibility into what is going on.
If that doesn’t provide enough detail you can also capture a trace but that’s more for people to look at the internal Chrome processing and is geared more towards chrome developers themselves. That said, if you can run a test with multiple runs and timeline (or tracing) enabled and reproduce both fast and slow start renders I’d recommend opening a Chrome bug at crbug.com with a link to the results.
I did run the tests again as you said and enabled the “capture dev tools timeline” feature [url=http://www.webpagetest.org/result/160720_13_1W5F/]http://www.webpagetest.org/result/160720_13_1W5F/[/url]. What I can see now is that the difference between Start Render firing after 1 second or 2.5 seconds is that Layout and Parse HTML simply takes a lot longer. I have the same behaviour on the Repeat View.
Can this problem be related to the 48 images I have on the page and the decompression of those that interferes with the actual parsing of the HTML?
I will create a new test page with 12 images on it instead of the 48 ones and see whether this one runs more stable. There is one special thing about the page: We use http/2. Can this be the reason?
Things that now seem to randomly block paints:
[list]
[]Asynchronously loaded/Deferred JavaScript
[]Pre-rendering
[]Deferred CSS (even with RequestAnimationFrame)
[]Analytics, including asynchronously loaded G.A.
[]Images that shouldn’t
[]Fonts that shouldn’t, including TypeKit and Google Fonts asynchronously loaded with the WebFont Loader
[/list]
I see no pattern, really. As I understand it, Chrome runs its own experiments(?). Perhaps it is now self-aware lol.
thanks for your answer. The list of things you provided that might block paints randomly is pretty interesting. Will have a closer look at that and conduct a couple of more tests. We do have embedded a Google font for example.
Anyway, I conducted a test with 12 images on the page instead of 48 images and have similar symptoms [url=http://www.webpagetest.org/result/160722_33_CYH/]http://www.webpagetest.org/result/160722_33_CYH/[/url]. So this is probably not it (means bandwidth, cpu usage, image decoding, …).
Will create a simple test page with the 12 images from scratch now without any Javascript, CSS, Fonts etc. and work my way through it step-by-step.
version with images but no other resource, with head and foot removed and with further markup reduced and markup bugs fixed does not have the problem and start render starts really as expected [url=http://www.webpagetest.org/result/160726_HR_KKB/]http://www.webpagetest.org/result/160726_HR_KKB/[/url]
So this problem must be somehow related to our head or foot or something funky in our markup. Strange!