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.
A handy little for calculating your performance budget based on how long you want your page to take to load on a particular connection.
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.
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.”
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!
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.
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.
Some sensible thinking from Tim on measuring performance gains.
Some handy tips for simulating slow network speeds on your machine.
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.
Some good practical advice on improving performance. This should all be familiar to you, but it’s always worth repeating.
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.
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.
I like this ad-hoc approach to staging one-night-only internet art shows:
Hit an Internet-cafe, rent all computers they have and run a show on them for one night.
Performance matters. Here, the Washington Post compares its own weak performance (hampered by ads and tracking shite) to the optimised experience of porn sites.
Performance shit just got real.
You can now sign up with Google to have your site pass every request through them and get your documents served up optimised.
A handy tool for checking page load times.
An online book about website performance by Stoyan Steganov, released into the public domain. Excellent!
Great news! Google Analytics now tracks page load times.
Freaky stuff. If you’ve seen Kevin Slavin or James Bridle talking about the increase in property prices on Wall Street as the buildings get closer to the network hub …that’s nothing—these are the new centres of world power; places where the speed of light interferes least with the speed of transactions.
A supremely useful tool from Google for measuring performance.
This is wonderful stuff: a long-term project to track the performance of high-traffic sites over time: oodles of lovely data and some quite shocking stats.
Two little tips courtesy of Dan.
Brian Suda has a theoretical solution to real-time interplanetary communication: "I get on my tachyon voip phone and make a call from mars to earth at 9:00am it takes 10 minutes to travel there, but the tachyons travel backwards (so i think) that would be