Navigating the critical rendering path - Jamie Alberico - VirtuaCon
•
0 likes•115 views
What happens when you combine Mobile First Index, Performance, and JavaScript? You find the critical rendering path. This talk will look at how these 3 major components of search can guide your strategy and tactical ways to improve them.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Navigating the critical rendering path - Jamie Alberico - VirtuaCon
Similar to Navigating the critical rendering path - Jamie Alberico - VirtuaCon (20)
Recently uploaded
Recently uploaded (12)
Navigating the critical rendering path - Jamie Alberico - VirtuaCon
- 1. Navigating the Critical Rendering Path Jamie Alberico | @Jammer_Volts
- 2. This talk is for you if: ● Your site has been switched to mobile first index ● Your site uses JavaScript ● Performance is a ranking factor for your site ● You’d like users to convert
- 3. This talk is from me if: ● I’m Jamie Alberico ● I’m Not a Robot (but I speak bot) ● I’m notorious for blue hair & tech SEO ● You wanna play D&D sometime
- 4. What we'll cover today What is CRP? How to measure CRP Optimizing CRP
- 5. What is the Critical Rendering Path?
- 7. The Critical Rendering Path is the steps a browser has to take to get the content a user has asked for on the screen.
- 8. Basically we’re talking about our already beloved Above the Fold content.
- 9. User Screen Content It’s a simple formula
- 10. What we think it’ll be like.
- 11. What it’s actually like.
- 12. Let’s Build It! 1. Document Object Model(DOM) 2. CSS object model(CSSOM) 3. Render Tree 4. Layout 5. Paint.
- 13. DOM HTML HTML Parser DOM Tree Step 1: Document Object Model(DOM)
- 14. Output
- 15. DOM HTML Style Sheets HTML Parser CSS Parser DOM Tree Style Rules Attachment Step 2: CSS object model(CSSOM)
- 16. Output
- 17. Step 3: Render TreeDOM HTML Style Sheets HTML Parser CSS Parser DOM Tree Style Rules Render Tree Attachment
- 18. Output
- 21. Oi, Jamie! What about JavaScript? Where’s it go?
- 22. all around us.
- 24. How to measure the Critical Rendering Path
- 25. Pros ● No dev work ● Tracks changes ● No worrying about extensions or stored ● Save results as json or html Cons ● Testing one page at a time Option 1: Web.dev
- 27. Pros ● Automation is cool ● More tests = more data ● Store results and visualize changes ● Test lower environments Cons ● Dev work required ● Dedicated space required Option 2: Automate with Lighthouse
- 29. Pros ● Captures and records real-world CRP performance of any page(!!) ● Holy heck that’s beautiful. Cons ● Must be implemented into your code base (devs required) ● Must be added to each page type Option 3: Navigation Timing API
- 30. CRP Milestones from the Navigation API ● domInteractive marks when DOM is ready. ● domContentLoaded typically marks when both the DOM and CSSOM are ready. ● If there is no parser blocking JavaScript then DOMContentLoaded will fire immediately after domInteractive. ● domComplete marks when the page and all of its subresources are ready.
- 32. Don’t. Block. Rendering. 3 types of rendering-blocking resources A <script> tag that: ● Is in the <head> of the document. ● Does not have a defer attribute. ● Does not have an async attribute.
- 33. Don’t. Block. Rendering. 3 types of rendering-blocking resources A <link rel="stylesheet"> tag that: ● Does not have a disabled attribute. When this attribute is present, the browser does not download the stylesheet. ● Does not have a media attribute that matches the user's device.
- 34. Don’t. Block. Rendering. A <link rel="import"> tag that: ● Does not have an async attribute.
- 35. Protect the <head> ● Remove synchronous 3rd party JavaScript, CSS or fonts from inside the HTML <head>. These are a Single Point of Failure. ● iFrames will prematurely close the <head>. Any resources or metadata listed after the iframe in <head> won’t be executed or discovered.
- 37. Keep resources small ● Use minification and data compression to make scripts as small as possible ● If your script is larger than 50–100 kB, split it up into separate smaller bundles. ● Multiple smaller bundles are more effective than a single large script package. ● If your site uses HTTP/2 multiplexing, multiple requests and responses can be in flight at the same time.
- 38. Avoid critical request chains
- 39. This is a visualization of all the requests to build a page.
- 40. Our site 3rd party script Script’s script Script’s script’s script All the pretty icons and stuff.
- 41. Load only what your need ● If we want to load a URL within 5 seconds on a fast 3G connection (~ 1.6 Mbps) we have about 1000KB budget for ALL of our content. ● Every script called has to be downloaded, parsed, compiled, and executed– regardless of whether it contributes to the content of the page. ● If you need it, only download it once. ● Reuse it as long as possible.
- 44. Prioritize what you load when
- 45. Inline CSS for above the fold content By default, all CSS is a blocking resource ● Inline CSS for content in the initial load viewport is loaded in head ● This CSS should appear before you make calls for external style sheets or JS
- 46. ● Extended max-age is used on JS and CSS resources ● Each resource should specify an explicit caching policy that answers the following questions: whether the resource can be cached and by whom, for how long, and if applicable, how it can be efficiently revalidated when the caching policy expires. Cache JS and CSS resources as long as possible
- 47. Cache JS and CSS resources as long as possible ● When the server returns a response it must provide the Cache-Control and ETag headers: ○ Cache-Control defines how, and for how long the individual response can be cached by the browser and other intermediate caches. ○ ETag provides a revalidation token that is automatically sent by the browser to check if the resource has changed since the last time it was requested.
- 48. |-------------| | MAKE | | ALLIES | |-------------| (__/) || (•ㅅ•) || / づ