A nifty tool from Brad to help calculate and allocate performance budgets. Click around and edit the numbers.
I think that “Do we want to support users without JS?” is the wrong question. Progressive enhancement has benefits that reach far beyond that user group.
- Resilience—”If users can perform critical tasks when your JS breaks, it’s a minor inconvenience instead of a show stopper.”
- Business, Business, Business.
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.
A superb talk on performance, advertising, and the future of the web. No doubt a transcript will appear in due time on Maciej’s site and when it does, I will enjoy it all over again.
Trust me: you’ll want to watch this.
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.
The missing font generator for Mac OS X.
Very handy for subsetting fonts for the web. It doesn’t (yet) export WOFF2 unfortunately.
Quite a few moving parts in this technique from Emil, but it’s very clever.
This is a nifty use of Service Workers—using a cache to mitigate unresponsive Content Delivery Networks.
The stuff in here about
Promise.race is particularly useful for “lie-fi” scenarios: instead of thinking about the network connection in a binary way (either it’s available or it isn’t), considering the scenario of a crappy network connection seems more realistic.
Harry packs a lot of great tips and tricks into one short video about performance troubleshooting. It’s also a great lesson in unlocking some handy features in Chrome’s developer tools.
A look at detecting, pinpointing, measuring, and fixing rendering performance issues.
Outlining the architectural thinking required to create what the Google devrel folks are calling progressive apps.
Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering…
…but this is only one of many options.
Hmmm. In my opinion, sending usable HTML on first request isn’t an implementation detail—it’s crucial. But on the whole, this approach is very sensible indeed.
Paul gives the lowdown on the Google+ responsive relaunch. They set themselves this performance budget:
- 60K of HTML,
- 60K of CSS,
- 60 frames per second animations, and
- 0.6 seconds latency.
And this bit is crucial:
Here’s Paul’s write-up of his excellent talk at FF Conf.
Previously I’ve used the term “developer convenience” when describing the benefits of using a framework. Paul uses the term “ergonomics” to describe those benefits. I like that. I worry sometimes that the term “developer convenience” sounds dismissive, which isn’t at all my intention—making our lives as developers less painful is hugely important …but it’s just not as important as improving the lives of the end users (in my opinion …and Paul’s).
As I look at frameworks, I see the ergonomic benefits (and those are important, I agree!), but I can’t help but feel that, for many developers, investing in knowledge of the web platform itself is the best long-term bet. Frameworks come and go, it just seems to be the ebb and flow of the web, and, as I said above, they do contribute ideas and patterns. But if you ever find that the one you use no longer works for you, or has a bug that remains unfixed, being able to understand the platform that underpins it will help enormously.
This was one of favourite talks at this year’s FF Conf. But I will readily admit there’s a hefty dollop of confirmation bias in my enjoyment.
Are we doomed to see history repeat itself? With the amount of client-side MVC frameworks and the upcoming implementation of the ES6 syntax, will we soon be seeing a repeat of the “browser wars.” Will more websites only work in a select number of browsers with the capabilities to run their code?
The prognosis for publishers is grim. Repent! Find a way out of the adtech racket before it collapses around you. Ditch your tracking, show dumb ads that you sell directly (not through a thicket of intermediaries), and beg your readers for mercy. Respect their privacy, bandwidth, and intelligence, flatter their vanity, and maybe they’ll subscribe to something.
The full transcript of Scott’s excellent presentation on performance and progressive enhancement.
There’s something quite Kafkaesque about reading through the comments on Jeff Atwood’s request for an alternative to Ember.js …for rendering some text on a screen.
Every now and then someone pipes up with “server-rendered HTML?”, there’s a pause, and then a response of “naahhhhh.”
But he shares my hope that AMP could serve as a demo of what the web could be if we developers had the will and political clout to see it through:
I wonder if what AMP really does is remind us how we’ve failed to build a performant web… we know how to, but all too often we just choose not to (or lose the argument) and fill our sites with cruft that kills performance, and with it our visitors’ experience.
A handy little for calculating your performance budget based on how long you want your page to take to load on a particular connection.
Tom’s thoughts on what AMP means for developers and publishers. He was initially sceptical but now he’s cautiously optimistic. Like me, he’s hoping that AMP can force the hand of those third-party advertisers to get their act together.
Publisher’s development teams are very capable of creating fast experiences for mobile users, but they don’t have the clout to coordinate all the additional cruft that is added to the page. However, if all the different publishers dev team’s got together and put their weight behind a single implementation, then we can force third parties to change their habits.
All the videos from the excellent Responsive Field Day are now available. Even better, the audio is also available for your huffduffing pleasure!
All the presentations and panels were great. Sophie Shepherd’s terrific talk has really stuck with me.
Paul compares publishing on the web to publish on proprietary platforms, and concludes that things aren’t looking great right now.
Performance is the number one selling point for each of these new content platforms.
Websites should not come with minimum software requirements.
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.
Yes! Yes! YES!
Marco makes the same comparison I did between the dark days of pop-up windows and the current abysmal state of bloated ads and tracking on today’s web.
I have one more thing to add to this list…
But publishers, advertisers, and browser vendors are all partly responsible for the situation we’re all in.
…developers. Somebody put those harm-causing
script elements on those pages. Like I said: “What will you be apologising for in decades to come?”
In a few years, after the dust has settled, we’re all going to look back at today’s web’s excesses and abuses as an almost unbelievable embarrassment.
Lara’s fantastic book is now available online in HTML for free. Have a read and then order a copy of the print book for your library.
Jeffrey weighs on the post I wrote about The Verge. I still feel like there’s a false dichotomy being presented here though: either performance or advertising. But advertising can be performant too. There’s a competitive advantage to be had there.
A long zoom and then a deep dive into web typography.
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.”
The system makes the website. Don’t blame the web developer, blame the organisation. A web developer embedded in a large system isn’t the one making the websites.
To make a progressively enhanced website that performs well and loads quickly even on slow connections, you need to first make an organisation that values those qualities over others.
Susan points out some uncomfortable truths. It’s all very well for us to try and create a culture of performance amongst designers and developers, but it will all be nought if we could change the minds of people higher up the chain …who currently just don’t care.
I think she’s spot on when she points to this possible solution:
I think what I’m asking is, who will be the game changer in this conversation? Who will be the large, bulky site that will work towards performance and make it happen and then we will all point to them and say, see they did it. It seems to me that that is what it takes. Much like we pointed to ESPN and being able to use CSS for layout or The Boston Globe and being able to do responsive at a large scale, who will we point to for the performance overhaul?
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.
This is a great blow-by-blow account of making an agency website perform better.
I love the side-by-side comparisons with other agencies, including Clearleft—the gauntlet has been thrown down!
I believe that Mozilla can make progress in privacy, but leadership needs to recognize that current advertising practices that enable “free” content are in direct conflict with security, privacy, stability, and performance concerns — and that Firefox is first and foremost a user-agent, not an industry-agent.
More thoughts on the lack of a performance culture, prompted by the existence of Facebook Instant:
In my experience, the biggest barrier to a high-performance web is this: the means of production are far removed from the means of delivery. It’s hard to feel the performance impact of your decisions when you’re sitting on a T3 line in front of a 30 inch monitor. And even if you test on real devices (as you should), you’re probably doing it on a fast wifi network, not a spotty 3G connection. For most of us, even the ones I would describe as pro-performance, everything in the contemporary web design production pipeline works against the very focus required to keep the web fast.
Zeldman looks back at Stewart Butterfield’s brilliant 5K contest. We need more of that kind of thinking today:
As one group of web makers embraces performance budgets and the eternal principles of progressive enhancement, while another (the majority) worships at the altar of bigger, fatter, slower, the 5K contest reminds us that a byte saved is a follower earned.
This Async event at 68 Middle Street on June 11th looks like it’s going to good (and relevant to my interests).
A new podcast for your huffduffing pleasure. It’s all about performance and it’s hosted by Katie and Tim.
A terrific little tool from Tim that puts performance into perspective by measuring how much money users are spending just to view your website on a mobile device.
The slides from Katie’s recent talk.
Performance is a rising requirement for building successful websites, but successful performance begins far earlier than development. So how do you get your entire team excited by it, specifically aesthetic-heavy designers?
A quick drag’n’drop way to base 64 encode your web fonts so you can stick ‘em in local storage.
Google’s experimental new “slow” label could revolutionize how we tackle web performance - Web Performance Today
It looks like Google is going to start explicitly labelling slow sites as such in their search results (much like they recently started explicitly labelling mobile-friendly sites). So far it’s limited to Google’s own properties but it could be expanded.
Personally, I think this is a fair move. If the speed of a site were used to rank sites differently, I think that might be going too far. But giving the user advanced knowledge and leaving the final decision up to them …that feels good.
Tom doesn’t mention the phrase “progressive enhancement” once, but that’s okay—his post is still about progressive enhancement.
FastBoot is coming to Ember. That means server-side rendering. And that means progressive enhancement will become a possibility for Ember apps. Exciting!
I’ve said it before: if your client-side MVC framework does not support server-side rendering, that is a bug. It cripples 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.
Smart thinking here on the eternal dilemma with loading web fonts. Filament Group have thought about how the initial experience of the first page load could be quite different to subsequent page loads.
There are some good points here comparing HTTP2 and SPDY, but I’m mostly linking to this because of the three wonderful opening paragraphs:
A very long time ago —in 1989 —Ronald Reagan was president, albeit only for the final 19½ days of his term. And before 1989 was over Taylor Swift had been born, and Andrei Sakharov and Samuel Beckett had died.
In the long run, the most memorable event of 1989 will probably be that Tim Berners-Lee hacked up the HTTP protocol and named the result the “World Wide Web.” (One remarkable property of this name is that the abbreviation “WWW” has twice as many syllables and takes longer to pronounce.)
Tim’s HTTP protocol ran on 10Mbit/s, Ethernet, and coax cables, and his computer was a NeXT Cube with a 25-MHz clock frequency. Twenty-six years later, my laptop CPU is a hundred times faster and has a thousand times as much RAM as Tim’s machine had, but the HTTP protocol is still the same.
A collection of performance resources: articles, tools, talks, and books.
Some good practical advice from Tim on setting a performance budget.
Use rule-based metrics to make sure you haven’t overlooked simple optimizations.
Use quantity-based metrics as guides to help designers and developers make better decisions about what goes onto a page.
Dave’s great slides from a presentation on performance and responsive design.
Google has updated its advice to people making websites, who might want to have those sites indexed by Google. There are two simple bits of advice: optimise for performance, and use progressive enhancement.
Just like modern browsers, our rendering engine might not support all of the technologies a page uses. Make sure your web design adheres to the principles of progressive enhancement as this helps our systems (and a wider range of browsers) see usable content and basic functionality when certain web design features are not yet supported.
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.
Scott shares the code that Filament Group are using to determine which style declarations are critical (and can be inlined) and which are non-critical (and can be loaded asynchronously). It makes quite a difference in perceived performance.
By the way, I really, really like the terminology of “critical” and “non-critical” CSS, rather than “above the fold” and “below the fold” CSS.
Dave wanted to figure out if having a responsive site necessarily meant taking a performance hit, so he ran the numbers on his own site. It turns out all of performance-related issues are not related to responsive design.
Mark Otto talks through the state of Github’s CSS and the processes behind updating it. There’s a nice mix of pragmatism and best practices, together with a recognition that there’s always room for improvement.
Words of wisdom from Scott on the clash of brand guidelines and the flexible nature of the web:
One thing I am pretty sure of though, is that having a fast, accessible, user-friendly site can reflect incredibly well on a company, and I’d love to see more guidelines and expectations that prioritize these aspects of a service as branding requirements in addition to the usual visual details.
Scott’s trying to find out the best ways to load critical CSS first and non-critical CSS later. Good discussion ensues.
Some sensible thoughts from Addy on how Web Components might be peer-reviewed.
A healthy dose of scepticism about Web Components, looking at them through the lenses of accessibility, security, and performance.
I share some of this concern: Web Components might look like handy ready-made out-of-the-box solutions, but the truth is that web developers have to do much more of the hard graft that was traditionally left to the browser.
A terrific post from Trent, touching on all the important facets of building for the web: universality, progressive enhancement, performance …great stuff!
Excellent tips and tools from Google’s Paul Lewis on performance testing.
A great write-up of the design process behind The Guardian’s responsive site. It’s really gratifying to see UX designers talking about performance.
Some sensible thinking from Tim on measuring performance gains.
Dan gives some insight into what it took to make his personal site responsive. Stay tuned: there’ll be more of this.
Well, this is interesting: it looks like Chrome might stop waiting 300ms for potential double-tap-to-zoom events if the site is using a meta viewport declaration that sets the width to device-width.
The battle between web fonts and performance. Ian Feather outlines some possible solutions, but of course, as always, the answer is “it depends”.
A terrific quiz about browser performance from Jake. I had the pleasure of watching him present this in a bar in Amsterdam—he was like a circus carny hoodwinking the assembled geeks.
I guarantee you won’t get all of this right, and that’s a good thing: you’ll learn something. If you do get them all right, either you are Jake or you are very, very sad.
Jake casts a scrutinising eye over the way that browsers load and parse scripts …and looks at what we can do about it.
Some good thinking from Jason here. In a roundabout way, he’s saying that when it comes to responsive images—as with just about every other aspect of web development—the answer is …it depends.
If, like me, you’ve been using the “export to SVG” plugin for Fireworks and then opening up the resultant file to trim it down, Josh has got you covered: here’s a version of “export to SVG” that will result in much slimmer files.
I find it hard to agree with any part of this. To me, it shows a deep misunderstanding of the web—treating the web as just another platform, without understanding what makes it so special.
I think I may have found my polar opposite.
The hilarious obsession with file size is the start of my frustrations with the web community.
A handy one-stop-shop for tips on improving front-end performance.
This issue of A List Apart is a great double-whammy. Lara Swanson has a ton of practical tips for front-end performance enhancements, and Brian dives deep into making your own icon fonts.
The “client hints” proposal looks really interesting: a way for user-agents to send data to the server without requiring the server to have a library of user-agent strings. But Scott has a few concerns about some of the details.
The slides from Andy’s excellent pragmatic talk on performance and aggressive enhancement at the Responsive Day Out.
Everything old is new again. Ross noticed that many of the themes recurring at the Responsive Day Out hark back to best practices from over a decade ago: progressive enhancement, performance, good ol’ information architecture…
I like the sound of the book that Chris is writing for Smashing Magazine. It sounds like a very future-friendly approach to front-end development.
Some handy tips for simulating slow network speeds on your machine.
This is handy: a look at which DOM properties and methods cause layout thrashing (reflows).
Amen, Brad, Amen.
It’s time for us to treat performance as an essential design feature, not just as a technical best practice.
More details on DNS prefetching, page prefetching and, controversial, page pre-rendering.
A really good introduction to front-end performance techniques. Most of this was already on my radar, but I still picked up a handy tip or two (particularly about DNS prefetching).
At this stage it should go without saying that you should be keeping up with this kind of thing: performance is really, really, really important.
This off-canvas demo is a great practical example of progressive enhancement from David. It’s also a lesson in why over-reliance on jQuery can sometimes be problematic.
An excellent tale of performance optimisation …complete with a coda on looking behind the numbers when it comes to analytics data.