Web Performance 2.0
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 dissapointing. (1)
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… ObeseJason Grigsby
But, most importantly, every mobile user was receiving the same kilobyte overload as a desktop user.
The community had different reactions to the fact. 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 likeBrad Frost, Luke Wroblewski or 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 stupidChristian Heilmann
Web performance has traditionally been built around (no offence) developer-exclusive jargon.
Terms like GZIPing, uglifying, minifying, DNS Lookup, file-concatenation… This obscure words push designers out of the ecuation.
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 him download it.
Good performance is good designBrad Frost (2)
To achieve truly lightweight sites, performance shouldn’t only be a concern. It should be treated as a design feature.
To them, performance is like any other issue. Sites that overcome it are the ones who acknowledged it from the start. And the ones that overlook it are the ones that suffer it in the end.
Performance is about respect. Respect your users and they will come back.Brad Frost
The Why
It’s not only that you want users to have a good experience. If that was the case you could easily swap performance for a more important concern in your agenda.
Page Abandonment
Research shows 57% of users will leave your site if it takes more than 3 seconds to load. (3)
Google, page speed & SEO
Back from the spring of 2010, Google takes speed as a ranking factor. (4)
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 algorythm.
This proves speed not only is a concern when talking about User Experience. Be aware of loading speed if your site is to be ranked well among the competition.
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 to three types (5):
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 put their phone out while waiting for something to happen.
Urgent Now
Pretty self explanatory
Sounds assumable, right?
Well, the truth is there is no truth about this. There is no 'mobile context'. People will use their phone not only when they are walking in the street, travelling 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 shows some really interesting stats: (6)
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: serve it to their macbook pros, while they are at home in UK or the USA with a full bandwidth.
But the rest of possible situations, which are a great many, have to be covered aswell. These include the seemingly endless stream of devices poured every day into the market, which people use to visit websites.
You don’t get to decide which devices access your site, your users doKaren McGrane
They include the countries which didn’t have that many smartphones a few years ago, but are ruthlessly getting ahead.
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 peopleKaren McGrane
But more importantly, they include all the places people will be at when using your site. So you have to watch all bandwidths. It’s not only inhabitants of poor areas of the world clearly don’t have the same data-speed coming their way. People 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 anymore about screen sizes 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 run server side that help with an already doomed site. There are ways to undertake this concerns and turn them into a competitive advantage.
What to avoid
Guy Podjarny cites three main reasons for the number of bloated responsive websites we see out there: (1)
Download and Hide
Assets are still downloaded, but hidden.
Download and Shrink
High-res desktop-level images are downloaded, and shrinked 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 strenghts. 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 take 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 brand new 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: (7)
- 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 not only designers, also many developers, have pointed out that building mobile first gives you an edge over desktop development, very related to Luke W’s second point. 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 makes a good summary of the reasons(8). 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 that you care about. 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 had kind of an essential short-coming. It relied mainly in 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 valuate 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 (9). It relies on detecting the user’s device type, evaluating it and providing an experience taylored 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 ver 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! (10). 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 saladMat ‘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 refered to as ‘Agressive 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 when 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 essentialJeremy Keith
Use excellent tools like MatchMedia, that mimics CSS behaviour evaluating 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 is 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 keep page load down (11). ‘Set your goals and stick to them’. Steve Souders mentions 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 methods to achieve speed, 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 overcome this is to serve different versions of images, depending on screen size or type. You would serve a small image to a mobile phone and a high-res one to a desktop. 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 (12). 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), so 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 the time. They are completely scalable, so they will perform better in 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 thinking on HiDPI images (12). He argues that, even if today we have the possibility of serving iPhones, iPads and other modern devices with images that will 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 and lossy compression for Web images, resulting in files 3x smaller, compared with PNG.
There are simple, lightweight JavaScript libraries that convert to and from WebP 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 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. There are a number of online solutions to do this.
- 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 every day, being fast will mean being ahead.
Reference
1. Performance Implications of Responsive DesignGuy Podjarny
2. Performance as DesignBrad Frost
3. Website abandonment happens after 3 seconds
4. How Page Load Speed Impacts SEO And User ExperienceSpencer Yao
5. Organizing MobileLuke Wroblewski
6. When & Where Are People Using Mobile Devices?Luke Wroblewski
7. Mobile FirstLuke Wroblewski
8. Responsible Considerations For Responsive Web DesignJordan Moore
9. RESS: Responsive Design + Server Side ComponentsLuke Wroblewski
10. Cutting the mustardBBC´s Responsive News
11. Setting a Performance BudgetTim Kadlec
12. Retina Revolutie Follow UpDaan Jobsis
13. The Raster Image ParadoxDave Bushell