68. Performance Tuning Critical Rendering Path

Charlie Gleason, a designer and developer at Heroku, is in conversation with Ben Harding, a developer at Raygun. Their conversation centers around a website's "critical render path," which are the steps in which HTML, CSS, and JavaScript are converted into pixels which a user actually interacts with in their browser. The fast these pixels are rendered, the better the experience which a user receives. Delays in website rendering can lead to an impact on one's business, as users are likely to leave slow sites; more often, it's an issue of accessibility, where users with slower connections should be able to visit any page they want to.

Ben outlines four metrics that can be key to gathering information about how your website is performing. There's "time to first paint," which is the time it takes for a browser to render anything; there's "time to first contentful paint," which is the time it takes for the browser to render any content, like an image or text; there's load time, which is the time it takes for all of your assets--CSS, JavaScript, and fonts--to download; and there's "time to interactive," which is when a user can start engaging with a website, such as by clicking buttons or filling out a form. It's important to measure all of these stats first so that you can approach performance optimizations from a baseline of where you are, and where you want to be.

There's plenty of low-hanging fruit when it comes to improving website rendering performance. You could try minifying and compressing your CSS, JavaScript, and images, so that the user's browser doesn't need to fetch large files. You can also implement techniques such as code splitting, which ensures that CSS and JavaScript is only loaded for the pages those styles or functions are needed on, rather than every single page on your site. You can load your assets asynchronously, so that the browser is not blocked on any one task. The important thing is to take a look at your starting metrics, and focus on tackling one of your problems until the load times are down to an acceptable range.

Fine-tuning website performance is an iterative cycle: as more features are added, performance will degrade. Sometimes you can't optimize a website any further than you've already done, and that's okay. As long as you keep your user's perceived performance in mind, you can still get away with having spinners and splash screens, so long as they are receiving feedback and are aware that something is happening.

Links from this epiode

• Critical rendering path
• DOM and CSSOM
• Lighthouse
• Webpack
• Parcel
• Uglify
• ImageOptim
• TinyPNG
• SVGO
• Media attributes for CSS files
• Async / defer for JavaScript
• Preloading / prefetching assets
• Heroku’sMalibu icon library
• SVG and sprite sheets
• Code splitting
• React Lazy and Suspense
• Visualising bundle sizes
• Tree shaking
• Raygun