If you ever need to pull up some case studies to demonstrate the business benefits of performance, Tammy and Tim have you covered.
A wide-ranging post from Andrew on the downsides of Google’s AMP solution.
I don’t agree with all the issues he has with the format itself (in my opinion, the fact that AMP pages can’t have
script elements is a feature, not a bug), but I wholeheartedly concur with his concerns about the AMP cache:
It recklessly devalues the URL
Spot on! And as Andrew points out, in this age of fake news, devaluing the URL is a recipe for disaster.
It’s hard to avoid the idea that the primary objective of AMP is really about hosting publisher content inside the Google ecosystem (as is more obviously the objective of Facebook Instant Articles and Apple News).
Here’s the panel I was on at the AMP conference. It was an honour and a pleasure to share the stage with Nicole, Sarah, Gina, and Mike.
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.
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).
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.
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.
Google’s search results now include AMP pages in the regular list of results (not just in a carousel). They’re marked with a little grey lightning bolt next to the word AMP.
The experience of opening of those results is certainly fast, but feels a little weird—like you haven’t really gone to the website yet, but instead that you’re still tethered to the search results page.
Clicking on a link within an AMP spawns a new window, which reinforces the idea of the web as something separate to AMP (much as they still like to claim that AMP is “a subset of HTML”—at this point, it really, really isn’t).
Turbolinks intercepts all clicks on
a hreflinks to the same domain. When you click an eligible link, Turbolinks prevents the browser from following it. Instead, Turbolinks changes the browser’s URL using the History API, requests the new page using
XMLHttpRequest, and then renders the HTML response.
During rendering, Turbolinks replaces the current
bodyelement outright and merges the contents of the
documentobjects, and the HTML
htmlelement, persist from one rendering to the next.
Here’s the mustard it’s cutting:
It depends on the HTML5 History API and Window.requestAnimationFrame. In unsupported browsers, Turbolinks gracefully degrades to standard navigation.
This approach matches my own mental model for building on the web—I might try playing around with this on some of my projects.
A data-driven look at impact of performance:
Some solid sensible advice on optimising performance.
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.
This solution to the mobile tap delay by the WebKit team sounds like what I was hoping for:
touch-action: manipulation;on a clickable element makes WebKit consider touches that begin on the element only for the purposes of panning and pinching to zoom. This means WebKit does not consider double-tap gestures on the element, so single taps are dispatched immediately.
It would be nice to know whether this has been discussed with other browser makers or if it’s another proprietary addition.
The transcript of a great talk by Wilto, focusing on responsive images, inlining critical CSS, and webfont loading.
When we present users with a slow website, a loading spinner, laggy webfonts—or tell them outright that they‘re not using a website the right way—we’re breaking the fourth wall. We’ve gone so far as to invent an arbitary line between “webapp” and “website” so we could justify these decisions to ourselves: “well, but, this is a web app. It… it has… JSON. The people that can’t use the thing I built? They don’t get a say.”
We, as an industry, have nearly decided that we’re doing a great job as long as we don’t count the cases where we’re doing a terrible job.