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.
I like the look of this proposal that would allow authors to have more control over network priorities for third-party iframes—I’ve already documented how I had to use a third-party library to fix this problem on the Salter Cane site.
Google Fonts only lets you download .ttf files meaning that if you want to self-host your fonts (and you should), you have to first convert them to .woff2 files.
Luckily this tool has been online for over a decade, doing what Google Fonts should be doing by default.
Here’s a handy free tool from Calibre that’ll give your website a performance assessment.
One dev team made the shift from React’s “overwhelming VDOM” to modern DOM APIs. They immediately saw speed and interaction improvements.
Yay! But:
…finding developers who know vanilla JavaScript and not just the frameworks was an “unexpected difficulty.”
Boo!
Also, if you have a similar story to tell about going cold turkey on React, you should share it with Richard:
If you or your company has also transitioned away from React and into a more web-native, HTML-first approach, please tag me on Mastodon or Threads. We’d love to share further case studies of these modern, dare I say post-React, approaches.
Needless to say, I agree with this sentiment.
I’ve worked with a lot of browser technology over the years. Service workers are pretty mind-blowing.
How I switched to high-resolution maps on The Session without degrading performance.
Safari 18 supports `content-visibility: auto` …but there’s a very niche little bug in the implementation.
A performance boost in Chrome.
Fear of a third-party planet.
A small-scale conspiracy theory from the innards of Google.