Harry clearly outlines the performance problems of Base64 encoding images in stylesheets. He’s got a follow-up post with sample data.
The transcript of a really great—and entertaining—talk on performance by Wilto. I may have laughed out loud at points.
Just like many people develop with an average connection speed in mind, many people have a fixed view of who a user is. Maybe they think there are customers with a lot of money with fast connections and customers who won’t spend money on slow connections. That is, very roughly speaking, perhaps true on average, but sites don’t operate on average, they operate in particular domains.
Phil describes the process of implementing the holy grail of web architecture (which perhaps isn’t as difficult as everyone seems to think it is):
I have been experimenting with something that seemed obvious to me for a while. A web development model which gives a pre-rendered, ready-to-consume, straight-into-the-eyeballs web page at every URL of a site. One which, once loaded, then behaves like a client-side, single page app.
Now that’s resilient web design!
A nice and clear description of how browsers parse and render web pages.
Scott runs through the latest improvements to the Filament Group website. There’s a lot about HTTP2, but also a dab of service workers (using a similar recipe to my site).
This is an interesting use of voodoo magic (or “machine learning” as we call it now) by Google to interpolate data in a small image to create a larger version. A win for performance.
A cute explanation of different browser caches:
- memory cache,
- service worker cache,
- disk cache, and
- push cache.
So if AMP is useful it’s because it raises the stakes. If we (news developers) don’t figure out faster ways to load our pages for readers, then we’re going to lose a lot of magic.
A number of developers answered questions on the potential effects of Google’s AMP project. This answer resonates a lot with my own feelings:
AMP is basically web performance best practices dressed up as a file format. That’s a very clever solution to what is, at heart, a cultural problem: when management (in one form or another) comes to the CMS team at a news organization and asks to add more junk to the site, saying “we can’t do that because AMP” is a much more powerful argument than trying to explain why a pop-over “Like us on Facebook!” modal is driving our readers to drink.
But the danger is that AMP turns into a long-term “solution” instead of a stop-gap:
So in a sense, the best possible outcome is that AMP is disruptive enough to shake the boardroom into understanding the importance of performance in platform decisions (and making the hard business decisions this demands), but that developers are allowed to implement those decisions in standard HTML instead of adding yet another delivery format to their export pipeline.
The ideal situation looks a lot more like Tim’s proposal:
Did you know that Ilya’s book was available in its entirety online? I didn’t. But now that I do, I think it’s time I got stuck in and tried to understand the low-level underpinnings of the internet and the web.
Behind the amusing banter there’s some really solid performance advice in here. Good stuff.
Client Side Rendering (CSR), or as I call it “setting money on fire and throwing it in a river” has its uses, but for this site would have been madness.
You can print out this PDF and then have the satisfaction of ticking off each item on the list as you build your website.
This is a thorough write-up of an interesting case where SVG looks like the right tool for the job, but further research leads to some sad-making conclusions.
I love SVG. It’s elegant, scalable and works everywhere. It’s perfect for mobile… as long as it doesn’t move. There is no way to animate it smoothly on Android.
We all make assumptions, it’s natural and normal. But we also need to be jolted out of those assumptions on a regular basis to help us see that not everyone uses the web the way we do. I’ve talked about loving doing support for that reason, but I also love it when I’m on a slow network, it shows me how some people experience the web all the time; that’s good for me.
I’m privileged to have fast devices and fast, broadband internet, along with a lot of other privileges. Not remembering that privilege while I work and assuming that everyone is like me is, quite possibly, one of the biggest mistakes I can make.
Monica takes a look at the options out there for loading web fonts and settles on a smart asynchronous lazy-loading approach.
Here’s an interesting metric for measuring performance: take the overall page weight of a URL and divide it by the file size of the screenshot of that URL.
AMP loads super, super quickly and is simply a better experience right now. So can we add enough design to make an AMP page feel like The Verge?
What a depressing conclusion! But I guess it’s easier than, y’know, actually fixing the bloated Verge website, packed with megabytes and megabytes of invasive trackers. It’s no wonder people prefer the AMP experience. Yet the idea of improving the website isn’t even raised in this whole article.
Then again, this is the same guy who tried to lay the blame for The Verge’s abysmal performance at the feet of web browsers.
will-changeproperty that was intended to SOLVE problems for animators may end up doing the opposite.
It seems wise for the browsers to step back and let the spec authors fill in the implementation details and gain consensus before moving forward.
Chrome is going to refuse to parse
document.write for users on a slow connection. On the one hand, I feel that Google intervening in this way is a bit icky, but I on the other hand, I totally support this move.
This keeps happening. Google announce a change (usually related to search) where I think “Ooh, that could be interpreted as an abuse of a monopoly position …but it’s for ver good reason so I’ll keep quiet.”
Anyway, this should serve as a good kick in the pants for bad actors (that’s you, advertisers) to update their scripts to be asynchronous.