Responsive Design is Not About Screen Sizes Any More

In March 2012, Guy Podjarny ran a test comparing the performance of hundreds of shiny new responsive websites across four different screen resolutions. The results were very disappointing.

Two years into the rise of responsive web design, after every imaginable sort of designer and developer had jumped into the train, it took a test to almost rock the theory to its foundations.

Guy proved that almost every known responsive site was overweight.

“We’ve made the internet in our image… Obese”
~ Jason Grigsby

But, more importantly, every mobile user was receiving the same kilobyte overload as a desktop user.

The community had varied reactions to this. Some claimed responsive design wasn’t the ultimate solution, perhaps not mature enough for the challenges web designers face today.

Thankfully, the Web community can always count on a number of people who will grab the bull by the horns and turn the situation around.

Modern Web gurus like Brad Frost, Luke Wroblewski and Christian Heilmann saw opportunity where others shouted crisis and managed to turn the problem to the community’s advantage.

“If your website is 15MB, it’s not HTML5, it’s stupid”
~ Christian Heilmann

Web performance has traditionally been built around (no offense) developer-exclusive jargon. Terms like GZIPing, uglifying, minifying, DNS Lookup, file-concatenation… These obscure words push designers out of the equation.

Smart people in the community, though, have since realized that the problem has a deeper root. It really doesn’t matter if you optimize or compress an ultra-high-res image, if your plan is to hide it from a mobile user and still make them download it.

“Good performance is good design”
~ Brad Frost

To achieve truly lightweight sites, performance shouldn’t only be a concern, it should be treated as a design feature.

Performance is like any other issue. Sites that overcome it are the ones who acknowledged it from the beginning. And the ones that overlook it are the ones that suffer for it in the end.

“Performance is about respect. Respect your users and they will come back”
~ Brad Frost

The Why

Page Abandonment

Research shows 57% of users will leave your site if it takes more than 3 seconds to load.

57% of users will leave your site if it take<a href=

Google, Page Speed & SEO

As of the spring of 2010, Google took speed in to account as a ranking factor. The impact is not major for average-speed sites, but if the page falls behind a certain threshold, it will be punished by the company’s search algorithm.

This proves that speed is a concern when talking about User Experience.

Bandwidth Considerations

Back in the day, people used to talk about the very abstract concept of ‘Mobile Context‘. Google’s famous theory breaks mobile users down into three types:

  • Repetitive Now: People that use their phone to stay up to date with ongoing, repetitive changes (sports scores, Facebook feeds or stock market)
  • Bored Now: Users that take their phone out while waiting for something to happen
  • Urgent Now

Sounds assumable, right?

Well, the truth is there is no truth about this. There is no ‘mobile context’. People will use their phone when they are walking in the street, traveling by train or relaxing in their home. They do everything at the same time!

Phones follow people everywhere, so people use them anywhere.

“Mobile context is important, but first we need to figure out what the heck it is”
~ Tim Kadlec

Luke Wroblewski highlights some really interesting stats:

Where are people using mobile devices?

  • 84% at home
  • 80% during miscellaneous downtime throughout the day
  • 76% waiting in lines of waiting for appointments
  • 69% while shopping
  • 64% at work
  • 62% while watching TV (alt. study claims 84%)
  • 47% during commute in to work

As new situations emerge, as new markets and different habits rise, mobile context will change. We can safely assume that the concept of mobile context will always be on the move until people stop using mobile phones.

This leads us to keep an eye on bandwidth. There is only one scenario where you can serve users an obese website and get away with it: serving it to their Macbook Pros, while they are at home with full bandwidth.

But all the rest of the possible situations, which are a great many, have to be covered as well. These include the seemingly endless stream of devices poured every day into the market. Which, of course, people use to visit websites.

“You don’t get to decide which devices access your site, your users do”
~ Karen McGrane

They include the countries that didn’t have that many smartphones a few years ago, but are now ruthlessly moving forward.

“If your stuff, if your content, if your information, if your products, if your services are not available on mobile, they don’t exist for these people”
~ Karen McGrane

But more importantly, they include all the places people will be when using your site. So you have to watch all bandwidths. It’s not only the inhabitants of the poor areas of the world that don’t have the same data-speed. Users will try to access a site at work, with a 100mb/s connection; at home, with 2 to 30mb/s and also with 3G, and also with 4G, and also with a data plan, etc., etc.

