Web Performance
Web performance shouldn’t be an afterthought, but rather something that we measure throughout the lifespan of the project.
On the frontend, page speed is impacted by:
- the number of resources loaded
- the size of the resources loaded
- whether any of those resources block further page rendering while they load
Resources may be images, videos, fonts, scripts, styles, or data.
CSS (unless it is excluded via a media query) and JavaScript (unless it is marked as asynchronous) will block rendering of the page at the position in the document they are referenced until the resource has been fetched, parsed and (in the case of JavaScript) executed.
Our goals with web performance should be to:
- minimize the number of requests for resources
- minimize the size of our resources
- defer requesting as many resources as possible
Images can carry a lot of weight and we typically load many of them. It is crucial to use the most appropriate format for each image, and use srcset and a tool like Imgix to compress and size images responsively.
Lazy-loading images hidden below the fold (or in carousels) is also vitally important. Images are not render-blocking, but the sheer volume of requests will slow down the page, so we need to prioritise only the images that are actually visible.
Formats
SVG: vector images
PNG: images with few colors (e.g. computer-generated assets)
JPEG: images with many colors (e.g. photos)
WEBP: a modern alternative to both PNG and JPEG, offering savings of 25-34% on size
Webfonts bring typographical options to the web, but usually require multiple files to cover all variations needed (regular, bold, italic, etc.), and are full of characters we don’t use to boot. Worse, most browsers will not render any text at all until the font has finished downloading and is ready to use. It is crucial to provide a fallback system font so that users can see page content before the font is loaded.
Zach Leat has a comprehensive guide to loading webfonts with a complete breakdown of the various font loading techniques available today. Where possible, fonts should generally be loaded in stages with fallbacks, so that users first see the system font, then a critical subset of the regular webfont with faux bold and italic, then finally the full set.
Expensive not just in gzipped weight sent down the wire, but in parsing and execution time. Don’t write/import more than needed!
- Only pick a JS framework/SPA when the project actually demands it
- If it does, use code-splitting, tree-shaking and scope-hoisting
- Choose external libraries carefully, checking with e.g. https://bundlephobia.com/
- Monitor bundle size and identify culprits with, e.g.
Inline critical CSS, load full stylesheet async.
Optimize queries for a balance between the number of requests and the size of the responses.
- Measure regularly with Lighthouse in Chrome Dev Tools → Audits
- Run in an incognito window / clean profile and in production mode
- Mobile Device, Perfomance Audit, Simulated Fast 3G, 4x CPU Slowdown
- Reports can be saved as (private) gists and viewed with https://googlechrome.github.io/lighthouse/viewer/
- Can include links in PRs to show before / after to verify impact of changes
- Consider incorporating into CI tests with Lighthouse Bot
- Also services like WebpageTest, Calibre or SpeedCurve
- How do we choose what the budget metrics are and how do we set them?
- Which pages do we track?
- Which pages do users interact with most?
- Which pages are important to the business?
- Which pages are particularly slow?
- Drop off/bounce rates?
Consider using RUM (real user metrics) such as Boomerang
- Create issues instead of comments for performance issues if we notice them in the development process