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.
A well-reasoned argument for tackling image optimisation on the server, using content-type negotiation.
I wholeheartedly agree with Christian’s diagnosis of the average web page: it’s overweight to the point of obesity. Fortunately Dr. Heilmann has some remedies.
A great in-depth description by Paul of how he optimised his site. More of this please!
You’ve probably seen this already, but it’s really worth bearing in mind: when you’re scaling up JPGs for retina display you can safely reduce the image quality by quite a lot—to the point of getting the exact same file size as a higher quality image that’s half the size.
The kickass articles just keep on comin’. This one from Dave is a great overview of options for dealing with images in responsive designs.
This looks like a really handy tool for reducing the file size of JPEGs without any perceptible loss of quality (in much the same way that ImageOptim works for PNGs)—available as a Mac app or an installable web service.
This is just wonderful! It combines almost all of my recent obsessions into one unified post: website performance (particularly on mobile) and the locations of undersea cables. The interactive map is the icing on the cake.
Mike compares the bandwidth usage of the sites he most frequently visits. The results are grim.
The worst sins of the Flash years are coming back with a vengeance, in the form of CSS Frameworks and the magic dollar sign. There has seriously got to be a better way to do this.
This is excellent! Scott, Wilto, and the gang at Filament Group have released the tools they use to help them craft performant responsive sites. Lots of excellent resources for conditional loading here.
Some good practical advice on improving performance. This should all be familiar to you, but it’s always worth repeating.
Some sensible advice from Oliver Reichenstein. Cluttering your social media icons isn’t helping and may actively be hindering your audience.
Jason outlines the real challenge to every proposed solution for responsive images: they just don’t jibe with the way that browsers (quite rightly) pre-fetch images.
Time is money …especially when it comes to performance on the web.
An in-depth analysis (graphs! data!) of how popular sites are using—or not using—compression.
Some practical advice for optimising your images on the web.
Wilto gives a thorough explanation of the state of things with responsive images, particularly the work being done at the Responsive Images Community Group at the W3C.
This is my short explanation of Remy’s explanation of a BBC news article which is an explanation of an academic paper about battery performance of mobile devices when accessing websites.
This is a very in-depth look at how to become a power user of the Web Inspector in Webkit browsers. I’m sitting down with a nice cup of tea to go through all of this.
I had a chat with the guys from Pingdom about performance’n’stuff. If I sound incoherent, that’s because this is a direct transcription of a Skype call, where, like, apparently I don’t, y’know, talk in complete sentences and yeah.
Scott walks through the code and thinking behind the conditional loading pattern on The Boston Globe site. This is such a useful and valuable pattern!
A handy performance testing tool from Pingdom, similar to Google’s offering.
Jason reiterates Bruce’s rallying cry: Performance First!
If you could only do one thing to prepare your desktop site for mobile and had to choose between employing media queries to make it look good on a mobile device or optimizing the site for performance, you would be better served by making the desktop site blazingly fast.
Bruce hammers home the importance of speed and performance on mobile (and frankly, everywhere).
So perhaps some of the time and effort put into media queries, viewports, avoiding scrolling, line length would actually be better employed reducing HTTP requests and optimising so that websites are perceived to render faster.
From Kornel, the genius who gave us ImageOptim, comes another Mac desktop tool for optimising PNGs, this time converting 24-bit PNG to 8-bit with full alpha channel.
A script that attempts to detect connection speed (by requesting a test file three times in a row) in order to determine whether hi-res images should be requested or not.
The slides from Chris’s presentation on the known unknowns of the web.
Some very interesting results from testing background image downloads contained within media queries or overridden with media queries: it turns out that, in iOS at least, the browser is getting smarter and smarter.
Stephanie details all the things we have to know about when designing for today’s broad range of devices: performance, capabilities, form factor, pixel density, and network latency.
These are all good points but I worry that if we just concentrate on the current device landscape, our processes won’t adapt to the future.
Oh, this is very handy indeed: a quick lint tool for HTTP so you can see what kind of headers are being sent. There’s a bookmarklet in the footer too.
An in-depth look at browser polyfills: what they are, how they work, and how you can make your own.