This is clever—you can use the
navigator.connection API from a service worker (because it’s asynchronous) which means you can have a service worker script that serves differently sized images based on bandwidth.
Monday, November 27th, 2017
This is clever—you can use the
The Fallacies of Distributed Computing (Applied to Front-End Performance) – CSS Wizardry – CSS Architecture, Web Performance Optimisation, and more, by Harry Roberts
Harry cautions against making assumptions about the network when it comes to front-end development:
Yet time and time again I see developers falling into the same old traps—making assumptions or overly-optimistic predictions about the conditions in which their apps will run.
Planning for the worst-case scenario is never a wasted effort:
If you build and structure applications such that they survive adverse conditions, then they will thrive in favourable ones.
Monday, September 25th, 2017
It looks like this is landing in Chrome. The
navigator.connection.type property will allow us to progressively enhance based on connection type:
A web application that makes use of a service worker to cache resources during installation might have different bundles of assets that it might cache: a list of crucial assets that are cached unconditionally, and a bundle of larger, optional assets that are only cached ahead of time when
There are potential security issues around fingerprinting that are addressed in this document.
Thursday, July 6th, 2017
Geek humour is no laughing matter, as Chris demonstrates here with his thorough dissection of that coffee mug.
CSS is weird. It’s unlike any other code, and that makes a lot of programmers uncomfortable. But used wisely it can, in fact, be awesome.
It’s not often I say this, but read the comments.
Sunday, March 26th, 2017
A lot has been written about the future of journalism, the importance of businesses like the LA Times being profitable as a way to protect American democracy. I agree with that in theory. But this sort of incompetence and contempt for readers makes me completely uninterested in helping their business.
Like Craig says…
between personal data suction and total disrespect of bandwidth, I'm not sure how you can *not* run ad blockers and browse the web— A Walkin' Dude (@craigmod) March 26, 2017
Monday, March 6th, 2017
Bruce widens our horizons with this in-depth look at where and how people are accessing the web around the world.
In this article, we’ve explored where the next 4 billion connected people will come from, as well as some of the innovations that the standards community has made to better serve them. In the next part, we’ll look at some of the demand-side problems that prevent people from accessing the web easily and what can be done to overcome them.
Monday, March 14th, 2016
I hadn’t heard of the
save-data header. This article shows how you can use a Service Worker to sniff for it and serve up smaller assets, but I’m guessing you could also sniff for it from the server.
Tuesday, June 9th, 2015
A comparison of when to use percentages and when to use vw/vh in your CSS.
Sunday, January 4th, 2015
Like an Enid Blyton adventure for the 21st century, James goes out into the country and explores the networks of microwave transmitters enabling high-frequency trading.
If you think that London’s skyscraper boom is impressive – the Shard, the Walkie-Talkie, the Cheesegrater, the Gherkin – go to Slough. It is not height that matters, but bandwidth.
Monday, December 31st, 2012
An excellent tale of performance optimisation …complete with a coda on looking behind the numbers when it comes to analytics data.
Thursday, July 19th, 2012
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.
Wednesday, July 18th, 2012
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.
Monday, March 19th, 2012
A great examination of the default settings for pixel density and how it can effect reported device width values on mobile.
Monday, March 28th, 2011
This code could be useful in determining a user’s bandwidth.
Sunday, March 27th, 2011
I swear there’s some kind of quantum entanglement going on between Ethan’s brain and mine. Demonstrating spooky action at a distance, just as I was jotting down my half-assed caveat related to responsive design, he publishes a sharp and erudite explanation of what responsive design is and isn’t attempting to do. He uses fancy learnin’ words and everything:
When I’m speaking or writing about responsive design, I try to underline something with great, big, Sharpie-esque strokes: responsive design is not about “designing for mobile.” But it’s not about “designing for the desktop,” either. Rather, it’s about adopting a more flexible, device-agnostic approach to designing for the web. Fluid grids, flexible images, and media queries are the tools we use to get a bit closer to that somewhat abstract-sounding philosophy. And honestly, a more unified, less fragmented approach resonates with my understanding of the web on a fairly profound level.
Embrace the fluidity of the web. Design layouts and systems that can cope to whatever environment they may find themselves in. But the only way we can do any of this is to shed ways of thinking that have been shackles around our necks. They’re holding us back.
Start designing from the content out, rather than the canvas in.
Both Ethan and Mark are writing books. I can’t wait to get my hands on them.
In the meantime, I wanted to take an opportunity to clear up some misunderstandings I keep seeing coming up again and again in relation to responsive web design. So put the kettle on and make a nice cup of tea while I try to gather my thoughts into some kind of coherence.
Breaking it down
To paraphrase Donald Rumsfeld, web design is filled with quite a few known unknowns. Here are three of them:
- Viewport: the dimensions of the browser that a person uses to access your content.
- Bandwidth: the speed of the network connection that a person uses to access your content.
- Context: the environment from which a person accesses your content.
With the proliferation of mobile devices, tablets and every other kind of browsing device imaginable, there’s a high number of possible viewport sizes. But here’s the thing: that’s always been the case.
For over a decade, we have pretended that there’s a mythical perfect size that every person will be using. To start, that size was 640x480, then it was 800x600, then 1024x768 …but this magical ideal dimension was always a phantom. People have always been visiting our websites with browsers open to varying dimensions of width and height—the rise of “mobile” has simply thrown that fact into sharp relief.
The increasing proliferation of different-sized devices and browsers means that we can no longer cling to the consensual hallucination of the “ideal” viewport size.
Fortunately this is a solved problem. Liquid layouts were a good first step. Once you add media queries into the mix it’s possible to successfully deal with a wide range of viewport sizes.
Simply put, responsive web design solves the viewport question.
But that’s just one of three issues.
The Filament Group are experimenting with responsive images and I hope to see a lot more experimentation in this area. But when it comes to serving up different-sized media to different people, we are forced to make an assumption. The assumption is that a small viewport equates to narrow bandwidth.
‘Tain’t necessarily so. If I’m using my iPod Touch I’m surfing with a fairly small screen but I’m not doing it over 3G or Edge—same goes for anyone idly browsing on the iPhone or iPad on their work or home connection.
Likewise, just because I’m using my laptop doesn’t mean I’m connected with a fat pipe. When I took the train from Seattle to Portland there was WiFi available …of a sort. And many’s the hotel connection that pushes the boundaries of advertising itself as “high speed.”
Once again, the “solution” to this problem for the past decade has been to ignore it. Just as with viewport size, we engage in a consensual hallucination of ideal bandwidth. Just as with viewport size, the proliferation of new devices is highlighting a problem that was always there. Unlike viewport size, the bandwidth issue is a much tougher nut to crack.
Responsive web design doesn’t directly solve the bandwidth question. I suspect that the solutions will involve a mixture of server-side and client-side trickery, most likely involving clever lazy loading for nice-to-have content. I’ll be keeping an eye on the work of Steve Souders.
In the meantime, the best we can do is stop assuming a best-case scenario for bandwidth.
You don’t know what a person is doing when they visit your website. It’s possible to figure out what viewport size they are accessing your content with and it might even be possible to figure out how fast their network connection is but short of clairvoyance, there’s no way of knowing whether someone is in a hurry or looking to spend some time hanging out on your site.
Once again, this has always been the case. Once again, we have up ‘till now ignored the problem by pretending the person visiting our website—the same person with the perfect viewport size and the fast internet connection—doesn’t mind being served up dollops and dollops of so-called “content”, very little of which is directly relevant to them.
The rise of services like Readability and Safari’s Reader mode demonstrate that the overabundance of page cruft is being interpreted as damage and routed around.
The context problem—figuring out what a person is doing at the moment they visit a site—is really, really hard.
Responsive web design does not solve the context problem. It doesn’t even attempt to. The context problem is a very different issue to the viewport problem—which responsive web design does solve. As Mark put it:
It’s making sure your layout doesn’t look crap on diff. sized screens. Nothing more.
anyone that claims “responsive design” as a best practice clearly has never actually tried to support multiple contexts or devices.
Those are two different issues: contexts and devices. The device issue breaks down into viewport size and bandwidth. Responsive design is certainly a best practice when tackling the viewport issue. But Brian’s right: responsive design does not solve the problem of different contexts. Nor did it ever claim to.
The choice is not between using media queries and creating a dedicated mobile site; the choice is between using media queries and doing nothing at all.
If responsive design were being sold as a solution to the context problem, I too would be annoyed. But that’s not the case.
The mythical mobile context
As with the viewport issue and the bandwidth issue, the context issue—which has always been there—is now at the fore with the rise of mobile devices. As well as trying to figure out what a person wants when they visit a website, we now have to think about where they are, where they are going and where they have just been.
This is by far the toughest problem.
Bizarrely, this is the very known unknown that I see addressed as though it were solved. “Someone visits your site with a mobile device therefore they are in a rush, walking down the street, hurriedly trying to find your phone number!”
The data does not support this. All those people with mobile devices sitting on a train or sitting in a cafe or lounging on the sofa at home; they are all in a very different context to the imaginary persona of the mobile user rushing hither and thither.
We have once again created a consensual hallucination. Just as we generated a mythical desktop user with the perfect viewport size, a fast connection and an infinite supply of attention, we have now generated a mythical mobile user who has a single goal and no attention span.
More and more people are using mobile devices as a primary means of accessing the web. The number is already huge and it’s increasing every day. I don’t think they’re all using their devices just to look up the opening times of restaurants. They are looking for the same breadth and richness of experience that they’ve come to expect from the web on other devices.
Hence the frustration with mobile-optimised sites that remove content that’s available on the desktop-optimised version.
Rather than creating one site for an imaginary desktop user and another for an imaginary mobile user, we need to think about publishing content that people want while adapting the display of that content according to the abilities of the person’s device. That’s why I’m in favour of universal design and the One Web approach.
That’s also why responsive web design can be such a powerful tool. But make no mistake: responsive web design is there to help solve the viewport problem, not the context problem.
Thursday, February 24th, 2011
Yes! Yes! Yes! Mark nails it: just because someone visits a site with a certain kind of device doesn’t mean you can make assumptions about their intentions.
- Mobile != low download speed
- Context != intent
Tuesday, April 20th, 2010
A clear explanation of device-width from PPK.
Wednesday, February 4th, 2009
An excellent write-up by Bruce of a talk he gave at the Betavine birthday party. Down with .mobi! One Web FTW!
Tuesday, September 25th, 2007
This blogging Tory MP is stealing someone's bandwidth for the photo in this post. Said photo has been subtly altered. Hilarity ensues in the comments.
Wednesday, March 28th, 2007
John McCain stole Mike Davidson's bandwidth. This sounds like a job for .htaccessman.