To put it bluntly, Responsive design is not about screen sizes any more, but about different scenarios, so the solutions must be flexible, adaptable and thought out top to bottom.

And How?

Well, glad you asked.

We said before not to look at performance as a bunch of automated tasks running server side that help with an already doomed site. There are ways to undertake these concerns and turn them into a competitive advantage.

What to avoid

Guy Podjarny cites three key reasons for the number of bloated responsive websites we see out there:

  • Download and Hide: Assets are still downloaded, but hidden
  • Download and Shrink: High-res desktop-level images are downloaded, and shrunk to fit the users screen
  • Excess DOM: There is no way to avoid browsers parsing and processing all areas of the DOM, including the hidden ones

A Preemptive Approach

There’s a great deal of information out there about why websites keep failing to surpass expectations in performance. But what most people come to say is something like ‘be responsible from the start’.

All techniques I’m going to cover have been around for a while. To me, the interesting part comes in how they mix and intertwine, covering each other’s flaws and combining their strengths. It is now, deep in the mobile explosion that they show how powerful they are.

Progressive Enhancement…

…is all about providing a web experience reduced to the essential and taking it from there.

A couple of years ago this theory was taken mostly from a browser point of view. With emerging technologies like HTML5, CSS3, jQuery and so on, the web makers had kind of forgotten about their users. Quite a big percentage of them were getting an incomplete form of their site, relying a bit too much on this shiny new tech.

Now that Webkit engines and Firefox and others have taken over much of the market share, the problem is the enormous quantity of devices with browsers that don’t have the capabilities of the iPhone or Samsung. Again, Progressive Enhancement is the only approach which takes care of these forgotten players first and leave the shine for the ones that can take it.

Mobile First Development

Back in 2009, Luke Wroblewski proposed designing mobile first for three reasons:

  • Mobile is exploding
  • Mobile forces you to focus (allowing you to get rid of the clutter that stems from having too much screen real estate)
  • Mobile extends your capabilities (with technology like GPS, geolocation, multi-touch gestures, accelerometer, cameras…)

Since then, Web design has been rapidly shifting to this approach. Along the way many designers, and many developers have pointed out that building mobile first gives you an edge over desktop development (highly related to Luke’s second point above). Progressive Enhancement and Mobile First Development have suffered a fusion of sorts. Devs start building for mobile and progressively enhance from there, taking larger screen space as an enhancement over a mobile core foundation.

Jordan Moore offers a good summary of the reasons. He argues that, since we can’t safely bet on connection speed, the ‘responsible web designer’ would build for the lowest point of entry – a mobile-first approach, assuming for the slowest connection speed and building up from there to larger breakpoints for faster connections. In the future, we will be able to rely on solid bandwidth detection, but for now it is a good idea to take it as a concern and try not to take any steps in the wrong direction.

To Sum Up:

Code the site for the lowest resolution and possibilities. Make true use of Progressive Enhancement from the start. Build extra functionality, enhanced visuals and interaction when it can be used.

RESS: REsponsive Web design + Server Side components

To many people, responsive design has one major shortcoming. It relied mainly on screen width detection.

As more and more types of devices emerge, hybrid devices like touch screen laptops and so on, feature detection has become essential for responsive design. Libraries that provide it, mainly Modernizr, have bloomed and are now used on most projects. They help devs evaluate whether the client’s browser supports certain functionality and provide it accordingly. But many times it’s tricky to rely on browsers, because ‘they’ will say they support features when, really, ‘they’ do whatever they want. Support for new features is usually partial.

RESS was born to provide a solution. Like mobile first, the term was coined by Luke Wroblewski in 2011. It relies on detecting the user’s device type, evaluating it and providing an experience tailored for 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.

Evaluating the device type has other advantages. It allows devs to serve different templates depending on the user’s device. Say you are building a very large site, and you want your mobile navigation to be a simplified one that doesn’t take half as much space as the desktop one. You could either play with content, showing and hiding stuff, moving DIVs around with JavaScript, or you could have different templates for mobile and desktop screens and have the server decide which one to serve.

This gives responsive design an edge over Mdot sites. Mdot’s only advantage, until RESS came along, was providing an experience specific for mobile devices.

The BBC (very smart people, with millions of readers across the globe and a big responsibility toward their users) talk about how RESS and Progressive Enhancement could work as one and only. They call their approach Cut the Mustard!. It consists of creating a core experience that will work on every device you can imagine. After that, they evaluate the device on the server and they decide whether or not it ‘Cuts the Mustard’. If it does, a progressively enhanced experience is handed out. But again, if it doesn’t, the user can still access the core content.

