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.
This checklist came in very handy during a performance-related workshop I was running today (I may have said the sentence “Always ask yourself What Would Zach Do?”).
- Start Important Font Downloads Earlier (Start a Web Font load)
- Prioritize Readable Text (Behavior while a Web Font is loading)
- Make Fonts Smaller (Reduce Web Font load time)
- Reduce Movement during Page Load (Behavior after a Web Font has loaded)
The first two are really straightforward to implement (with
font-display). The second two take more work (with subsetting and the font loading API).
Focusing on the median or average is the equivalent of walking around with a pair of blinders on. We’re limiting our perspective and, in the process, missing out on so much crucial detail. By definition, when we make improving the median or average our goal, we are focusing on optimizing for only about half of our sessions.
Tim does the numbers…
By honing in on the 90th—or 95th or similar—we ensure those weaknesses don’t get ignored. Our goal is to optimize the performance of our site for the majority of our users—not just a small subset of them.
I was just talking about how browser-based games are the perfect use-case for service workers. Andrzej Mazur breaks down how that would work:
- Add to Home screen
- Offline capabilities
- Progressive loading
AMP pages aren’t fast because of the AMP format. AMP pages are fast when you visit one via Google search …because of Google’s monopoly on preloading:
Technically, a clever trick. It’s hard to argue with that. Yet I consider it cheating and anti competitive behavior.
Preloading is exclusive to AMP. Google does not preload non-AMP pages. If Google would have a genuine interest in speeding up the whole web on mobile, it could simply preload resources of non-AMP pages as well. Not doing this is a strong hint that another agenda is at work, to say the least.
A step-by-step guide to implementing drag’n’drop, and image previews with the Filereader API. No libraries or frameworks were harmed in the making of this article.
Ooh, this is clever! Scott shows how you can use
Here’s a clever to technique to improve the perceived performance of image loading with a polygonal SVG placeholder.
Here’s the flow that eBay use for the font-loading. They’ve decided that on the very first page view, seeing a system font is an acceptable trade-off. I think that makes sense for their situation.
Interestingly, they set a flag for subsequent visits using
localStorage rather than a cookie. I wonder why that is? For me, the ability to read cookies on the server as well as the client make them quite handy for situations like this.
It looks like this is landing in Chrome. The
navigator.connection.type property will allow us to progressively enhance based on connection type:
A web application that makes use of a service worker to cache resources during installation might have different bundles of assets that it might cache: a list of crucial assets that are cached unconditionally, and a bundle of larger, optional assets that are only cached ahead of time when
There are potential security issues around fingerprinting that are addressed in this document.
A good analysis, but my takeaway was that the article could equally be called Why it’s tricky to measure Client-side Rendering performance. In a nutshell, just looking at metrics can be misleading.
Pre-classified metrics are a good signal for measuring performance. At the end of the day though, they may not properly reflect your site’s performance story. Profile each possibility and give it the eye test.
And it’s always worth bearing this in mind:
This article makes a good point about client-rendered pages:
Asynchronously loaded page elements shift click targets, resulting in a usability nightmare.
…but this has nothing, absolutely nothing to do with progressive web apps.
More fuel for the fire of evidence that far too many people think that progressive web apps and single page apps are one and the same.
Everyone’s been talking about
font-display: swap as a way of taking the pain out of loading web fonts, but here Chris looks at
font-display: optional and
font-display: fallback as well.
A look at our relationship with waiting, and how that is manifested in the loading icons in our interfaces.
For me, in my moments of boredom, as I turn to my phone and refresh my social media feed, I imagine that what’s on the other side of the buffering icon might be the content that will rid me of boredom and produce a satisfying social connection. The buffering icon here represents my hopes for the many ways that my social media feeds can satisfy my longings at any given moment. They rarely do, though I believe that we are half in love with the buffering icon here because it represents the promise of intimacy or excitement across the distances that separate us.
Harry clearly outlines the performance problems of Base64 encoding images in stylesheets. He’s got a follow-up post with sample data.
Monica takes a look at the options out there for loading web fonts and settles on a smart asynchronous lazy-loading approach.
A terrific rundown of all your options when it comes to web font loading.
Infinite Scrolling, Pagination Or “Load More” Buttons? Usability Findings In eCommerce – Smashing Magazine
A good side-by-side comparison of loading techniques, with some clear advice. But pay attention to this note:
While the debate over “Load more” versus infinite scrolling versus pagination has been debated for years, the product loading method shouldn’t be the first thing that most e-commerce vendors spend their development resources on.