Harry clearly outlines the performance problems of Base64 encoding images in stylesheets. He’s got a follow-up post with sample data.
Saturday, February 18th, 2017
Thursday, February 9th, 2017
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.
Sunday, January 15th, 2017
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).
Saturday, December 24th, 2016
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.
Wednesday, September 28th, 2016
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.
Wednesday, September 21st, 2016
Saturday, August 6th, 2016
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).
Tuesday, May 31st, 2016
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.
Thursday, April 14th, 2016
A data-driven look at impact of performance:
Tuesday, March 15th, 2016
Some solid sensible advice on optimising performance.
Friday, December 18th, 2015
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.
Wednesday, December 16th, 2015
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.
Sunday, December 13th, 2015
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.
Sunday, November 22nd, 2015
Thursday, October 15th, 2015
A handy little for calculating your performance budget based on how long you want your page to take to load on a particular connection.
Thursday, August 13th, 2015
It’s really great to see the performance improvements being made by the Vox team. This is the one that I think will make the most difference:
Our Revenue Team is increasing focus on the impact our advertising has on user experience and overall performance. One of their biggest initiatives has been to change the way ads load from synchronous to asynchronous, which has been underway for several months and is nearing deployment.
Monday, July 27th, 2015
On The Verge
Quite a few people have been linking to an article on The Verge with the inflammatory title The Mobile web sucks. In it, Nilay Patel heaps blame upon mobile browsers, Safari in particular:
But man, the web browsers on phones are terrible. They are an abomination of bad user experience, poor performance, and overall disdain for the open web that kicked off the modern tech revolution.
Les Orchard says what we’re all thinking in his detailed response The Verge’s web sucks:
Calling out browser makers for the performance of sites like his? That’s a bit much.
Nilay does acknowledge that the Verge could do better:
Now, I happen to work at a media company, and I happen to run a website that can be bloated and slow. Some of this is our fault: The Verge is ultra-complicated, we have huge images, and we serve ads from our own direct sales and a variety of programmatic networks.
But still, it sounds like the buck is being passed along. The performance issues are being treated as Somebody Else’s Problem …ad networks, trackers, etc.
The developers at Vox Media take a different, and in my opinion, more correct view. They’re declaring performance bankruptcy:
I mean, let’s cut to the chase here… our sites are friggin’ slow, okay!
But I worry about how they can possibly reconcile their desire for a faster website with a culture that accepts enormously bloated ads and trackers as the inevitable price of doing business on the web:
You realize that “bloat" pays the salaries of editorial, product, design, video, etc etc etc, right?— nilay patel (@reckless) July 20, 2015
I’m hearing an awful lot of false dichotomies here: either you can have a performant website or you have a business model based on advertising. Here’s another false dichotomy:
To be clear: I’d pick a slow open web loaded with trackers and ads over a walled garden 100 percent of the time.— nilay patel (@reckless) July 21, 2015
If the message coming down from above is that performance concerns and business concerns are fundamentally at odds, then I just don’t know how the developers are ever going to create a culture of performance (which is a real shame, because they sound like a great bunch). It’s a particularly bizarre false dichotomy to be foisting when you consider that all the evidence points to performance as being a key differentiator when it comes to making moolah.
It’s funny, but I take almost the opposite view that Nilay puts forth in his original article. Instead of thinking “Oh, why won’t these awful browsers improve to be better at delivering our websites?”, I tend to think “Oh, why won’t these awful websites improve to be better at taking advantage of our browsers?” After all, it doesn’t seem like that long ago that web browsers on mobile really were awful; incapable of rendering the “real” web, instead only able to deal with WAP.
As Maciej says in his magnificent presentation Web Design: The First 100 Years:
As soon as a system shows signs of performance, developers will add enough abstraction to make it borderline unusable. Software forever remains at the limits of what people will put up with. Developers and designers together create overweight systems in hopes that the hardware will catch up in time and cover their mistakes.
If anything, browser makers might have to take more drastic steps to route around the damage of bloated websites with invasive tracking.
- swapping out images when the user moused over a link,
- doing really bad client-side form validation, and
- spawning pop-up windows.
Tracking and advertising scripts are today’s equivalent of pop-up windows. There are already plenty of tools out there to route around their damage: Ghostery, Adblock Plus, etc., along with tools like Instapaper, Readability, and Pocket.
That option is basically stealing. Don’t feel good about that.— nilay patel (@reckless) July 21, 2015
I’m sure that business owners felt the same way about pop-up ads back in the late ’90s. Just the price of doing business. Shrug shoulders. Just the way things are. Nothing we can do to change that.
For such a young, supposedly-innovative industry, I’m often amazed at what people choose to treat as immovable, unchangeable, carved-in-stone issues. Bloated, invasive ad tracking isn’t a law of nature. It’s a choice. We can choose to change.
Every bloated advertising and tracking script on a website was added by a person. What if that person refused? I guess that person would be fired and another person would be told to add the script. What if that person refused? What if we had a web developer picket line that we collectively refused to cross?
That’s an unrealistic, drastic suggestion. But the way that the web is being destroyed by our collective culpability calls for drastic measures.
By the way, the pop-up ad was first created by Ethan Zuckerman. He has since apologised. What will you be apologising for in decades to come?
Wednesday, July 22nd, 2015
It’s really good to see that Vox are taking measures to fix their atrocious performance problems. The Verge in particular is a case study in how not to serve up text and images on the web. There have been times in the past when I’ve wanted to link to an article there but then thought “I can’t in good conscience put a fellow human through that.”
Saturday, May 30th, 2015