Conditional Loading

“Mobile users want to see our menu, hours and delivery number. Desktop users definitely want this 1mb png of someone smiling at a salad”
~ Mat ‘Wilto’ Marquis

Let’s take a couple of points of view into account:

  • Mobile users want THE content, as much as desktop users.
“If your content is accessible from a URL, it will be accessed by mobile devices”
~ Brad Frost
  • Mobile forces you to focus. There are some constraints designers have to embrace to serve the same content, like bandwidth and lesser screen size.

Also referred to as ‘Aggressive Enhancement’, this development technique allows designers to focus on the core content and progressively enhance it for bigger screens. It provides basic access to certain content that can later be injected on the page as space becomes available.

“It might be more accurate to think of conditional loading as a content-first approach. You don’t have the luxury of sidebars or multiple columns to fill up with content that’s just nice to have rather than essential”
~ Jeremy Keith

You can use excellent tools like MatchMedia that mimics CSS behaviour and evaluates screen size in JavaScript.

Lazy Loading

Image and user heavy sites that need to be optimized for mobile, like Facebook, Twitter or Pinterest, make use of lazy loading to provide a better experience. When you first load the page, a number of posts are loaded. When you scroll down, the designer assumes it is because you want to browse through even more content, so it is injected in the page via Ajax. This makes the page load much faster by avoiding DOM excess.

Setting a Performance Budget

Tim Kadlec argues that setting a maximum page weight and being always aware of it is the ultimate way to keeping page load down. ‘Set your goals and stick to them’. Steve Souders discusses three options to choose from, if you fall over your budget:

  • Optimize an existing feature or asset
  • Remove an existing feature or asset
  • Don’t add a new feature of asset

To me this sounds a bit radical, but it makes a point of closely following the overall performance of a site over time and with each new feature.

Let’s Get Technical!

There are certain speed methods that work in a more technical and less conceptual level.

Image Techniques

Images constitute around 60% of websites. If you are serving mobile users with unknown bandwidth connections desktop-sized images, you are basically dooming your site to poor performance.

The trick to overcoming this is to serve different versions of images, depending on screen size or type. You would serve a small image to a mobile phone, a high-res one to a desktop and you would serve a double-sized image to a Hi-DPI device.

Responsive Images

Designers and developers all over the world have been fighting to get responsive images into the HTML specification. Mat ‘Wilto’ Marquis is one of the most outspoken. The battle is not yet won, but there are a number of solutions that rely on JavaScript to achieve a desired result. Scott Jehl, also from the Filament Group, wrote a plugin that mimics the markup proposed by the community and works like a charm: PictureFill.

Compressive Images

Daan Jobsis, a dutch designer, found a very strange phenomenon when compressing images with Photoshop. He proved the following: Take an image, double its size (200%), compress it to 25% or less its original quality, resize it back in the browser(100%). The image will not only be lighter in size but already optimized for HiDPI screens, since its pixel density is already doubled.

The only observed problem is that the browser might have a hard time painting a double-sized image back to its original size (if it has to do it a hundred times, like in image-heavy sites). A little bit of testing is required to see if this is the optimal solution.

Vectors VS Bitmaps

SVG images are the way to go at this time. They are completely scalable, so will perform better on any screen. Providing fallback is very easy through Modernizr.

Icon Fonts

Technically they are vector based images, only served as a font. As Chris Coyier puts it, ‘Icon Fonts are Awesome’ because:

  • You can easily resize
  • You can easily change the color
  • You can easily shadow their shape
  • They will work in IE6, unlike transparent PNGs
  • You can do everything you can do with images
  • You can do anything you would do with typography

HiDPI Images

Dave Bushell wrote recently a very interesting article with some thoughts on HiDPI images. He argues that, even if today we have the possibility of serving iPhones, iPads and other modern devices with images that fulfill their screen capabilities, it is still too soon to assume a site is not going to get crippled by doing it.

“Does a fast connection and high pixel density mean users even want higher quality? Not likely on mobile data plans”
~ Dave Bushell

The point is to do it but do it sensibly, considering the case before jumping into 4x images.

What’s Next

Google recently developed a new image format, WebP. It provides lossless compression for web images, resulting in files 3x smaller, compared to PNG.

There are simple, lightweight JavaScript libraries that convert to and from WebP that are available today. Considering the impact of Google’s latest tools, it’s probably a good idea to start experimenting today in order to handle an image-heavy site.

