srcset, revisited
The exact bug I wrote about in 2018, on a site built last year, by a competent team, with a modern pipeline. Which tells you which parts of this got fixed in eight years.
18 posts filed under Performance, newest first.
The exact bug I wrote about in 2018, on a site built last year, by a competent team, with a modern pipeline. Which tells you which parts of this got fixed in eight years.
Three years of declining performance work. Then the same list of changes, approved in two weeks, because it arrived under a sustainability heading instead of a technical one.
I measured a client's homepage in August and the fonts were 41% of it, which makes them the largest avoidable cost on the page and also the one line item nobody will let you touch.
Most image optimization advice is about codecs, but the actual bug is usually that nobody has opened the file and looked at it since the day it came out of Figma.
Most of the web is brochures, and a brochure doesn't need a client-side runtime, a router, or a build pipeline that stops working the moment you look away from it.
For about eight years the standard way to find out whether something was on screen was to ask, repeatedly, on every scroll event, in a way that forced the browser to stop and recalculate layout each time.
Two things happened to image formats this fall, and the less exciting one is much more useful. I'd like a flowchart for choosing between them. I don't think one can exist.
I added lazy loading to every image on a site in about 20 minutes, felt pleased with myself, and then measured it and found the pages were taking longer to show their main content than before I started.
Eight years of losing this argument, because it was my opinion against somebody's feature. Then Google published three numbers with thresholds on them. That changes the politics far more than the engineering.
We spent 40 minutes arguing about whether a 28 KB framework was too heavy for the project, on a site whose tag manager was pulling in 470 KB of other people's JavaScript that nobody in the room had ever measured.
Set in January, written in a document. The site is now more than twice it and nobody broke a rule, because there was never a moment where anybody had to say no.
A month after the deadline, the visible output of the largest privacy regulation in a generation is an interface that appears on every website in Europe and is designed, carefully and expensively, to be got past.
Full-page caching made the whole store about eight times faster and broke exactly four things, and all four of them were the same problem wearing different hats.
Five pages, a contact form, updated roughly twice a year, and I spent an evening giving it an offline experience. I've been trying since to work out honestly whether that was worth doing or just fun.
I shipped that homepage at 180 KB and it is currently 2.5 MB, and nobody did anything wrong. They just changed the picture like they were supposed to be able to.
Most of what jQuery was invented to fix has been fixed in the browsers, and a lot of us are still loading the whole library to avoid typing a slightly longer method name.
Every browser has picked a different answer to what should happen while a web font downloads, and all of the answers are bad so the decision quietly falls to you whether you choose to make it or not.
Every conversation about page weight goes straight to minification. Meanwhile there is a 2 MB image on the page that nobody has opened since Photoshop.