If you really, really have to add Google Analytics to a sites, here’s a way to do it in a more performant way, without the odious Google Tag Manager.
A spot-on description of how targetted advertising works …or rather, how it doesn’t.
They are still trying to sell me car insurance for my subway ride.
Following on from that proposal for a browser feature that I linked to yesterday, Tim thinks through all the permutations and possibilities of user agents allowing users to throttle resources:
If a limit does get enforced (it’s important to remember this is still a big if right now), as long as it’s handled with care I can see it being an excellent thing for the web that prioritizes users, while still giving developers the ability to take control of the situation themselves.
Now this is a feature request I can get behind!
I’m serious about this. It’s is an excellent proposal for WebKit, similar to the never-slow mode proposed by Alex for Chromium.
How did I miss this great post from 2016 by one of my favourite people‽ It’s even more more relevant today.
When you stop to consider all the implications of poor performance, it’s hard not to come to the conclusion that poor performance is an ethical issue.
GitHub - GoogleChromeLabs/quicklink: ⚡️Faster subsequent page-loads by prefetching in-viewport links during idle time
This looks like a very handle little performance-enhancing script: it attempts to prefetch some links, but in a responsible way. It won’t do any prefetching on slow connections or where data saving is enabled, and it only prefetches when the browser is idle.
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.
A handy in-browser image compression tool. Drag, drop, tweak, and export.
Harry takes a look at the performance implications of loading CSS. To be clear, this is not about the performance of CSS selectors or ordering (which really doesn’t make any difference at this point), but rather it’s about the different ways of getting rid of as much render-blocking CSS as possible.
…a good rule of thumb to remember is that your page will only render as quickly as your slowest stylesheet.
Ethan ponders what the web might be like if the kind of legal sticks that exist for accessibility in some countries also existed for performance.
Harry divides his web performance work into three categories:
I feel like a lot of businesses are still unsure where to even start when it comes to performance monitoring, and as such, they never do. By demystifying it and breaking it down into three clear categories, each with their own distinct time, place, and purpose, it immediately takes a lot of the effort away from them: rather than worrying what their strategy should be, they now simply need to ask ‘Do we have one?’
Great ideas from Addy on where to start with creating a performance budget that can act as a red line you don’t want to cross.
If it’s worth getting fast, it’s worth staying fast.
When a storm comes, some of the big news sites like CNN and NPR strip down to a zippy performant text-only version that delivers the content without the bells and whistles.
I’d argue though that in some aspects, they are actually better than the original.
The “full” NPR site in comparison takes ~114 requests and weighs close to 3MB on average. Time to first paint is around 20 seconds on slow connections. It includes ads, analytics, tracking scripts and social media widgets.
Meanwhile, the actual news content is roughly the same.
I quite like the idea of storm-driven development.
Rush hour. The worst time of day to travel. For many it’s not possible to travel at any other time of day because they need to get to work by 9am.
This is exactly what a lot of web code looks like today: everything runs on a single thread, the main thread, and the traffic is bad. In fact, it’s even more extreme than that: there’s one lane all from the city center to the outskirts, and quite literally everyone is on the road, even if they don’t need to be at the office by 9am.
Service Workers have such huge potential power, and I feel like we (developers on the web) have barely scratched the surface with what’s possible.
Needless to say, I couldn’t agree more!
Trys is thinking through some of the implicatons of service workers, like how we refresh stale content, and how we deal with slow networks—something that’s actually more of a challenge than dealing with no network connection at all.
There’s some good food for thought here.
I’m so excited to see how we can use Service Workers to improve the web.
This is fascinating! A website that’s fast and nimble, not for performance reasons, but to reduce energy consumption. It’s using static files, system fonts and dithered images. And no third-party scripts.
Thanks to a low-tech web design, we managed to decrease the average page size of the blog by a factor of five compared to the old design – all while making the website visually more attractive (and mobile-friendly). Secondly, our new website runs 100% on solar power, not just in words, but in reality: it has its own energy storage and will go off-line during longer periods of cloudy weather.
Ping! That’s the sound of my brain going “service worker!”
I’ve sent them an email offering my help.