
Responsive Design is Not About Screen Sizes Any More - gbelleguic
http://speckyboy.com/2013/09/11/responsive-design-is-not-about-screen-sizes-any-more/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+speckboy-design-magazine+%28Speckyboy+Design+Magazine%29
======
zeman
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.

[http://www.youtube.com/watch?v=YV1nKLWoARQ](http://www.youtube.com/watch?v=YV1nKLWoARQ)
[https://developers.google.com/speed/docs/insights/mobile](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/](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/](http://www.cdnconnect.com/)

~~~
kmfrk
Heads up: on speedcurve.com, my browser freezes at signup.php after entering
my credentials, and I don't receive a confirmation e-mail.

Using Opera, Ghostery, and Ad Muncher, if it helps.

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

~~~
abrowne
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.

~~~
cam_l
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!).

~~~
abrowne
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!

------
oyvindeh
Good article!

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.

~~~
mwilcox
Source (listed on the link in the article):
[http://www.akamai.com/html/about/press/releases/2010/press_0...](http://www.akamai.com/html/about/press/releases/2010/press_061410.html)

There's an option to download the full study but it requires registering.

~~~
pakitan
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.

~~~
gorkamolero
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

~~~
pakitan
> 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.

~~~
gorkamolero
Haha touche

------
mgkimsal
"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'.

~~~
prawks
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?

~~~
mgkimsal
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.

~~~
wonderyak
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.

------
wehadfun
Responsive design was about (perceived) speed before it was about screen size.

The first time I came across "Responsive design" it was about using threads to
make UI's appear faster.

Here is an article from 2001 talking about it:

[http://www.c-sharpcorner.com/UploadFile/hsankar/UIresponsive...](http://www.c-sharpcorner.com/UploadFile/hsankar/UIresponsiveusingThreading11162005054732AM/UIresponsiveusingThreading.aspx)

~~~
uses
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.

~~~
idProQuo
I suppose you could say it has a responsive definition, changing to suit the
needs of the people saying it.

------
chrislomax
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

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

~~~
jonathanstark
> Your first media query is no media query

What don't you like about this?

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

Just my two cents.

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

~~~
enko
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.

~~~
Pxtl
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".

~~~
enko
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.

------
Kiro
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?

~~~
pixelcort
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.

~~~
cheapsteak
You can do it client side with matchMedia.

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.

------
canterburry
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](http://www.w3.org/html/wg/drafts/srcset/w3c-srcset))
and the picture element
([http://www.w3.org/community/respimg/](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](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!

------
TeamMCS
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)

~~~
zeckalpha
Doesn't decreasing page weight for non-mobile help?

------
mohit_agg
In case you missed steve souders wrote about domain sharding recently -
[http://www.stevesouders.com/blog/2013/09/05/domain-
sharding-...](http://www.stevesouders.com/blog/2013/09/05/domain-sharding-
revisited/). 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](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.

------
cheapsteak
What are the odds that when we finally settle on a standard of optimizing for
bandwidth, 5G or 6G mobile internet would make it all obsolete?

~~~
badman_ting
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.

------
terabytest
If you have a big image meant for desktop users only and you hide it with CSS,
I'm pretty sure most modern UAs won't download it.

~~~
voyou
I don't think that's right; at least, a quick test on the browser I'm using
right now (Chrome 29) suggests otherwise, as do this guy's tests from last
year: [http://timkadlec.com/2012/04/media-query-asset-
downloading-r...](http://timkadlec.com/2012/04/media-query-asset-downloading-
results/)

------
andybak
Half-way through the article uses the term 'mdot' and never defines it.

Anyone?

~~~
SolarUpNote
A separate website at the "m" subdomain:

m.yourwebsite.com

------
rorrr2
It would also be nice to implement LZMA2 support to content encoding in the
browsers, which is much better than GZip.

Firefox started doing it, I think.

[https://wiki.mozilla.org/LZMA2_Compression](https://wiki.mozilla.org/LZMA2_Compression)

~~~
masklinn
> which is much better than GZip.

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)

~~~
rorrr2
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.

~~~
masklinn
> 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.

~~~
Shorel
Twice as tiny is still very small.

In this case, bandwidth is a more scare resource than CPU/RAM.

