Harry breaks down cache-control headers into steps that even I can understand. I’ll be using this a reference for sure.
This is terrific! Jeremy shows how you can implement a fairly straightforward service worker for performance gains, but then really kicks it up a notch with a recipe for turning a regular website into a speedy single page app without framework bloat.
Trust no one! Harry enumerates the reason why you should be self-hosting your assets (and busts some myths along the way).
There really is very little reason to leave your static assets on anyone else’s infrastructure. The perceived benefits are often a myth, and even if they weren’t, the trade-offs simply aren’t worth it. Loading assets from multiple origins is demonstrably slower.
This just blew my mind! A fiendishly clever pattern that allows you to inline resources (like critical CSS) and cache that same content for later retrieval by a service worker.
Crazy clever!
It looks like this is landing in Chrome. The navigator.connection.type property will allow us to progressively enhance based on connection type:
A web application that makes use of a service worker to cache resources during installation might have different bundles of assets that it might cache: a list of crucial assets that are cached unconditionally, and a bundle of larger, optional assets that are only cached ahead of time when
navigator.connection.typeis'ethernet'or'wifi'.
There are potential security issues around fingerprinting that are addressed in this document.
Steve describes a script you can use on WebPageTest to simulate going offline so you can test how your progressive web app performs.
Improving performance on The Session.
A proposal to tackle the injustice of Google AMP pages receiving preferential treatment in Google search results.
A presentation at An Event Apart Seattle 2019.
Performance sluething.