Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Performance Optimization How To Make Your Websites Faster On Mobile Devices

A recent study1 (PDF) found that more than 80% of people are disappointed with the experience of browsing Web on mobile devices and would use their smartphones more if the browsing experience improved.

This isn’t surprising when 64% of smartphone users2 expect websites to load in 4 seconds or less, while the average website takes more than twice that amount, at 9 seconds. This article explains techniques you can use to make your websites faster on mobile devices.

Further Reading on SmashingMag: Link

Download Speeds For Mobile Users Link

Let’s start by looking at what influences the loading speed of a website on a smartphone.

The most obvious factor is the connection speeds of smartphones. In the best-case scenario, mobile users connect to the Internet over 3G and 4G networks, with 4G networks being faster. In the US, 57% of users are on 3G, and 27% are on 4G. In Canada, 4G penetration is even lower. In the UK, 4G only recently became available.

User experience on mobile devices usually has room for improvement. (Image: Phil Campbell8)

According to a study by PCWorld9, the average download speed for 3G networks in the US is 2 Mbps, and 6.2 Mbps for 4G networks. A study by Ofcom10 found that the average download speed for 3G in the UK to be 2.1 Mbps. Outside of North America and Europe, connection speeds are generally slower. Because 1 Mbps equals 122 KB/s (or 0.12 MB/s), this translates into the following:

  • 244 KB/s on average for 3G users (0.24 MB/s),
  • 756 KB/s on average for 4G users (0.76 MB/s).

If you multiply that by the 4 seconds that mobile users are expecting to wait, this means the website could be a maximum of 1 MB for 3G users and 3 MB for 4G users.

However, download speed is not the bottleneck. The bottleneck is the network latency11, smartphone’s memory and CPU. Even if the phone can download 1 MB in 4 seconds, the website will take longer to load because the phone needs to receive and process the code and images.

On a desktop, only 20% of the time it takes to display a Web page comes from downloading files. The rest of the time is spent processing HTTP requests and loading style sheets, script files and images. It takes even longer on a smartphone because its CPU, memory and cache size are much smaller than a desktop’s.

How To Minimize Loading Time Link

Having a fast website is all about making the hard decisions and getting rid of what’s not at the core of your experience. If it doesn’t add a lot of value, remove it. This is true for all phases of the development process, but especially so for planning and coding.

  • Reduce Dependencies
    Fewer files to download means fewer HTTP requests and faster loading times.
  • Reduce Image Dimensions
    On top of the extra download time, precious processing power and memory are used to resize high-resolution images.
  • Reduce Client-Side Processing
    Rethinking the use of JavaScript and keeping it to a minimum are best.

How To Reduce Dependencies Link

Load Images Through CSS Link

If you want to hide content images from mobile users, relying on display: none or visibility: hidden won’t prevent them from being downloaded. We tested the following code:

<div style="display:none;">
   <img src="logo-none.png" />

<div style="visibility:hidden;">
   <img src="logo-hidden.png" />

You can see in the two waterfall charts below how content images set to display: none or visibility: hidden are still downloaded.

Waterfall chart12
Waterfall chart for display: none and visibility: hidden on an iPhone 4, iOS 5.0.

Waterfall chart13
Waterfall chart for display: none and visibility: hidden on a Nexus S.

Instead, load them as background images in CSS, and use media queries to conditionally hide them. The basis for this technique was originally tested by Jason Grigsby14 and expanded upon by Tim Kadlec15. A variant is used on Amazon’s separate mobile pages16 to conditionally load device-specific images.

<meta name="viewport" content="width=device-width">

