Web Performance Fundamentals

I had heard that Google was changing some of the ways it measures performance, and I wasn't fully versed in what the new terms are or what they mean, so I was excited to find 'Web Performance Fundamentals' course by Todd Gardner on FrontendMasters.com, which goes into the new metrics and why they matter.

The new metrics are:

  • First contentful paint
  • Largest contentful paint
  • Cumulative Layout Shift
  • First input delay

Todd advises that it's important to focus on this because Google will rank your site based on these metrics, and also, a performant experience will lessen the chance of impatient users leaving the site.

Lighthouse

Before going into the different ways of tackling each of the new metrics, Todd covers Lighthouse. This is a test that can be run from within anyone's Chrome browser through dev tools. The gotchas of using Lighthouse:

  • It's relative to your machine and network.
  • Chrome window size affects the results.
  • Chrome should be kept in the foreground

Todd suggests also disjoining devtools from the Chrome browser before running the test, as using it in-browser affects window size, and therefore test results. He also points out that Chrome extensions affect the test, so it's recommended to disable them (or run Lighthouse in incognito mode).

Ideally, you measure from real world statistics (but I forget on how we get this), but there are gotchas there too, as bots affect the values, and averages can stink, so it's good to understand the biases. Google cares about the p75 number, which is 75% of your users have a better score than this. Todd feels like we should care about p95. (Where does this come from again?)

Performance API

Todd goes into the Performance API, which is something browsers can report back on regarding these metrics. I didn't see me coding this out, so I didn't pay high attention to this area. But it seemed to boil down to buiding out some scripts that could measure this for anyone's visit to the site, then when they leave the site, post to an endpoint that gathers the data. It's kind of neat to do a homegrown version of a metrics tracker, but I'd likely end up using something already built for this. It's interesting, though, to know that the browser's performance API has some of this info readily available to access.

Improving FCP

  • Servers needs to be quick
    • Sized correctly
    • Have minimal processing specified
    • Appropriate network bandwidth
  • Small amounts of data
    • Content size should be small
    • Use compression (gzip, brotli)
  • Fewer hops
    • Use a CDN

Improving LCP

  1. Defer resources until later
  2. Optimize images
  3. Reduce request overhead

Scripts in the head are blocking. A common method to help with that is async attribute on the script tag, but once the browser commits to downloading it, it wants to execute. So Todd encourages use of defer attribute instead, which tells the browser not to execute until after the load event. Also move js to the end of the body.

To help with images that don't need to be loaded yet, use loading="lazy" attribute to images, but unfortunately, that's not supported in Safari. So a lazyloader.js solution is encouraged instead, which uses IntersectionObserver to signla to a browser when to load images.

Todd also gets into using srcset and sizes - with the idea being that smaller devices will have the option of pulling down more appropriately sized images, rather than one-size-fits-all. Also, specifying browser caching is an option, but is really only helpful to those on a repeat visit.

Using <link rel="preconnect" href=""> we can tell the browser to establish a connection to another domain from which we'll need resources, which should help the speed at which those resources are finally fetched.

Todd also encourages use of <link rel="preload" href=""> - but I'm reading different things about why that's a good or bad idea, so I think the main idea is be familiar with those options.

Improving Cumulative Layout shift

Apply 'width' and 'height' values to images or iframes. The browser can reserve the space immediatetely instead of shifting content after the image (or iframe) loads.

Improving first input delay

Apparently this is kind of abstract according to the speaker, so we don't really get a working exercise opportunity to change this.

In summary

It's nice to cover the metrics, and go over what they mean (although I didn't walk away from this course with a solid understanding of first input delay). I would've liked to see a few methods mentioned to automate some of the items above (lazyloading, setting width and height of images, etc.). I think the manual walkthrough of those tweaks were good and important in this course, but it would've been good also touch on automated solutions, as I doubt content creators of large organizations are tweaking things in this manner. I'm also surprised that 'webpagetest.org' wasn't mentioned as well.

June 2, 2021🏷frontendmastersperformance