Optimizing the Critical Rendering Path for Instant Mobile Websites - Velocity SC - 2013
Vložit
- čas přidán 17. 07. 2013
- Slides @ bit.ly/mobilecrp
Users expect a fast and optimized experience regardless of whether they're on a mobile or desktop browser -- rightfully so! However, delivering instant mobile websites requires careful engineering: you need to account for every extra network roundtrip, tune your servers, and prioritize critical assets -- aka, we need to optimize the critical rendering path to deliver best visual rendering performance.
In this session we'll take a deep dive into the technical design and optimization criteria to help us meet these goals. As a bonus, we'll demo some existing and upcoming tools we've been working on at Google to automate the process. - Věda a technologie
*Optimizing the Critical Rendering Path (CRP)...* aka, what it takes to build fast mobile sites! A presentation Dave Mankoff and myself gave at Velocity a few weeks back. Slides: bit.ly/mobilecrp
As a bonus, Dave demoed the upcoming PageSpeed Insights tool (which we'll be releasing very soon) which will help you diagnose your own sites!
Let us know what you think, or if you have any questions...
very nice presentation at Velocity!.
When you are in an audit (@31:07) how did you get the file sizes to show up? I have the number of rules unused and the percentage, but no sizes in kb. I have tried both stable and canary.
James King doh, nice catch. It looks like we dropped the kb metric!
Ilya Grigorik 301 server-side redirect have to go back through the network?
whats the recommendation for people with fully sites? For Nginx the recommendation is to use 301 redirect.
Yes, this may be three+ years old, but still an eye opener to me. I'll have to play around with this ATF concept.
That's true, the focus here is on optimizing the time to first (cold) render. However, the 'cold cache' scenario is the harder of the two - anything you do to improve this case will automatically benefit the 'warm cache' case. As such, there really is no need for separate criteria...
Visual progress is equally important for cold and warm caches, and there is no such thing as "painting too early" - I wish that was a thing! :) ... PLT is the wrong metric to optimize for. Historically, that's all we've had so we had to go with it, but now's the time to start fixing that.
thanks guys , understood now what really matters
Speed Index / visual progress are not "speculative: both are measuring the number of painted pixels on the screen (as compared to final outcome). As such, they're actually a better metric - e.g. consider a page which is blank for 3 seconds and then paints everything at once, vs a page that paints 80% of the pixels at 1s and then remainder at 3s.
Re, pagespeed: no, we would have to look at the metics. Note that critical css is an optional filter, so make sure you enable that in comparisons.
There is a lot of great existing UX research on what "slow" means. Search for Nielsen's "Response Times: The 3 Important Limits" for one of the better examples -- while individual perception varies, the orders of magnitude are reliable and consistent constants.
There actually are real world cases where we must consider 'Painting early' vs. not delaying content, as tradeoff. Loading scripts 'async' in the 'head' will likely delay 'painting' by def., yet by loading them early, external assets will load much faster. e.g. webpagetest result: 130721_7B_40c1a1db8caa4e953448f2a448f738f9 The FB btns load faster for the original, despite a small initial paint delay. The optimized waterfall does not even consider the FB button as content because it delayed it.
Ok. It makes sense from a blank page and especially a 'cold cache'. But for subsequent page views the visual progress is much less of a perception issue.
Painting too early at the expense of delaying external additional content (e.g. social buttons, videos, ads) and therefore delaying Load Time with 'late painting', can also be perceived 'slow'. Perception vs. actual speed being debatable. But in some cases delaying paint some 500ms-1s in order to gain 1-2s on the Load Time can also be good.
The 'optimized by PageSpeed Service' comparison is nice. But it could be misleading...
While the 'visual progress' or the 'speed index' can show significant speculative benchmark improvements, isn't the 'visually complete' timing what ultimately counts?
In my case, my original performs a tiny bit better that the fully optimized version.
Would it be fair to say that, in such case, the website should already be considered sufficiently optimized as implemented, despite the visual progress diff?
It seems to me that you have solely focused on first-time/empty-cache visitors?
Will there be a Pagespeed option to measure performance using a primed cache? - To test performance of visits to subsequent pages?
So if you are able to create a page that contains everything it needs, and it compresses to something less than the 14KB first trip limit -- it is best to place all coding into the page (CSS, js, etc.)? Not necessarily practical, but the answer could help wrap my head around this.
Yep, one page, inlined -- that'll deliver the fastest time to first render.
Ilya, it would be interesting to know how the goalposts have moved for today. Is 14 KB still relevant or is it higher, etc?
And there are no comprehensive study/consensus as to what the majority perceive as slow AFAIK. How can you say that it's the wrong metric? e.g. Look at the comments of S. Souders' article "The Perception of Speed". Personally when the ext. content takes forever to load and keeps re-painting with jittering content for a few more seconds, I consider that as slow lagging pages because it feels like I still have to wait. I take here a middle ground approach between 1st paint and visually complete.
I tested the Silverton Casino website and it didn't perform well at all, 37/100 on mobile and 40/100 on desktop.
Ilya Grigorik I understood all you said. I am stuck with a question - stackoverflow.com/q/24751153/731963. I am not able to match CRP with whats happening in my example. Can you help ?