@media (max-width:600px) {
   .image {
@media (min-width:601px) {
   .image {
      background-image: url(image1.jpg);

<div class="image"></div>

You can see in the two waterfall charts below that the image isn’t loaded:

Waterfall chart17
Waterfall chart for an iPhone 4, iOS 5.0.

Waterfall chart18
Waterfall chart for a Nexus S.

Keep External Style Sheets To A Minimum Link

If you’ve been using separate style sheets for each break point, you may want to rethink this. We tested the following code:

<link href="extra-small.css" rel="stylesheet" media="screen and (max-width: 390px)" />
<link href="small.css" rel="stylesheet" media="screen and (min-width: 391px) and (max-width: 500px)" />
<link href="medium.css" rel="stylesheet" media="screen and (min-width: 501px) and (max-width: 767px)" />
<link href="large.css" rel="stylesheet" media="screen and (min-width: 768px)" />

You can see that all four style sheets are downloaded in portrait mode:

Waterfall chart19
Waterfall chart for media queries on an iPhone 4, iOS 5.0.

Waterfall chart20
Waterfall chart for media queries on a Nexus S.

Because they’re all being downloaded anyway, you might as well combine them all into a single file and reduce the number of HTTP requests. Alternatively, you could rely on server-side functions to dynamically insert the correct style sheet based on the device (a method used on the responsive WordPress.com21).

A different approach would be to use inline styles. Amazon’s separate mobile product pages have one external 6 KB style sheet, along with some inline styles. This results in a single additional HTTP request to download all page styles. Amazon’s desktop version isn’t as efficient, with nine external style sheets, totalling 40 KB combined.

CSS3 Instead Of Images Link

Rounded corners, drop shadows, gradient fills, and so on — these styling features can be used instead of images, reducing the number of HTTP requests and speeding up loading time.

Screenshot of Amazon buttons22
Amazon’s buttons are created using CSS3; no images are used.

Although CSS3 can reduce HTTP requests, it adds to the processing load. We created a series of simple HTML files, each containing one basic CSS3 styling feature. You can see from the chart below that the effect on loading time is minimal but should still be considered. Notice how the box-shadow effect has the biggest impact on loading time.

Chart with CSS3 styling feature loading times23
Loading times for CSS3 styling features on an iPhone 4, iOS 5.0.

Data URI Instead of Images or Web Font Files Link

The data URI scheme24 is a way to embed data into HTML or CSS without using any external resources. It can be used to embed anything onto a Web page, with the most common usage being to embed images and Web font files. Its primary benefit is to reduce the number of HTTP requests.

The way it works is simple. Instead of referencing an external image file, you would embed the base64-encoded data directly into the HTML or CSS, using the following format:


For example, the following shortcut icon is generated by a data URI:

Here’s the code:

<img alt="" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAACI0lEQVQoz2P48/bFX1Tw58vn3/dv/rp56dfD238+vocIfl029UOC3dsgS4Y/nz4gq/794sm3VbO+zmr/MqX+S1/l597yb2vn/rpx6VN14od4+3cBRgx/vn9F1vB9/+bPPeVfJlZ/6S793JwDVPcxL/BjQeiHFNf3cbbvgw0Z4JZCwM/Lpz81Zn2qS/1Ul/apOv5jUfiHbP8PSc7vY23fh5m+C9JjALoVzQ8/zx7+0lH4IcvnQ4bXhwzPD8muINXhZu+C9N/56zB8mdr49/cfdH9/fPdj36bPLbkgpYH670KNQaoDdV47aTK8j7H+tmXpX6zg95+f545+7ix656PxzlP5jaf2c2M1hvcRZu8jzb4umfrn6xfs2v78+XFkx9sI2+fass8N1Rje+eu/dtR+YaD0Jj70296df3/+xKrr593bL91tnmnJMbwwVXtuoAbU+kxD5pmu4pvYkK9rVvz58B5Tz7dd257pKDAAlT43giEDFZA2NclXAe5fN60DOgZFx48fb6ICGRCqIchY/bmhKkibivinOdPRLPnQ1cwAUqGrCFQBVIes7ZmmzEtni9+vXiFr+DR9IsMzHfnXIV5vs5OeqUs/05B+rqcIdBhQ81M1yRfW+r+fPUHRMLWfAejir+tWATlf1ix/HR34wlL3ub7Scx2F56Yan6ZPQnPS+6oihlc+Tr/fv4OG+Levv+7d+X700PeDe3/dv4um+tfjhy9drQDa2DKqOJhVKgAAAABJRU5ErkJggg==" />

The responsive website embeds both images and fonts. The Boston Globe25’s responsive website, which loads in just over 4 seconds on a smartphone, also embeds data.

Screenshot of WordPress website26
Nearly all graphics and Web fonts on are from data URIs.

Because of the way browsers load data URIs, they could end up taking longer to load than using external image or font files. Testing and comparing the two methods is important to see whether it’s worthwhile.

Inline Scalable Vector Graphics (SVG) Instead of Images Link

Much like data URIs, scalable vector graphics27 (SVG) can be embedded onto a page to reduce the number of HTTP requests. For example, the following image is an inline SVG:


Here’s the code:

<svg version="1.1" id="drop" x="0px" y="0px"
   width="17.812px" height="28.664px"
   viewBox="296.641 381.688 17.812 28.664"
   enable-background="new 296.641 381.688 17.812 28.664" 
<path fill="#EE1C4E" d="M314.428,401.082c-0.443-5.489-5.146-9.522-7
.52-14.186c-0.816-1.597-1.352-5.208-1.352-5.208 s-0.555,3.792-1.388
,8.896,9.191 C310.49,410.354,314.816,405.941,314.428,401.082z"/>

SVG files can be created with a vector graphics editor, such as Adobe Illustrator. Once created, open the file in a text editor and drop it into the code (minus any unnecessary meta data).

The above code will work in an HTML file, but won’t work in a style sheet. To embed an SVG file in a style sheet, first convert it to a data URI. To do this, grab the SVG code from the text editor (be sure to include the meta data), encode it in base64, and then embed it using the following format:


Here’s the code:


Test this method and compare with external image files to make sure it actually is faster.

Image Sprites Link

The idea behind sprites is to combine commonly used images into a single image file, reducing the number of HTTP requests. For example, if you combine four images into a single sprite, you’re theoretically reducing HTTP requests from four to one. The required image is then displayed by using the CSS background-position property.

Amazon sprite28
One of Amazon’s image sprites

Amazon has multiple sprites, some with duplicated images.

Font Icons Link

Font icons are fonts consisting of symbols and glyphs (like Wingdings or Webdings), and can be used instead of loading an image file. For example, the following icon is not an image, but rather the letter “H” from Wingdings:


Although Wingdings and Webdings are a bit cheesy, other more professional Web fonts are available that can be loaded through the @font-face rule.

This technique can be used in the same way as image sprites to reduce HTTP requests. By combining multiple icons into a single Web font, the number of HTTP requests for all icons can be reduced to one. If the Web font is embedded using a data URI (as described above), HTTP requests could be reduced to zero.

This is exactly what does. Here’s the Web font embedded in its style sheet:

Wordpress font icons29’s font icons has access to all of these icons without having to make any extra HTTP requests, because the icons are part of a Web font embedded in WordPress’ style sheet as a data URI.

As an bonus, font icons can be animated using CSS3 keyframe animation (which would be useful for “loading” icons).

The primary downside of CSS sprites is that they can only be one solid color. Amazon’s image sprites include multi-colored icons, which is why it couldn’t use this technique.

Tools such as IcoMoon30 make it easy to build a custom Web font. All that’s needed is the SVG file for each of the icons.

Avoid Inline Frames Link

Each inline frame (iframe) results in one more HTTP request, in addition to any dependencies within the iframe. Here’s a quick test we did, comparing inline text with a single iframe containing text only.

Chart with inline frame loading time31
Loading times for CSS3 styling features on an iPhone 4, iOS 5.0.

Having a single iframe added nearly 0.20 seconds to the loading time. To keep the website fast, it’s best not to use them.

Code for Mobile-First Link

Going mobile-first also applies to front-end development.

By coding for mobile users first and then progressively enhancing for tablets and desktops, unnecessary dependencies are reduced. Compare this to coding for desktop first, where heavy components are loaded by default and then hidden for small screens (known as “graceful degradation”).

Here’s an example of coding for desktop first:

.image {
   background-image: url(image1.jpg);

@media (max-width:390px) {
   .image {
      display: none;

<div class="image"></div>

In the above code, the default is to display the image, which is then overruled for mobile devices with the media query.

Here’s an example of coding for mobile first:

@media (min-width:391px) {
   .image {
      background-image: url(image1.jpg);

<div class="image"></div>

By default, the image isn’t displayed, while wider screens are progressively enhanced using a media query.

Split Content Onto Multiple Pages (Separate Mobile Websites) Link

Keep your core content on the page, while linking to secondary content. This will reduce the payload of the HTML and prevent any associated dependencies from being downloaded.

Amazon’s mobile product pages have generic product information, while providing links to “Customer Reviews,” “Description & Details” and “New & Used Offers.” This eliminates HTTP requests for three images, while the HTML’s size is reduced by 45 KB.

Screenshot of Amazon mobile product pages32
Amazon splits content onto multiple pages to reduce loading time.

Keep Redirects to a Minimum (Separate Mobile Websites) Link

Amazon has a single redirect taking the visitor to the separate mobile page, resulting in a 0.4 second delay. Compare that with Dell’s website, which has two redirects, resulting in a 1.2 second delay.

Waterfall chart33
Waterfall chart for Dell’s website on an iPhone 4, iOS 5.0.

Waterfall chart34
Waterfall chart for Amazon’s website on an iPhone 4, iOS 5.0.

How To Reduce Image Dimensions Link

Responsive Images Link

The idea behind responsive images is to have the visitor download only those images that are best suited to their device. In the case of smartphones, this would be lower-resolution images that can be quickly downloaded and rendered.

Amazon’s separate mobile product pages use a responsive-images technique that assigns a particular background image to a div according to media-query matches. Here’s Amazon’s code:

<!-- // This meta viewport is inserted for iPhones // -->
<meta name="viewport" content="width=device-width,user-scalable=no,initial-scale=1.0,maximum-scale=1.0">

<!-- // This meta viewport is inserted for the Nexus S // -->
<meta name="viewport" content="width=device-width">

@media (max-width:390px) {
   #image-container {
      max-width: 109px;
   .image {
      background-image: url(image1.jpg);
@media (max-width:390px) and (-webkit-min-device-pixel-ratio:1.5) {
   .image {
      background-image: url(image2.jpg);
@media (max-width:390px) and (-webkit-min-device-pixel-ratio:2) {
   .image {
      background-image: url(image3.jpg);
@media (min-width:391px) and (max-width:500px) {
   #image-container {
      max-width: 121px;
   .image {
      background-image: url(image4.jpg);
@media (min-width:391px) and (max-width:500px) and (-webkit-min-device-pixel-ratio:1.5) {
   .image {
      background-image: url(image5.jpg);
@media (min-width:391px) and (max-width:500px) and (-webkit-min-device-pixel-ratio:2) {
   .image {
      background-image: url(image6.jpg);
@media (min-width: 501px) and (max-width: 767px) {
   #image-container {
      max-width: 182px;
   .image {
      background-image: url(image5.jpg);
@media (min-width: 501px) and (max-width: 767px) and (-webkit-min-device-pixel-ratio:1.5) {
   .image {
      background-image: url(image7.jpg);
@media (min-width: 501px) and (max-width: 767px) and (-webkit-min-device-pixel-ratio:2) {
   .image {
      background-image: url(image8.jpg);
@media (min-width:768px) {
   #image-container {
      max-width: 303px;
   .image {
      background-image: url(image8.jpg);
@media (min-width:768px) and (-webkit-min-device-pixel-ratio:1.5) {
   .image {
      background-image: url(image8.jpg);
@media (min-width:768px) and (-webkit-min-device-pixel-ratio:2) {
   .image {
      background-image: url(image8.jpg);

<div id="image-container">
   <div class="image">
      <img src="image1.jpg" />

Even though Amazon has a total of eight product images in its inline styles, only two are downloaded by an iPhone 4 or Nexus S in portrait mode.

A different data-fullsrc responsive-images technique35 is used on the Boston Globe’s responsive website. It’s a combination of markup, JavaScript and a server-side redirect rule:

<img alt="" src="mobile-size.r.jpg" data-fullsrc="desktop-size.jpg" />

The src is the mobile-sized image, ensuring that the website defaults to the smaller version (mobile-first), while the data-fullsrc is the full-sized image. JavaScript is used to detect the device’s screen size, which is written to a cookie. For large screen sizes, JavaScript swaps the smaller src image with the higher-resolution data-fullsrc image. The server also uses Apache rewrite rules to check for .r. in the image file’s name and displays a spacer GIF, instead of the smaller mobile image (thus preventing the mobile-sized image from being downloaded by desktops).

Microsoft36’s responsive website uses Scott Jehl’s Picturefill37 technique:

<div data-picture data-alt="Alternate text here">
   <div data-src="image1.png"></div>
   <div data-src="image2.png" data-media="(min-device-pixel-ratio: 2.0)"></div>
   <div data-src="image3.png" data-media="(max-width: 539px)"></div>
   <div data-src="image4.png" data-media="(max-width: 539px) and (min-device-pixel-ratio: 2.0)"></div>

   <noscript><img src="image1.png" alt="Alternate text here" /></noscript>

Note: In the above snippet, data-picture="" should be data-picture, without the ="". (The ="" characters are automatically inserted by Smashing Magazine’s WYSIWYG editor.)

With this technique, JavaScript sweeps through the page’s code and finds the divs with the data-picture attribute. It then inserts a new img tag based on the data-media attribute.

The main benefits of these responsive-image techniques are:

  • Small screens download low-resolution images, while large screens download high-resolution images;
  • Only the required images are downloaded, while unneeded images aren’t loaded in the background.

There are a variety of other techniques for implementing responsive images. Check out these resources for more details:

How To Reduce Client-Side Processing Link

Keep JavaScript to a Minimum Link

With JavaScript disabled in Chrome, Starbucks40’ responsive website takes 3.53 seconds to load on a good broadband connection on desktop. With JavaScript enabled, it takes 4.73 seconds, a 34% increase. JavaScript’s impact on loading time would be even greater on a smartphone because of the device’s smaller CPU, memory and cache size. As a general rule, rethink whether to use JavaScript, and keep it to a minimum.

A good example of spartan JavaScript is the BBC41’s mobile website. The website doesn’t use external JavaScript files — it’s all inline. The inline script is limited to a few lines and doesn’t have a significant impact on memory, with the HTML file and all inline JavaScript taking 0.78 seconds to load.

Much like the BBC, Amazon’s mobile product pages don’t have external JavaScript files, instead using minimal inline scripts. The HTML file and all inline JavaScript take 0.75 seconds to load.

IKEA42 and Kmart43’s mobile websites use jQuery Mobile44, a lighter version of the full jQuery JavaScript framework. (Please note that jQuery is not a lighter alternative, and is in fact an addition to the jQuery base.) Both of these websites load in under 4 seconds on an iPhone 4.

Before using a JavaScript framework, consider whether it’s really necessary. In some cases, using small bits of JavaScript is more efficient than initiating calls to a framework.

Avoid Widgets Link

Widgets can have a surprisingly catastrophic impact on real loading time. To verify this, we created a series of simple HTML files, each containing the default embedding code for one widget. You can see in the results below how bad it gets. Note that this isn’t a perfect test because these are controlled experiments in a simulated environment, but it’s interesting nonetheless.

Chart with widget loading times45
Loading times for widgets on an iPhone 4, iOS 5.0.

Combining them all on a single page results in a whopping four-second loading time for the widgets alone.

Server-Side Techniques Link

In addition to optimizing the front end, server-side techniques can also be used to speed up loading times. These techniques are worth looking into, but won’t be covered in this article:

  • Cache HTTP redirects to speed up repeat visits;
  • Merge HTTP redirect chains to reduce the number of redirects;
  • Use HTTP compression to reduce the number of bytes (Gzip or DEFLATE).

Testing Performance On Mobile Devices Link

Because of the unpredictability of mobile devices, testing performance on multiple devices is important. Here are some free performance-testing tools:

  • Mobitest46, Akamai
    Generate waterfall charts and HAR files for the iPhone 4 iOS 5.0, iPhone 3G and Nexus S. Note that test results for the Nexus S were inconsistent with our own internal testing. Our server-access logs showed fewer HTTP requests when we tested on actual Android 2.x devices.
  • Network Panel47,” Chrome Developer Tools
    Generate waterfall charts and HAR files from the Chrome browser. Go to Settings → Overrides to switch the user agent to an iPhone (iOS 4 or 5), Nexus S, Galaxy Nexus, BlackBerry 9900, BlackBerry BB10 or Nokia N9.

Conclusion Link

To meet the high expectations of mobile users, you need a mobile-optimized website that loads in 4 seconds or less. The best way to hit that magic 4-second mark is to minimize the processing load on smartphones by reducing JavaScript and by optimizing the HTML, CSS and images.

Using the techniques above, you will be well on your way to building a snappy mobile Web experience!

Do you have anything to add? Let us know in the comments.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47

↑ Back to top Tweet itShare on Facebook

Johan Johansson is a Web Development Manager at Pixelmade in Vancouver, Canada. He has founded 2 web design companies during his 18 year career. His free time is consumed by his 4 year old son, who won't take no for an answer. You can follow Johan on Twitter @johansson_johan.

  1. 1

    Scott Lewis

    April 3, 2013 5:34 am

    I think the sentence “However, download speed is not the bottleneck. The bottleneck is the network latency”. I think it would be clearer to say “However, download CAPACITY is not the bottleneck”. I read capacity to be a measure of potential whereas speed is a measure of performance. They are not the same thing.

    Maybe I’m just thinking about the terminology wrong but it seems like “download speed”, to the average person, would imply the actual amount of time it takes for a page to appear in the browser once I’ve requested it. There could be many reasons why the speed is slow, but as the author points out, capacity isn’t the issue.

    • 2

      Johan Johansson

      April 3, 2013 9:30 am

      Thx for the comment! You make a good point. I think in this case, either “capacity” or “speed” can be used. It’s more a question of semantics.

      • 3

        Scott Lewis

        April 5, 2013 1:26 pm

        Yes, I was just trying to clarify. I suspected I might have been misunderstanding the terminology and definitely wasn’t trying to detract from the piece. I found it very helpful. The “capacity” versus “speed” topic could easily warrant its own post, but clearly that’s not your point. Thanks for a great post.

    • 4

      Download speed refers to the speed at which the resources for the page are downloaded. Just downloading all the parts of a web page is only the first part of rendering it on a screen. The writer of the article is trying to point out that processing and rendering the page is often more time consuming than initially downloading the page and its dependancies (images, css, js, fonts and so on). So speaking of download speed or download capacity is irrelevant in my opinion. The thing to take away from that part of the article is that developers should create pages that render quickly, by using javascript and css3 effects scarcely and by keeping the html file as small as possible. Many of the tips in this article reduce both the download time aswell as rendering time. Developers should be aware of both, and the impact our decisions have on each.

  2. 5

    A well written article with useful tips!

    To me, it’s clear that the web technologies we use today are struggling to keep up with user and developer demands. For example, every method for responsive images is messy, time consuming to set up and generally unelegant. It feels like a necessary evil at best, using background images and / or javascript and / or messing up semantics and so on. We need a sort of multi-image solution that works much simpler and without downsides to semantics or otherwise. Also the way every tiny little resource is downloaded separately to begin with is silly. Now we as developers need to use fonts for icons, or sprites, or embedded data or svg, just to compensate for this weakness in the http protocol. Front-end development just brings with it so much hassle these days, which should not be necessary if the technology was more up to par.

    The internet as a whole was created for very simple textual documents and the tech was merely updated when it should have been redone from the ground up to support current expectations. We’ve been very creative at working around the limitations and yes, it’s possible to create very user friendly and speedy experiences on the web. But just look at all the micromanagement it requires. It’s interesting, but tiresome, and it’s slowing down real innovation.

    There’s no real sense in getting frustrated over this (though I do), since this is the hand we’ve been dealt and it’s not easy coming up with a solution. But there will come a time when the whole http / html technology stack will really start to crumble, in spite of the updates these technologies receive. Until that time though, we’ll need well written articles such as this one so we can work around the issues as best we can.

    • 6

      Johan Johansson

      April 4, 2013 8:26 am

      Thx for your thoughtful comment! I can remember trying to get websites to render correctly on IE3 way back in the 90s… Frontend development has been full of hacks and workarounds for a long time. I guess it’s just the nature of what we do.

      • 7

        Scott Lewis

        April 5, 2013 1:50 pm

        Those were the days, weren’t they? :-) It seems like eons ago but it wasn’t really that long ago. FONT tags, tables for layouts, nested P tags. Ugh. I won’t complain about the way things are today. There are challenges and it can be tedious, but we have come a long way. But as you stated, it’s the nature of the beast.

    • 8

      Scott Lewis

      April 5, 2013 1:48 pm

      Very well said and I couldn’t agree more. I’m encouraged by some of the newer approaches and technologies (CSS preprocessors) but there are still some inherent weaknesses that you aptly pointed out. I’ve been at this since 1996 and these issues have always existed … but I’d much rather be developing today than back then. :-) Great comment.

    • 10

      Thanks Geert, what you say is evident and something I’ve been saying for too long. HTML was ok back in time but now the limitations and workarounds end up with far too many comprimises to make for more interesting web experiences.

      The main frustration is that it didn’t need to have been like this. Flash was doing all that HTML is still trying to do in 2005, eight years on and the situation has improved a bit in terms of what HTML can accomplish but it’s come at the cost of ugly workarounds, protracted, slower more costly development and a total separation of content and presentation. To me as a designer this goes against basic design/first principles that are a given in any other design field. It’s like designing a building with context, use and aesthetics all separated into silo’s and a loss of holistic outcome. This is why the whole field seems stagnant and there’s a real problem of everything looking the same and a total lack of innovation in website design. Honestly when was the last time anyone saw a website that really made you think wow that is different, why didn’t I think of doing that?

      I’ve always tried to use constraints as opportunities in design yet there’s less scope now as to what can be done than there was eight years ago, that doesn’t seem like progress to me. Until these problems are sorted articles like this will need to be written but to me it seems like an awful waste of time, effort and resources that we are still messing about micromanaging rather clumsy technology rather than creating interesting work. The worst thing is all of this effort will be absolutely redundant once the problems are solved. The best thing is we’ll be back to designing interesting sites, hopefully within the next 3 years but looking at the rate of progress I’m not holding my breath.

  3. 11

    Excellent article. “Outside of North America and Europe, connection speeds are generally slower.” – this reminded me of a blog I wrote recently on how the challenges of mobile performance are exacerbated in Asia/Pacific markets where networks are older/slower. Link:

  4. 12

    Interesting point about widgets. Social media buttons are extremely common so I must have lost so much time just waiting for those extra buttons to load.

  5. 13

    From yesterday’s article (, we have:

    jQuery Mobile is not:
    a jQuery alternative for mobile browsers;

    Doesn’t that conflict with your comment?
    “IKEA and Kmart’s mobile websites use jQuery Mobile, a lighter version of the full jQuery JavaScript framework. “

    • 14

      I think the statement: “a lighter version of the full jQuery JavaScript framework.” is wrong.

      jQuery mobile is an extension for jQuery which provides an optimised mobile experience. It does not replace the full jQuery framework it combines with it.

      • 15

        Ricardo Torres

        April 3, 2013 5:50 am

        And also increases page loading time.
        I’m surprised there’s nothing about Zepto or other tiny libraries. But anyway, awesome article though.

      • 16

        Johan Johansson

        April 4, 2013 8:00 am

        Thx for the comment! You are correct, and we’ve amended the article.

    • 17

      Johan Johansson

      April 4, 2013 8:01 am

      Thx for the comment. You are correct! It does conflict, and we’ve updated the article.

  6. 18

    Ricardo Torres

    April 3, 2013 5:25 am

    “The primary downside of CSS sprites is that they can only be one solid color. Amazon’s image sprites include multi-colored icons, which is why it couldn’t use this technique.”

    I think you are talking about font icons, huh? ;)

  7. 19

    Scott Lewis

    April 3, 2013 5:39 am

    Using background images instead of inline images creates a dilemma with regards to semantics. I favor performance over ideologies so it doesn’t bother me to use whatever approach provides for the best user experience. That said, I wonder what the impact to accessibility is of moving content images (as opposed to decorative images) to a CSS background property. I’m not disagreeing with the suggestion, just want to understand other potential downsides.

    • 20

      Johan Johansson

      April 3, 2013 10:36 am

      Another good point. There would be an impact to accessibility because there wouldn’t be an alt tag. If accessibility is a requirement, there are ways around this, but there would be a minor hit on performance. One solution would be to include a low-res image that has an alt tag within the div, then conditionally hiding the image using Javascript.

      • 21

        Scott Lewis

        April 5, 2013 1:44 pm

        I was working with a similar approach with regards to SVG fallbacks earlier today. I like the lo-res image approach. If the image is only for accessibility, I wonder if one could just include an empty image tag or a 1 pixel placeholder with the appropriate alt tag. It often feels like we take one two steps forward, one step back with regards to semantic markup.

      • 22

        Alan Dalton

        April 6, 2013 1:17 pm

        Great article—but I’m genuinely curious about this phrase in your comment: “If accessibility is a requirement […]”. When would accessibility not be a requirement?! Unless you can guarantee that everybody who uses a particular website will have perfect vision, hearing, motor skills, and comprehension, accessibility is a requirement for that website!

        • 23

          Johan Johansson

          April 10, 2013 9:30 am

          How true! In a perfect world, all sites would be accessible. However, even when coding to web standards, there is extra work and testing involved in making a site truly accessible. Not all organizations are willing (or able) to pay for it.

          • 24

            Thanks for replying, Johan.

            I have to disagree. From my experience, if you plan to “keep” your website accessible, as opposed to planning to “make” it accessible, you will have an accessible website at little or no extra cost. See .

            I think accessibility is particularly relevant to your article: the Web Accessibility Initiative have written about the mobile and accessibility overlap at .

  8. 25

    Steve Mallett

    April 3, 2013 8:15 am

    There a tons of recommendations and tweaks to follow, but the first is to measure your speed performance (Disclosure: I run RUMAnalytics). If you’re not measuring this then you’re not managing speed and it will become slow as creep sets into your pages or servers or whatever.

    Consider offering your visitors an SLA you hold yourself responsible to hit and maintain. It’s one thing to do some fixes & tweaking, but staying fast requires a bit more web performance cultural tool set.

  9. 26

    do you know any backward compatibility library, like css3-mediaqueries.js, that works well with link media=”screen and (max-width: 390px)” includes?

    From what I’ve found there is none as most of them ignore media attribute.

  10. 27

    Hi Johan, nice article, well written. On point I would like to mention is about data-uri. In some cases, the generated data-uri code for images can be too big and gradually increase the size of the css or html page. This can cause performance issue in another way although it will help to lessen http request. your thoughts?

    • 28

      Johan Johansson

      April 10, 2013 9:50 am

      Thx for the comment Sajay. You’re correct about data-uri sometimes taking longer to load than dependencies. It’s important to test and choose the fastest option.

  11. 29

    Given what you’ve said about widgets and JavaScript in general it seems like Google Analytics code would also be problematic.

    • 30

      Johan Johansson

      April 10, 2013 9:43 am

      Thanks for the comment! Google Analytics will add 2 dependencies, and approximately 0.5 seconds to real load time.

  12. 31

    And I used to think Content Delivery Network will be sufficient to speed up my website.

  13. 32

    Hi, thanks for a great article. Makes a change from the same old page speed optimizations I have read.

    Just wondering what tool, if any you used to test the Starbucks website speed. You mentioned you turned of JavaScript in Chrome and tested, so was it a toolbar add-on?

  14. 33

    Dear Johan Johansson: I had translated the article into Chinese, and put it on w3cplus ( This is a very good article. My Chinese friends and I like very much, hope I can see more good tutorial.

  15. 34

    Thank you. Working on speeding up my music website, tunebang. com/ for mobile now and at least 3 major changes I missed justing going on my own knowledge on subject. Biggest one is didn’t realise about display: none images still be downloaded- some of the pages on my site load dozens of large thumbnails, which imagine is pretty big burden for low-spec and/or low-bandwidth devices – what’s the logic behind browsers doing that anyway?


  16. 35

    Natalie Johanson

    February 25, 2014 5:09 am

    Interesting article. Very well and clearly pointed out the important aspects. Loved it. Was thinking is there any way to make iOS app faster in terms of performance?

  17. 36

    Web Designing Services

    April 16, 2014 12:37 pm

    Really it is a great post, as a newbie in web design, I read this post and bookmarked it, very organized information you have post here.

  18. 37

    Thanks, Johan, for some great tips. I have to point out a tool that’s great in helping to build super fast sites that are responsive.

    People seem to love it and it’s easy to use. It’s SEO-friendly with built in analytics, social & lead management tools. Pretty cool stuff.

  19. 38

    hi, i wonder, what is the fastest way to use web font?

    I am using google blog,

    I want to use nanumgothic font…

    could you please send me the fastest this web font code?

    please answer

    than you


  20. 39

    Hey Guys here i collect some Fast loading Google Fonts , Its may be useful for you. I explain loading speedtime and also which popular website using that fonts. One fonts used by Google’s Head Matt Cutts. Check here

  21. 40

    And you gusy SMASHED the Google Speed Test. 98 of 100 for Desktop and Mobile! #Daaamn

  22. 41

    I’m working on a mobile website project and this article is really useful, thank you !

  23. 42

    If you install tons of plugins on your blog that can slow down the entire site drastically. There are also lot of themes which load a huge number of JS in the header. So test test test before you decide what to keep and what don’t. I created site where I’ve tested plugins and themes , about 30K in total , so feel free to find your plugins and themes there and check their speed.

  24. 43


    June 27, 2015 11:25 am

    Important article.Now a days social media plays an important role to get product promotion.
    Keep sharing such an important posts

  25. 44

    Big Jim Slade

    July 8, 2015 1:08 am

    How much is an http request worth? For instance, we’ve had to code a monstrous 5 foot long (in photoshop) page. (Yes, this is a mobile site, and the turnaround time was like a day, maybe two, for about 10 pages, about half of which were simple.) We could make it one big honking image with an image map (I know, not really even front end dev) at about 800K, If I do it the normal way of breaking it up into images/html/css it would be around 300K with 14 images (primarily product images and people using the product). So, is it worth 500K to save 13 http requests?

  26. 45

    Daniel Gregorio

    August 16, 2015 11:15 am

    I likes. This sites


↑ Back to top