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.
A comprehensive overview of
rel="preload" which looks very useful indeed …I just wish it wasn’t (like “nofollow”) a nonsensical value for the
rel attribute: a resource can’t have a relationship of “preload” to the linking document.
Charlotte talks through some of the techniques she used when she was building the site for this year’s UX London, with a particular emphasis on improving perceived performance.
Smart thinking on optimising the perceived performance of loading web fonts: if you prioritise the most widely-used weight and style (usually the regular roman), and load other weights and styles subsequently, then it appears as though the font is ready sooner.
I very much agree with Orde’s framing here: I don’t think it makes much sense to talk about “above the fold” CSS …but it makes a lot of sense to talk about critical CSS.
And, yeah, it’s another example of progressive enhancement.