Tags: speed

47

sparkline

Base64 Encoding & Performance, Part 1: What’s Up with Base64?

Harry clearly outlines the performance problems of Base64 encoding images in stylesheets. He’s got a follow-up post with sample data.

Performance Under Pressure - performance, responsive web design - Bocoup

The transcript of a really great—and entertaining—talk on performance by Wilto. I may have laughed out loud at points.

Most of the web really sucks if you have a slow connection

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.

Modernizing our Progressive Enhancement Delivery | Filament Group, Inc., Boston, MA

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).

10 things I learned making the fastest site in the world

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.

Intervening against document.write() | Web Updates - Google Developers

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.

SpeedCurve | PWA Performance

Steve describes a script you can use on WebPageTest to simulate going offline so you can test how your progressive web app performs.

Official Google Webmaster Central Blog: AMP your content - A Preview of AMP’ed results in Search

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/turbolinks: Turbolinks makes navigating your web application faster

I really, really like the approach that this JavaScript library is taking in treating Ajax as a progressive enhancement:

Turbolinks intercepts all clicks on a href links 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 body element outright and merges the contents of the head element. The JavaScript window and document objects, and the HTML html element, 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 faster FT.com – Engine Room

A data-driven look at impact of performance:

The data suggests, both in terms of user experience and financial impact, that there are clear and highly valued benefits in making the site even faster.

Managing Mobile Performance Optimization – Smashing Magazine

Some solid sensible advice on optimising performance.

Building the UX London website by Charlotte Jackson

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.

More Responsive Tapping on iOS | WebKit

This solution to the mobile tap delay by the WebKit team sounds like what I was hoping for:

Putting 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.

Smaller, Faster Websites - - Bocoup

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.

I Turned Off JavaScript for a Whole Week and It Was Glorious | WIRED

When someone’s web browsing experience can be so drastically improved by simply switching off JavaScript, you know it’s time for an intervention with web developers.

This is our fault. Client-side JavaScript gave us enormous power and we abused that power.

Performance Budget Calculator

A handy little for calculating your performance budget based on how long you want your page to take to load on a particular connection.

Performance update #2: Electric Boogaloo | Vox Product Blog

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.

Declaring performance bankruptcy | Vox Product Blog

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.”

Supercharging page load (100 Days of Google Dev) - YouTube

A straight-faced Jake talks us through the step-by-step iterations for turning a JavaScript-required web thang into a progressively enhanced zippy experience, supercharged with Service Worker.

The web is fast by default, let’s keep it fast | hiddedevries.nl

Apart from the best practices that can often be automated, there are many human decisions that have impact on page speed. A way to make page speed part of the conversation and optimising it part of a website’s requirement, is to set a performance budget.