It's worth adding above the fold (ATF) rendering as a technique. It's aim is to deliver pages on mobile within 1 second and requires a fundamental rethink of the way we architect CSS and our reliance on frameworks like Bootstrap. Ilya Grigorik presented the technique at the latest Velocity Conference and Google have now adopted it as recommendation at part of the PageSpeed Insights tool.
I'm currently working on a service in beta to help designers and developer address these issues through monitoring the front-end build of a website over time. Measurement and comparison is the first step in establishing a baseline and then rolling out these techniques and understanding the improvement.
I also discovered CDNConnect recently which looks like a great service to help optimize and generate images at a bunch of different sizes and formats like WebP easily.
As long as there is an option to view the desktop version of the site on the phone (presuming it is usable at all), I don't really care.
It's very seldom I see a mobile version of a site that is better than the desktop version. Mobile versions usually aren't scrollable, so they're much harder to see in overview and zoom into the interesting bit. They usually don't show as much information overall in the interest of reducing clutter, but this makes them harder to scan and navigate.
Mobile Wikipedia commits both of these crimes, and even more annoyingly, mobile Google redirects WP search results to the mobile version, and there's no way to turn this off.
I often want the opposite -- I often prefer the mobile version on the desktop. Especially for news sites like the NY Times and BBC. The pages usually have many fewer distractions.
My take is that sometimes mobile sites are often optimised for simplicity (this is bad), sometimes for content (this is better), and occasionally, rarely perhaps.. for both (this is awesome!).
Too simple can be bad, but I'll take a page optimized for simplicity over one optimized for ads and the "you might like this related article" nonsense of many desktop pages!
However, I am curious about the research showing that users will leave a website after 3 seconds. Where was this measured? On desktop, or on a low-end/low-bandwidth device? With low-end devices and/or low bandwidth, most websites will load slowly, and my guess is that performance expectations will be different than on desktop.
That "study" is bullshit. It's actually a survey asking people after how many seconds they will leave the site. I'm now expecting them to find cure for cancer by popular vote.
You're right but let me tell you this:
Half of the visits the article got since publishing have bounced off after close to 2 seconds. Coincidence? It´s a shame but I do this too
You do what too? Conflating correlation with causation? We all do that at one point or another :)
Speed is no doubt important but it's only a part of the big picture. The site I'm maintaining has roughly 60% bounce rate. If I'm to take the "study" at face value, that means all of those bounces are due to 3+ sec load time. And if I somehow manage to bring that to 0.1 sec (preferably using Akamai's services), the bounce rate will magically go to 0%. Of course, that doesn't happen in the real world.
Btw, great article, thanks for taking the time to write it.
"To do this, there are heavy tools out there, like WURFL, DeviceAtlas or lighter ones like Browser Gem, that read the user agent string and start from there."
All this time we were told 'browser detection is bad', yet... the only real way to give optimal experiences for mobile is... 'browser detection'.
In theory, browser detection is bad, because we should rely on detecting whether JavaScript functions exist or not, etc.
In practice, browser detection is usually necessary, no way around it. Thinking about writing HTML5 audio functionality? Guess what, every browser implements it differently, and you just have to detect the browser so you know whether to respond to the 'ended' event or the 'pause' event, or whether calling load() before playing is necessary, or will crash a certain mobile browser. (I could go on about 100 more things.)
So, in an interview, always explain that browser detection is bad. Once you're hired, you'll find that most reasonably complex sites use it out of necessity.
Yes! When I saw that I nearly closed the page then and there. Frankly, anyone advocating this has likely never tried to do it. In my experience the data goes out of date almost instantly anyway, the technique is not fully reliable and if you start going down this rabbit hole you realize there are so many varied devices to take into consideration that it becomes pointless anyway.
This also completely contradicts what I thought was the entire point of the article.
I hear you, but I think it's a mistake to take things like "browser detection is bad" as inviolable axioms. These sorts of best practices are results-oriented, so when we want different results, we have to reevaluate them. I am not necessarily saying browser sniffing is now an awesome idea, though.
I was under the impression that tracking users by uniquely identifying them by their browser was bad, not merely detecting their browser and its properties? Or did I miss something?
No, you didn't miss anything. It's just that... for years, we got "browser detection is bad" thrown at us. I realize I'm conflating things a bit, but personally I never did anything like "if useragent=='mozilla' redirect to 'we only support ie.html'", although many did (back in the day). "browser detection" got a bad rap, and had been "out of favor" for a long time (or appeared to be). Yet... the only way to avoid sending down a 400k of HTML to a mobile device is to... detect the device and send down smaller amounts of stuff.
It's "bad" because its very difficult to plan for all of the extreme edge cases found on the net. If UA Sniffing was infalliable, there would be a lot more of it.
Enabling/disabling features by user agent tends to break over time. Browsers implement features, but your user agent sniffing keeps them disabled.
Or as I get a lot, you use a non-standard but standards-compliant browser and then have to spoof the user agent of one of the major browsers to persuade the site to actually use the features your browser has.
It's a really unfortunate naming convention. "Responsive" is a perfectly good, versatile English word that I can no longer use in the context of websites.
Maybe "flexible design" would've been better. Or something more specific and descriptive.
It is very clear that this method is still in infancy and we should not be expected to be able to fully accommodate everyone right now. We are working towards a solution.
The fact the DOM is parsed regardless is not a massive issue to me, as mobile browser speed increases this will become a non issue. The issue really is the images, there needs to be some way of telling the browser to completely ignore the image on certain media types, or at least defer the load if it is not meant for this media type then load it last.
There will eventually be a standard for responsive web design but at this moment in time people are doing it the best they can with the tools they have
I agree that performance is a design feature. The days of the non developing designer are drawing to a close.
I still don't buy this "Design for Mobile First" idea though, for a couple of reasons.
- Your first media query is no media query
- This mobile up approach means your responsiveness is dependent on Javascript, which smells funny to me.
- Most websites don't live that long, and desktop users still account for the lions share of traffic. If you had to pick one, you'd probably pick desktop. So it makes sense to me to start there.
- I personally find it easier to work backwards towards mobile. But that's just me.
> This mobile up approach means your responsiveness is dependent on Javascript, which smells funny to me.
Hm... I don't see how a mobile first approach depends on javascript. In my experience, it's quite the opposite, in fact. Mobile first is all about progressive enhancement and starting small. Granted, many web devs build their sites in a way that doesn't work w/o js, but IMHO, this should be the exception not the rule.
> Most websites don't live that long, and desktop users still account for the lions share of traffic. If you had to pick one, you'd probably pick desktop. So it makes sense to me to start there.
If designing mobile first meant "build two websites, and the first one you build should be the mobile one" then I might agree with you. But using RWD means that you only need to have one site, and that it will work across mobile and desktop. Because of the was CSS works, it's just way easier to start with a bare bones style for small screens, and use min-width media queries to progressively add more complex styles for screens with more real estate.
> I personally find it easier to work backwards towards mobile. But that's just me.
I'm shocked to hear that, but obviously can't argue; your experience is your experience. I teach RWD classes, and without exception, students who have dabbled in RWD have had a really hard time trying to shoehorn a desktop site into a mobile format using RWD principles. It's not impossible but it is really painful. I've worked on responsive sites for some of the biggest publishers in the world and I can't imagine how would could have worked from desktop down to mobile. This is because CSS is much easier to use in an additive fashion, as opposed to subtractive.
Remember, sites like Facebook get more hits on mobile than they do on desktop.
Mobile includes more than phones, it also includes the rapidly expanding tablet form factor.
I think it would be wise to understand where your traffic comes from and how your audience consumes what you provide and pick the best solution for you.
If 70% of your users access your service over mobile, prioritizing desktop over mobile seems very backward! But that's just me.
I think what has to be considered here is how we view the future of the desktop vs. that of mobile. With the ever growing numbers in the mobile space along with tablets and other devices, I don't see desktops being as widely used/valued. Major companies are shifting their focus to these other devices which means more apps, which means more functionality, which means more possibilities, which means less need for desktops. So I think this is where the idea of "Design for Mobile First" is coming from.
I see how you could be concerned with the use of javascript but that is part of the progressive enhancement escalation, you just put it on top of your 'ready goodness'!
Also you might be half right about the lions share of traffic. But be sure to check videos by the great Karen McGrane (like this awesome one: http://vimeo.com/50609566). She can argue that most of the new population in occidental first world countries and most of the population in the rest of the world uses mobile as their primary point of access to the internet. To them, mobile is the internet! As she says, if you don't put it on mobile, your content doesn't exist for this people
I think you have a fundamental misunderstanding of RWD somewhere along the line. Your first point is the entire point of mobile-first design. Old and less capable browsers, such as older version of IE don't understand media queries, so they get the "simple" non-media-query, mobile-optimized site and you avoid problems with patching CSS3 queries on browsers which don't support them.
There's absolutely nothing about mobile-first design that makes your site dependent on JavaScript.
Third point depends ENTIRELY on the site, but your logic doesn't really follow. If I only had to pick HTML or CSS, I'd pick HTML. That doesn't mean I'd launch a site with only HTML and no styling. You're creating a false dilemma.
> This mobile up approach means your responsiveness is dependent on Javascript, which smells funny to me.
How so? In my experience it's the complete opposite. You certainly don't need any JS to make a responsive site, besides responsive images if you need it.
The whole point of mobile first is to get low site load, low http requests, JS only when necessary, etc, as to not keep anyone from accessing your content.
I think you have a really distorted view of what mobile-first design is.
I have an old WinPhone with a weak processor that only loads the current tab. This makes tabbing the browser functionally pointless.
Heavyweight responsive websites are unusable. I have to wait indefinitely for page to load, and there's no way to make it load in the background. In the rare cases where the pages progressively display, scrolling is still agony as elements jump around constantly.
While I realize I should probably get a new phone, I'd wager I'm not an edge-case and a lot of users with older or bargain-bin phones face this kind of frustration.
I completely agree. More than a few of the Web people (perhaps most?), though, are moving towards more complicate systems, more expensive design.
To me the way forward should be optimization of sites. I don't know where you use your phone but most of the people using mobiles to access internet lack any sort of bandwidth.
So, if you are a company, this people basically don't have access to your content
I believe mobile is currently about 18% of web usage market share, and windows phone is about 2% of mobile, so your situation is probably less than half of one percent of users - well below the level where specific support is economically viable, especially since it would probably require a lot of work.
As you said, the solution is for you to get a new phone.
I don't mean literally supporting the dead-ended WP7, but the general category of "old/cheap smartphones that scream and fall over dead trying to render your page".
Ah, I see what you mean. Yeah, that's a bit obnoxious, especially when it's something as gratuitous as a slideshow or something with CPU-hungry fading eye candy.
How does mobile first solve Excess DOM? As soon as you extend it to desktop you will have the same amount of DOM elements. Are you not supposed to use media queries?
It doesn't, directly, but you could argue that when designing/building a website with mobile at the forefront of your thought process, you should end up with a less-excessive DOM, as you begin by building the simplest (i.e. mobile) UI, first.
What if there was a way server-side to look at the CSS and HTML and strip out the elements that won't ever be visible on a specific client device? A bit of HTML and CSS parsing, as well as knowledge about the client, and voila: less HTML (and CSS?) to the device!
This way as a developer you still have one HTML page, but smaller devices don't ever get non-visible DOM elements.
Instead of setting `display: none` with CSS media queries, make a function to rip out elements with a class like `onlyBig` from the DOM, or better yet, use client side templates and only inject the DOM elements appropriate for that screen to start with.
Great article! Images are a huge bandwidth hog. There is absolutely no need to send desktop sized images to mobile users just to be down scaled by browsers. While new markup standards such as srcset (href="http://www.w3.org/html/wg/drafts/srcset/w3c-srcset) and the picture element (http://www.w3.org/community/respimg/) are trying to help, they still place an additional and unnecessary workload on designers...and they primarily consider screen resolution and size.
Designers should let the server side start helping them solve front end problems.
We've developed Pixtulate (http://www.pixtulate.com) to right size and optimize images on the fly before they are sent over the wire. Each visitor, mobile or not, gets the right image for them.
The author is right though, lazy loading of content is key!
Excellent post. My concern with RWD is the page weight. Whilst with the proliferation of 3G and 4G this has somewhat been negated it still leaves a lot to be desired. I dont believe an 'App' is the answer and the original answer, separate mobile sites still feels attractive (both technically, page weight, delivery and recruitment)
In case you missed steve souders wrote about domain sharding recently - http://www.stevesouders.com/blog/2013/09/05/domain-sharding-....
Domain sharding combined along with dns prefetching is also one of the techniques you might want to look into if you have high number of requests.
Check out amazon and etsy to see how they are using it :)
Kudos for mentioning inject after load for third party assets. We are a third party monitoring service yourselves (http://fueldeck.com) and we defer loading our script till page load to make sure user experience is not affected. Our customers don't have to worry about that.
That doesn't strike me as too much of a tragedy - a fast site will only get faster on a fat connection. Plus, who knows when bandwidth caps are going away. Maybe never.
For one value of "better": better compression ratio.
LZMA is also much more expensive than GZip (2x CPU when decompressing, 3x to 6x when decompressing) and uses 2 to 100 times the working memory (when decompressing, the compression is worse). GZip also has more or less constant working memory where LZMA2's depends on compression settings.
LZMA2's use case is thus a bit restricted, mostly pre-compressed static assets (ideally not used on mobile devices)
Compression is done on the server, and (hopefully) once per unique response, which is then cached.
Decompression is fast. I don't think memory is an issue when we're talking about decompressing some HTML/CSS/Javascript, considering it only is required for a few milliseconds to do the work.
CPU is barely an issue, considering how powerful modern mobile devices,
New phones seem to have as much power and as much RAM as my 5 year old PC.
> Compression is done on the server, and (hopefully) once per unique response, which is then cached.
Only works for low-dynamicity response. Or fully static assets.
> Decompression is fast.
I quoted numbers. LZMA decompression takes twice as much CPU time as gzip in the best case.
> I don't think memory is an issue when we're talking about decompressing some HTML/CSS/Javascript
Memory is not a function of payload size in compression algorithms, it's a function of compression parameters. xz -9 will have ~65MB of memory overhead regardless of the payload size (and LZMA is flexible enough that you can craft a single payload requiring gigabytes of working memory, xz's man even warns about it).
> CPU is barely an issue, considering how powerful modern mobile devices
CPU transitions are extremely aggressive on mobiles. The more CPU time has to be spent decompressing payloads the less the CPU can be in deep hibernation state and the more battery you burn through.
Not a tradeoff which makes much sense considering >3G bottlenecks tend to be latency and processing more than bandwidth for "basic" HTML/CSS/JS web content (and really most things outside of video streaming)
> New phones seem to have as much power and as much RAM as my 5 year old PC.
Phones usually can't page out, and aren't tethered to a wall.
Also depends which "new phones" you're looking at, the Firefox OS-based ZTE Open has 256MB RAM and a 1GHz single-core Cortex A5.
For me, the difference in CPU between gzip and lzma is more expensive than the bandwidth difference. I'm much more often processing constrained than bandwidth constrained.
http://www.youtube.com/watch?v=YV1nKLWoARQ https://developers.google.com/speed/docs/insights/mobile
I'm currently working on a service in beta to help designers and developer address these issues through monitoring the front-end build of a website over time. Measurement and comparison is the first step in establishing a baseline and then rolling out these techniques and understanding the improvement.
http://speedcurve.com/
I also discovered CDNConnect recently which looks like a great service to help optimize and generate images at a bunch of different sizes and formats like WebP easily.
http://www.cdnconnect.com/