Asset Loading

Load assets carefully and in order. Controlling this aspect provides a big advantage, by allowing the page to render the basic content and enhance it afterwards.

CSS, Images

Controlled loading through media queries, conditional or lazy loading and responsive / compressive image techniques

JavaScript

Make use of HTML5 functionality, like async or defer. There are also loading helpers like RequireJS that can handle loading and dependencies.

Advertising, Social Widgets or any third party assets

Just inject after load.

Old-school Performance Techniques

They have been around for a while, but are still just as relevant today.

Reduce the number of HTTP Requests

To achieve this, devs have to think resource by resource, but here are a number of guidelines:

  • Concatenate all CSS files or make use of CSS Preprocessors to compile them into one file.
  • Unify all JS Plugins under the same file and always load them in the footer, unless they really need to block the rendering of the page (if you load Typekit fonts in the footer, you will get the famous FOUT or ‘Flash of Unstyled Text’).
  • If you must use PNG images, use sprites. They unify all images in one and make use of CSS to cut the pieces.
  • Make use of the data URI scheme where possible, that allows you to include images as inline data, getting rid of some more HTTP requests.

Reduce the number of Bytes

Uglify, minify every script or CSS file you call from the page. Set your server up to allow GZIP compression and expansion and GZIP every asset.

In Summary

The importance of Web performance has been slightly overlooked since the birth of responsive design.

Designers and developers have been focusing on how to solve the responsive puzzle and, along their way, a new multi-bandwidth, multi-device, multi-location web is starting to come into focus.

To be prepared for tomorrow’s problems, we have to include performance as an essential consideration, as the desktop-centered web is disappearing before our eyes. The mobile user is hastier and readier and won’t jump through hoops to get the content, and since more and more sites spring up every day, being fast will mean being ahead.

(1 Posts)

Gorka Molero (gorkamolero.com) is a self-taught web designer, musician and sound engineer and heavy Internet enthusiast. He believes in the universality of the web and the free-flow of information, regardless of platform or situation. He is moved by innovation and originality, despite the time or the field, and tries his best to keep up with cutting-edge technology and always stay tuned to artistic and technical vanguards.

