Harry Roberts:

today’s shiny will soon become tomorrow’s millstone.

over a decade of consultancy experience has taught me time and time again that…What’s brand new today starts to show its age much more quickly than something that’s already stood the test of time.

customers don’t want smooth page transitions—they want a website that works. Don’t make your entire site a single page app just so you don’t have to retransmit a header and footer.

A wonderful breakdown. This about sums it up right here:

[Critical CSS:] we tackled the wrong problem.

Site-speed is nondeterministic. I can reload the exact same page under the exact same network conditions over and over, and I can guarantee I will not get the exact same, say, DOMContentLoaded each time.

Show me a reproducible measurement that results in reproducible data and therefore reproducible conclusions and I’ll hold my tongue on “data”.

Trying to proxy the impact of reducing our CSS from our LCP time leaves us open to a lot of variance and nondeterminism. When we refreshed, perhaps we hit an outlying, huge first-byte time? What if another file on the critical path had dropped out of cache and needed fetching from the network? What if we incurred a DNS lookup this time that we hadn’t the previous time? Working in this manner requires that all things remain equal, and that just isn’t something we can guarantee. We can take reasonable measures (always refresh from a cold cache; throttle to a constant network speed), but we can’t account for everything.

This is why we need to measure what we impact, not what we influence.

Numbers aren’t often what they seem.

Inadvertently capturing too much data—noise—can obscure our view of the progress we’re actually making, and even though we might end up at the desired outcome, it’s always better to be more forensic in assessing the impact of our work.

The author asks: inflight smoking has been banned in commercial airlines for the last twenty decades but airplanes are still fitted with ashtrays, why? Because rules aren’t going to stop 100% of people. The author summarizes this sentiment from the airlines manufacturers: “We absolutely do not want people to smoke on board, but if they do, then we need to handle the fallout from it in the safest way possible.” It’s about pragmatism.

How does this relate to writing code?

ten years of being a developer has taught me that, sometimes, doing the wrong thing is the right thing to do

Also:

When a team cannot bend the rules of your system or framework, they’ll often opt to simply not use it at all. This is a net loss, where allowing them to do the wrong thing would have at least led to greater adoption, more consistency, and less repetition.

The conclusion being:

Whenever you plan or design a system, you need to build in your own ashtrays; a codified way of dealing with the inevitability of somebody doing the wrong thing.

I liked this reminder that things don’t always work as expected:

If you build and structure applications such that they survive adverse conditions, then they will thrive in favourable ones. Something I often tell clients and workshop attendees is that if you optimise for the lowest rung, everything else on top of that comes for free.

Interesting look at performance difference between mixin and extend in sass. I found this particular point refreshing:

Y’see, when people talk about the performance of mixins, they’re usually thinking about filesize on the filesystem. But because we have gzip enabled (you do have gzip enabled, right?), we should be thinking about filesize over the network.

I often forget this fact. As the Harry Roberts, the author, goes on to show in the article: filesize on the filesystem is one thing and filesize gzipped can often be something else entirely. In his example, File1 was 150% larger than File2 upon compilation, but after gzipping, File1 as 33% smaller than File2.