Comments

  • Raphaël BECK

    Most solutions rely on Javascript but most of the time there is no mitigation in the case the Js is disabled. Do you think is it valid to cut from the non-javascript audience or is there a solution for this particular case?

  • Mark Zeman

    Great write up Gorka. You might want to add 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.

    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. I’d love some more responsive designers to help shape the service.

    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 easily.

    http://www.cdnconnect.com/

    How about adding a tools sections with services like these, WebPagtest and others?

  • jordanmoore85

    Thanks for the mention, minor correction — my Twitter handle is @jordanmoore, not “JMOIAM”. Thanks!

  • Paul Andrew

    Sorry about that Jordan, I just fixed it :-)

  • tl;dr Responsive design does not solve other design problems

  • Igor Faletski

    Great article, Gorka! A lot of the optimizations you’re talking about can be made instantly using the developer platform we’ve built at Mobify (http://cloud.mobify.com). Hope that’s helpful!

  • jordanmoore85

    Awesome, thank you sir :)

  • Pants

    Don’t forget ImageOptim!

  • Gorka Molero

    I’ll check it out, thanks!

  • Gorka Molero

    Wow. That actually looks great.
    I’ll add these to the post as soon as possible, time to investigate a little!

  • ZoubIWah

    i don’t want the fucking salad even on desktop ;-) desktop users also want content. so just focus on content and performance. Everyone will be happy.

  • Gorka Molero

    Will go into the tools section!

  • Gorka Molero

    If it were up to me I’d cut with them but you know…

    Ethan Marcotte did a beautiful talk this year, called ‘The Map and the Territory’ (http://vimeo.com/63525054). He pointed out how lots of people in Africa and other ‘undeveloped’ regions of the world (what a horrible term, ‘undeveloped’), still use WAP to access Internet. And there are some very smart folks who built incredibly useful apps that helped them find drinkable water…
    In some cases, like in my company, the whole site relies on JavaScript, but who knows if we actually have to take a step back on this…

    There are things you can do today though, like using the BBC’s ‘Cut the Mustard’ technique. Serve basic content that works anywhere, anytime, on any device, and then enhance for browsers that meet the capabilities

  • Gorka Molero

    Thank you for your idea!

  • Really great summary – aggregating bits and pieces I’ve read elsewhere, but this is a really good, focused piece.

    BTW, under the section titled “What to Avoid”, the List Item tag is broken such that “Download and Shrink” isn’t on a separate line as it should be.

  • Tim

    On HiDPI images… no one should use these on a website. I’ll tell you why….Copyright.
    I’m an artist and I have had numerous issues with people stealing my work and using it on their own websites or even on printed materials, such as flyers and even CafePress products!
    People are not honest. That’s just the way it is. Give them even more resolution than 72ppi and you are asking for a world of trouble with people ripping you off (if you’re an artist or designer). I will NEVER use anything higher than 72ppi on my own website…ever.

  • Christian Jensen

    Your article is full of great information, but perhaps you could indicate what is condoned and what is not. I found myself trying to figure out what is considered good and bad and at times it flip-flopped.

    My suggestion is to put an indicator, a table or something listing out the good parts from the bad.

  • Graham Mueller

    I feel like you’re not the average website use case. The majority of sites use content that is either not owned by them (legally or otherwise), or use images they likely don’t mind having lifted (like their branding images). In that case, they would want the highest quality images for the users.

    In your case it seems like you would just want to put a disclaimer up stating that the images were intentionally put up at lower resolution. That, or you could do something crazy like putting a splash on the images, like many other sites with Copyrighted content do.

  • sep332

    While you’re at it, your Daan Jobsis link is also broken.

  • jason

    I think the criticism of responsive design here is right on. I’d add on other thing- while there may not be a mobile context, users absolutely do behave differently on mobile. Most wouldn’t hesitate to tweet on a phone, but not many would write a full blog entry on a phone. So, the responsive designs approach of just shrinking the content isn’t right, and not just because of page load weights and times- you have to have a different product on mobile because the user goals are different for many browsers. Furthermore, the huge list of tweaks suggested in this article means the you aren’t reaping the benefits of have a largely shared code base with just a few tweaks for mobile, the delta is large enough… to warrant just building separate mobile and desktop versions of your site.

    The approach computer science has taken to this class of problem is to modularize. Having multiple execution paths within a single context leads to lots of issues. Ultimately its hard to reason about- one context bleeds into the other- and, in this case, you start pushing mobile phones images optimized for laptop retina displays. Its a temporary expedience with negative long term repercussions, which we are seeing emerge as this article points out. A modular solution would be to have an api which serves both the mobile and the full version of the view layer (html, css, js, images, fonts, etc).

  • Excellent writeup! I’m working on a framework called conditioner.js (http://conditionerjs.com) which sits on top of RequireJS to handle realtime progressive enhancement and conditional loading of modules. You might like it, it ties in to a lot of the topics discussed above :)

  • virtualCableTV

    Maybe paper was not such a bad idea after all.

  • Marcus Ellis

    So, you put High Res images on the internet with no watermark or any other such “protection” and are angry that other people have appropriated your images for purposes you didn’t approve. And you’re angry about this? Really?!? I suppose you also leave your car unlocked with the keys in the ignition, and expect it to be there when you get back…

  • 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 and the picture element 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 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. While we do leverage WURFL for device detection, unfortunately it is much less accurate than relying on client side javascript to detect client capabilities and constraints.

    Gorka is absolutely right though: “It really doesn’t matter if you optimize or compress an ultra-high-res image, if your plan is to hide it from a mobile user and still make them download it.”. Lazy loading is key!

  • Great read thanks. A lot to take in there, but a great article.

  • Gorka Molero

    As William says above, Responsive design does not solve other design problems.

    It’s hard to give a general overview of what would work in each case, you’d really need to talk about something more specific.
    Take the webapp I’m doing now. We’re redesigning a betting website top to bottom, and along the way we are learning that the actual betting is very different on mobile than in a big screen.

    At first we just tried to make the content adapt and that proved an OK solution. Barely OK if you want to bet from the bus.
    Suddenly we were confronted by the possibility that many people use their phone at the same time than their computer. So now we could think of a mobile, in a different context, as a kind of controller, and the whole mindset changes.

    The possibilities are endless, but it really really depends on the case. I´m sure you can find reasons why serving a separate mobile site is more intelligent as an interim solution.
    The Guardian does this, for example (it´s the Guardian right? Correct me if I’m wrong). They are basing their responsive redesign on their mobile-centric website and expanding from their.

  • Simon Hermann Hector Goellner

    wow, great collection, every web developer and designer should read this !

  • Raphaël BECK

    I’ll watch the Ethan’s talk, after all he’s “the father” of the responsive design if I remember well. In two words what you are suggesting is to use progressive enhancement, seems legit. Thanks for the reply :)

  • trischlorren

    This article arrived just at the right time. As i work with web designers to develop my site I see the challenges they face. Working with images being one of the greatest. Thanks

  • jason

    Super interesting example. I work for a large federated political blog, and we see something similar. People jump on the full version of the site to discuss major news events, then stay on their phone long afterwords to make sure they don’t miss developments. I wouldn’t call the mobile pattern ‘passive’ as they are active reloading and searching for updates and new opinions, but its not as active as the debate that takes place on the full version of the site. Your example is even more compelling as one mode seems categorically different, not just a focused subset of the browser mode.

    Anyway, I probably stated my views a bit too much as a one sized fits all solution. A better way to frame it might be to say that responsive design is strictly speaking bad technical and product design practice, but might make good economic sense if dev resources are scarce. I think its great to build responsive layouts into wordpress templates for instance, but if you are maintaining an app, spend the extra time to address the specialized needs of mobile users. It will pay off.

  • Eivin Landa

    Re matchMedia: It’s also in Modernizr. http://modernizr.com/docs/#mq

    Great article!

  • Gorka Molero

    Yeah you caught me dude ^^

    Did you ever hear the argument that the first site ever created was not fixed but responsive, mobile-optimized, etc etc?

    http://info.cern.ch/hypertext/WWW/TheProject.html

    That has to be a lesson for all of us. Cutting with non-JS users should never be an option, unless your technology is built upon JS. Content first, then pirouettes

  • Gorka Molero

    Thank you Trisch!

  • maxlibin

    Nice article…

  • Rugby

    “Performance is about respect.” Yeah Speckyboy, look at yourself! This article has 216 requests, 1.9 MB and loads over a minute! And it is not the biggest article in your site. Please do something with it – start with removing banners and compressing images using WebP.

  • Thank you so much. Hahahaha!

  • Tim

    I watermark ALL of my images and people still use them. They use Photoshop or whatever to crappily remove the watermark and they don’t care how it looks. Also, these images were only 72ppi images and people STILL removed the watermarks and used them for printing and other things. Making them high res is just asking for more problems. Humans are not honest. They steal and they do Google searches without bothering to mind the copyright.

  • joaoN1x

    when 90% of the globe have web connections inferior to 1mbps this guys come and say “Research shows 57% of users will leave your site if it takes more than 3 seconds to load.”… badly made researches,… with a 7mbps 3G connection people wait 10 or more seconds for the page load, this stats and researches are made with surveys on the top of a NY building chill-out restaurant/bar with all those fancy moneytized guys that have no idea of what is a net connection worldwidely… in general it all resolves to the interest of the person about the website and the fact that the person didn’t clicked by msitake on those fanads adwords stuff that just shows content that have nothign to do with what you are searching for.

  • I just passed this around the office. RESS is especially interesting.

  • This article demonstrates the challenges development teams to make a website responsive, not just thinking of different sizes, but also in the different scenarios we have today. We have to think in like we’re still on dial-up, who took that time is more accustomed!

    Great article!

  • Biruk Hailu

    this is probably the most important mobile website peace i’ve read so far tx Speckybox. I am working on a new website for our company and surely we will be using the tips mentioned here

  • Bob Bobov

    Great article! Amazing one!

  • FreekyMage

    Ironicly this page kept loading and then crashed my browser (on android 4.1)

  • Sébastien Conejo

    Great post Gorka, thanks!

  • bgbs

    If the page has valuable info, a person will wait 20 seconds for it to load. Besides, it is not alway about the page but also slow network, or TCIP ip packet glitch that causes a page to hang or load slow.

  • iamjonjackson

    fantastic article

  • spaulagain

    Actually, there is one BIG reason to send desktop sized images to mobile users. Because mobile users have high res screens! Desktop sized images often equate to just about the right pixel density when shrunk down to look good/sharp on smartphones. Considering many/most smartphones have resolutions as good or better than your average desktop screen, I’d say its a leap to assume the mobile user should receive lower quality images. You have to check the device’s pixel density first, then send lower quality images if appropriate.

    There are ways to send images based on pixel density. This should be done, whenever possible. But content driven sites like blogs, etc. Don’t always have that flexibility as often non-developers are creating and pushing the content to the page.