Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. 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 London, dedicated to all things web performance.

How To Create High-Performance Mobile Websites

Editor’s Note: This article features just one of the many solutions for creating high-performance mobile websites. We suggest that you review different approaches such as Building A Responsive Web App1, Improving Mobile Support2 and Making Your Websites Faster3 before choosing a particular solution.

People start to lose interest in a website if they don’t get a response within three seconds4. Fulfilling this expectation for mobile phone users requires a different approach to usage analysis, design and testing.

This article expands on the techniques that Johan Johansson explains in his article “How to Make Your Websites Faster on Mobile Devices5,” published in April 2013.

We’ll demonstrate methods to identify how people interact with a website differently on mobile devices, and the design decisions that can be made based on this understanding. Our objective is not only to improve Web performance but to increase the client’s return on investment.

The techniques we’ll demonstrate center on the two unique characteristics of mobile phones, which are not going to change any time soon: small batteries and small screens.

Small Batteries Link

Mobile phones use radios for all communication, and they have little batteries that need to be carefully managed in order to avoid running out of power. As a result, radios are shut down very quickly when not in use, increasing the perceived time that a Web page takes to appear. 2G and 3G radios could require up to two seconds to establish an operational HTTP connection. If we accept that users start to lose interest after three seconds, then a website has only one second to respond. Think of this as the “golden second.”

Golden Second.6
Maximizing the “golden second”7.

Small Screens Link

In the physical world, content is produced for billboards and magazines and customized to account for the size and viewing distance of the medium. In the digital world, a typical mid-range smartphone has a screen with around six square inches of real estate. An MacBook Pro with a 15-inch display will have over 100 square inches. Thus, not only can we optimize website performance by reducing the amount of content sent to phones, but we can optimize business processes to improve the return on investment for website owners.

The code examples in this article are provided in .NET. Where equivalents are possible in PHP, Java, C or Python, I’ve made them available in a companion article8. I’ll explain why I’ve used .NET at the end of this article9.

Maximizing The “Golden Second” Link

Website designers and developers with high-bandwidth Wi-Fi and fixed-line connections often used to take bandwidth for granted. Responsive Web design (RWD) limits the creative process by forcing the same content, navigation and business processes to be presented on every device, irrespective of its physical capabilities.

Solutions to ensure that we can easily measure performance, monitor user behavior based on the characteristics of the device and optimize Web pages for low-bandwidth devices are required to maximize the golden second.

Simulating the Real World Link

Essential for mobile Web performance testing is a method to simulate real-world mobile bandwidth conditions. Many wireless routers that cost less than $100 support bandwidth limiting. This simply involves limiting the uplink and downlink bandwidth for LAN-side clients. If the router doesn’t support this capability out of the box, then DD-WRT10, an open-source firmware upgrade, may be used to replace the default operating system on many popular routers to limit bandwidth.

I use a Linksys E3000 router modified with DD-WRT. The procedure to upgrade the router is pretty simple, and full instructions are available on the DD-WRT website.

Once DD-WRT is installed, go to the “QoS” (quality of service) menu, and enable bandwidth limiting. Then, set values for the uplink and downlink. I prefer 256 kbps for the downlink and 28 kbps for the uplink to simulate an average mobile bandwidth connection.

Bandwidth Monitoring.11
Limiting bandwidth in the “Quality of Service” options.

Now the bandwidth of any Wi-Fi or ethernet-cabled devices that are connected to the router will be artificially reduced. The actual bandwidth being used over time can also be monitored.

Bandwidth Monitoring.12
Monitoring bandwidth using DD-WRT.

While this approach doesn’t introduce random drop-outs, variable bandwidth conditions or the delays associated with radio wake-up, it is better than performing all of your testing on a fast low-latency broadband connection. When introduced at the beginning of the website development cycle, it’s an easy way to informally test performance during the development process and ensure that you don’t get any nasty surprises during formal testing.

You Can’t Manage What You Can’t Measure Link

Peter Drucker13, a management consultant, once famously said, “If you can’t measure something, you can’t manage it.”

You can't manage what you can't measure.14
Average screen size growth over time.

Continually monitoring the content that users view according to device characteristics (such as supported radios or physical screen size) will help you to identify the content and services that are more or less popular on mobile phones. Perhaps you will see no difference, but unless you measure it, there’s no way to know for sure.

Feed Me Now: An Example Link

A global fast-food franchise wanted to create a mobile-optimized version of its big-screen website. Before creating the first iteration of the mobile-optimized website, it performed analysis to determine which options on the big-screen website were being accessed by users on small-screen devices. The main menu, special offers and the store finder were the most popular, and so a mobile-optimized website was created that focused on these areas.

Work didn’t stop there. Continued analysis revealed that the store finder was the most popular option. The mobile home page was altered again to focus on the store finder. Continued monitoring will show how many visitors choose other options, and the website will be continually refined to ensure that the most popular outcomes are catered to in the simplest possible way.

Better Logging Link

Google Analytics provides some information about device model, but it lacks the detail we need to make informed decisions based on screen size and input method. Fortunately, a comprehensive device-detection repository (DDR) can be used to add this information to existing log files. The following code snippet can be added to a .NET website to obtain the screen’s physical dimensions in inches and write the output to a simple CSV file.

// Write a log file containing the current time, and the screen
// size of the requesting device in inches.
        AppDomain.CurrentDomain.BaseDirectory, String.Format(

The first column is the date and time that the request was processed. The second is the page being requested. The final two columns are the width and height in inches. Once sufficient data has been captured, the average screen size in square inches can be calculated and plotted on a chart, similar to the following:

Screen sizes per month.15
Comparison of the average sizes of device screens over 20 months.

The analysis could be narrowed down to individual pages. Other characteristics about device, operating system and browser may be added as columns.

Similar code could be used with PHP, Java, Python and other environments.

Existing Log Files Link

Sometimes, existing Web pages can’t be altered in the way shown. In these situations, a DDR may be used to perform offline analysis of log files containing user agents. The following .NET code is a functional command-line program that will parse a space-separated log file and calculate the average screen size in square inches for the requests it represents. The first argument is the log file’s location, the second is the index of the UserAgent column within the log file.

using System;
using FiftyOne.Foundation.Mobile.Detection.Binary;
using System.IO;

namespace ConsoleApplication
    class Program
        static void Main(string[] args)
            // The number of devices read from the log file.
            int count = 0;

            // The column in the input file the user agent is held in.
            int column = int.Parse(args[1]);

            // Screen dimension variables.
            double total = 0, width, height, squareInches;

            // Create a provider to determine the device capabilities.
            var provider = Reader.Create("");

            // Read each line of the log file provided in argument  0.
            // Assume the value at column 8 is the UserAgent string.
            using (var reader = File.OpenText(args[0]))
                while(reader.EndOfStream == false)
                    var values = reader.ReadLine().Split(new[] { ' ' });
                    if (values.Length >= column)
                        // Get the device information based on the UserAgent.
                        var device = provider.GetDeviceInfo(
                            values[column - 1].Replace("+", " "));
                        if (device != null)
                            // Determine the screen dimensions in inches.
                                out width);
                                out height);
                            squareInches = width * height;
                            // If valid values are available (not a desktop/laptop)
                            // then add the values to the results.
                            if (squareInches > 0)
                                total += squareInches;

                "Average screen size '{0:#.00}' square inches from '{1}' devices", 
                total / count,

Analyzing log files is less accurate because HTTP headers other than User-Agent affect the detection’s results. This is especially true with Opera Mini and Opera Mobile browsers, in which a second HTTP header, named Device-Stock-UA16 is used to provide information about physical hardware not available in the standard User-Agent.

Why Monitor? Link

Monitoring enables us to remove unpopular content from major landing pages, thus improving the performance of content that is more important or relevant. The removed content should still be available via second-level pages — just not placed on landing pages, where they would eat up valuable bandwidth and slow down performance.

So, how do we create a separate mobile website optimized for performance?

Divide and Conquer Link

I understand why RWD makes a lot of sense from the perspective of user interface design. It’s great in situations in which content, navigation and business-process requirements are identical between 6-square-inch screens and 100-square-inch screens and only the layout needs to be altered.

Device screen sizes.17
Average device screen size.

However, having a separate mobile website makes a lot of sense when the conditions above aren’t true or when performance is critical.

Separate mobile websites are often implemented in a way that delivers a poor user experience. Google is now shining a light18 on these common issues by penalizing websites with lower search engine rankings. Mistakes include sending every desktop page to a single mobile home page, redirecting to application download pages, preventing the user from accessing the big screen website, and treating all devices with a particular operating system in the same manner.

These poor implementations have given the concept a bad reputation. Here’s how to do it simply and properly.

The following .NET web.config section will redirect the first request from a smartphone to an equivalent page on the “Smartphone” section of the website. Importantly, the query string and page name are retained across the redirection.

<redirect firstRequestOnly="true" 
    mobilePagesRegex="/(Mobile|Smartphone)/" >
        <!--Send smartphones to an equivalent version of the original page, preserving the page name and query string.-->
        <location name="smartphone" url="~/Smartphone/{0}" matchExpression="(?<=^w+://.+/).+">
            <add property="IsSmartphone" matchExpression="true"/>

In most situations, when redirected to alternative pages, users should be able to return to the original page if they wish; perhaps they’re more familiar with the big-screen version of the website. The firstRequestOnly attribute ensures that only the first request from the device is redirected. The devicesFile attribute is used to track devices on which cookies aren’t supported. The timeout attribute controls how long the device is remembered (for the purpose of redirection).

The redirection system also has to know which pages are designed for which type of device. The mobilePagesRegex attribute is applied to requested URLs. If there is a match, then the page won’t be eligible for redirection. This prevents cases of infinite redirections.

The locations element allows for different locations and associated rules to be configured. The example inserts the folder Smartphone into the original URL. The query string and other URL information are retained across the redirection. All information that affects the context of the request must be transferred in order for the user to receive the content they are expecting.

This simple approach enables a search engine-friendly, Google-compliant, mobile phone-optimized website to be delivered, with a good user experience and superior performance. Essential to the process is a DDR that provides information about the device quickly, consistently and accurately. Users who change their mobile phone’s browser settings to surf in desktop mode will be respected, and the redirection will not occur.

Beware of Clouds Link

Cloud services are a popular way to easily add features to a website. But they bring a performance penalty by calling out over the Internet. Ignoring processing time, we’ve observed an average 200-millisecond delay19 with data transmission from Amazon Web Service-hosted cloud services.

200 milliseconds is 20% of the golden second. Therefore, consider carefully where you use cloud services, ensuring they’re called asynchronously to enable other processing to continue while waiting for the response. They should be avoided for critical path activity, such as determining information about the requesting device.

Squeezing Content Link

After video, images, CSS and HTML make up the bulk of Web traffic. We need methods of optimizing them all. Video is an article on its own and will have to wait for another day.

Images Link

A popular solution is to provide three versions of the same image, and select the one that is best for the requesting device using JavaScript or CSS3 when the browser renders the page. This is a great start, but managing different versions of the same image is a pain; the image is never ideally optimized, and the method puts the burden of resizing onto the mobile device’s limited CPU and battery.

There is a better way, using an image optimizer. There are many great options out there; if you decide to use our very own image optimizer, you can add it to an ASP.NET website via the Visual Studio IDE. The following configuration will be added automatically to the web.config.

    <add name="Image" verb="GET" path="P.axd" type="FiftyOne.Framework.Image.ImageHandler, FiftyOne.Framework" />

The handler tells Internet information services (IIS) that the image handler should process any GET requests for the resource P.axd.

Once enabled in web.config, the following ASP.NET code will use the image optimizer to define an image element with three possible sources — being 240, 480 and 640 pixels wide, respectively.

<mob:Image runat="server" ID="ImageBanner" CalculateSizeMode="ClientWidth" Style="clear: both; width: 100%">
    <mob:AltImage ImageUrl="~/Images/Landscape240.png" />
    <mob:AltImage ImageUrl="~/Images/Landscape480.png" />
    <mob:AltImage ImageUrl="~/Images/Landscape640.png" />

When the image is initially displayed, the server will send a white 1 × 1-pixel GIF to appear in place of the image. This is the resulting HTML:

<img id="B" src="P.axd?i=E.gif&i=1"/>

Once the page has loaded, JavaScript is used to work out the exact dimensions required by the image and request a precisely sized image from the server. After JavaScript processing, the HTML above will be transformed to this:

<img id="B" src="P.axd?i=1&w=500"/>

The image handler referenced in web.config correlates the I query string parameter with the sources of the image, so that the best image can be used as the starting point for resizing on the server. The w query string parameter specifies the width of the image required. Multiple images don’t need to be provided; a single image will work almost as well.

This approach is easy to implement, and the result is a precisely sized image, which reduces bandwidth consumption, mobile phone CPU cycles and power consumption.


The full Oxford English Dictionary contains 171,476 words. If a computer were to represent each word as a unique binary number, rather than letters in an alphabet, then 18 bits (or 3 bytes, if rounded up) would be required. This technique is why compression algorithms are so effective.

However, HTML is not very efficient because it’s full of words for elements, IDs, classes, styles and JavaScript, without even considering the human-readable words. Compression reduces this, but it remains an overhead. This is why popular libraries have minified versions that appear almost unreadable to humans.

Some of these markup-related words can also be minimized before being sent to the browser by the server, without losing any of their meaning. Taking the image example shown earlier, the standard HTML ID attribute of the image element in ASP.NET would be ImageBanner.

<mob:Image runat="server" ID="ImageBanner" CalculateSizeMode="ClientWidth" Style="clear: both; width: 100%">

However, the code sent to the browser would use just B. For a single element, the performance improvement is negligible, but on a complex page with hundreds of elements, the page will transfer more quickly and the browser will be able to process everything that much faster.

Includes Link

Something else is slightly peculiar about the resulting HTML from the image example.

<img id="B" src="P.axd?i=1&w=500"/>

The ASP.NET code includes a style attribute that is missing, and there isn’t a class attribute for the img element. So, how is the style being applied?

The server-side-minimizing process will identify style information and create a CSS include for the page, thus reducing the HTML. If the HTML changes, then the style information will already have been cached in the browser and will not need to be downloaded again. The CSS snippet looks like this:


If many elements share the same styling, then their IDs will be added to the CSS and they’ll share the same information.

Style information can also be shared across elements and pages using a server-side style element. The following code extends the previous image example to demonstrate a shared style element.

<mob:Style runat="server" ID="StyleBanner">
    <mob:Filter Style="clear: both; width: 100%"/>

<mob:Image runat="server" ID="ImageBanner" CalculateSizeMode="ClientWidth" StyleID="StyleBanner">

The elements can be further extended to apply different styling based on the capabilities of the device and to optimize style sheets across multiple pages.

This technique will always ensure that only the required CSS is transferred, thus improving performance over subsequent requests to the same page, particularly where there are only minor differences in HTML content.

Why .NET? Link

The techniques and code examples shown for image optimization and dynamic minification of HTML and CSS content rely on content being altered after the page has been rendered but before transmission to the browser by the server. Such preprocessing techniques are relatively easy to implement in architectures such as ASP.NET Web forms.

However, they are a lot more complex to implement in script-based architectures such as PHP. For this reason, the examples in this article are provided in .NET for consistency. Where I’ve been able to apply the techniques to other languages, the example code is available in a companion blog20.

Examples Link

Public Health Foundation Enterprises implemented the techniques21 shown in this article and experienced a 23% increase in successful outcomes during the first week.

Other performance-aware websites — including 24.com22 (media), ServiceTick23 (analysis), LettingWeb24 (property), AdSupply25 (advertising) and Kitsap Credit Union26 (finance) — are all optimizing for mobile using some or all of techniques covered in this article.

Summary Link

We need to consider the return on investment for a website’s owner in order to truly optimize performance. Monitoring differences in the characteristics of devices is the essential starting point.

We can then deploy solutions such as using separate mobile websites to split up or change the focus of content. And we can squeeze maximum performance out of mobile phones by minifying images and HTML, removing jQuery, questioning when to use RWD alone, and other techniques. Of course, established techniques are critical, too, such as configuring caching directives and compressing content.

Tweaking our development environment to simulate real-world conditions will also yield a greater understanding of performance throughout the development process.

Optimize Now Link

To get you thinking even more about performance, I’ve set up a competition to find the world’s heaviest website27. Find a Web page that performs poorly on a mobile phone and submit it to the competition. We’ll work out the page’s weight, and if it’s the heaviest, you’ll win $1000. Meanwhile, implement the techniques covered in this and other great Smashing Magazine articles to ensure that your website doesn’t top the list when we weigh in on performance!

There’s never been a better time to improve your website’s performance.

(al) (ea)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9 #whydotnet
  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

↑ Back to top Tweet itShare on Facebook

James Rosewell has 18 years experience in the mobile industry. He led many initiatives for Vodafone, including the development of the 1st mobile web application for the Nokia 7110 in 1999. Since then he's founded several businesses, including 51Degrees providers of THE fastest and most accurate device detection tools to build on RWD techniques. The extensive information available ranges from screen size, retail price and battery capacity to browser capabilities.

James is also a regular presenter on, the longest running mobile industry podcast.

  1. 1

    The problems of responsive design can be alleviated using something like (disclosure: I am the author). Advantages for mobiles
    1. It only loads the scripts that are needed (eg: if you don’t want to activate the lightbox feature for a gallery, the jquery plugin’s files are not loaded)
    2. If you find a way to test the speed of the user’s connection you can decide which elements can be progressively enhanced (eg: load retina images if the connection is good enough but don’t otherwise)
    3. When going from portrait-mode to landscape-mode some enhancement may be activated or deactivated.

  2. 2

    I’m by no means an expert in Apple’s gadgets, but I believe it should say “MacBook Pro” instead of “iMac Pro” in the “Small screens” section ;)

    • 3

      Esther Arends

      August 12, 2013 2:02 am

      Thanks for the note. Fixed! ;-)

    • 4

      I am under the impression that the current consensus in the industry is that RWD is the new default, and mobile-only the exception, only when you have really strong reasons.

  3. 5

    I’m not trying to beat down this article, but I do want to ask one question – the fundamental basis for this article is 3s rules minus 2s radio latency. Do we know for sure that the 3s rule still applies to users in a mobile situation? I wouldn’t be too confident that the 3s rule simply carries over.

    • 6

      I have read a study from compuware stating that 71% of people want a mobile website to load as fast as the desktop counterpart. This would lead me to believe that it does indeed carry over to mobile.

      • 7

        I want websites to load a second or two before I request them hehe ;)

        What I am asking is: are there any scientifically sound studies that look at user behaviour specifically when using mobile web sites?

        I don’t trust surveys or polls because many people cannot articulate their own experiences, behaviours and expectations suitably. There’s also a difference between what the user wants and what they are willing to accept.

        The article is full of good advice – I simply wanted to challenge the idea that the 3s rule transfers unaltered to mobile use. I think that assumption could leave the subsequent 1s idea as a fallacy.

        The rule could be affected by environment, or it may not. It would be very interesting to know!

        • 8

          I agree. That was my first thought. I have a totally different expectation of sites loading on my phone or my desktop. There’s also a difference between my phone on WiFi and my phone outside on 3G.

          I think the norm is defined by your average experience.

          I think the whole article is very valuable, whether or not you believe the 3 second rule. Just go for as fast as possible.

  4. 9

    At least in my opinion (and behavior), I’m more open to wait more seconds on mobile than on desktop. Specially when I’m on 3G networks, where speed is unpredictable on each request (at least in my country a connection can be the one you bought and on the next second, worse than edge and then, back to normal speed or even timeout).

    I think the 3 sec rule isn’t worldwide, because while every person expects the website to load fast, in the end the environment will shape the user’s wish to it’s speed, that is, user will grow used to wait more time since the connection isn’t that awesome.

  5. 10

    I have been reading the post of Smashing magazine from almost 6 months now and had never commented on any of the post, but this post is worth commenting. Excellent post sir.

    Long live Smashing magazine.

  6. 11

    The author suggests that separate mobile sites get a bad name due to poor implementation, but then his claims about the supposed negatives of responsive web design are, you guessed it, problems with less than optimal implementation.

    As a for instance: there is absolutely no reason that an RWD site cannot highlight site features that are most used by mobile visitors. This can all be handled easily by media queries.

    Likewise, this comment: “This is a great start, but managing different versions of the same image is a pain; the image is never ideally optimized, and the method puts the burden of resizing onto the mobile device’s limited CPU and battery.”

    First of all, there are automated solutions for this (e.g., so if you’re dealing with more than a handful of images, you don’t have to worry about the “pain.” (Not to mention the fact that maintaining separate sites would be far more of a “pain”!) Second, the writer never explains why he thinks good RWD puts the resizing burden onto the device. That’s simply false. Any mobile-first RWD design will not force the burden onto mobile.

    While there may indeed be numerous situations where a separate site is logical, it seems to me that this article is pretty misleading in its comparison to RWD.

    • 12

      I do agree with TIm on this point. The author’s points on image delivery and separate mobile sites are valid, but his stance against responsive websites lacks solid evidence.

      “Responsive Web design (RWD) limits the creative process by forcing the same content, navigation and business processes to be presented on every device, irrespective of its physical capabilities.” – For anyone who is familiar with the mobile-first philosophy, and those who really know how to work with @media-queries, this statement is simply not true.

      Checkout some mobile usability reports conduced by Google ( – in short, users expect the same website experience to be delivered, regardless of device.

      The true creative process lies in developing a solution that can effectively deliver a similar website experience across multiple devices, while developing around device limitations. This can be achieved with responsive web design, particularly when the mobile-first approach is applied.

  7. 14

    This is the best article, i search from Google to this page. Thank you

  8. 15

    Ryan Lombardo

    August 12, 2013 11:53 am


    Instead of fiddling with your router, you could just use Apple’s Network Link Conditioner tool. It gives you a few different options for simulating mobile connections.

  9. 16

    “However, they are a lot more complex to implement in script-based architectures such as PHP”

    Most of this article is great, but this part is COMPLETELY false. Preprocessing is completely built in with Rails and most other frameworks these days. Also includes the likes of asset syncing with cloud-storage and your favorite CDN too. The volume of PHP scripts that are out there which allow for preprocessing and caching are ENORMOUS and have been for some time.

    .NET has some perks over other languages (every language has it’s strengths and weaknesses) but this is not a .NET separator.

  10. 18

    This is an interesting article and has some valid points, but I am not sure I buy the “3 secs” until users lose interest rule or that it is the best choice to create mobile sites with only some of the features of the full site. No doubt, it is critical to make the initial mobile site load quickly taking in considerations the limitations of mobile, but as a heavy user of computer websites and mobile devices (phone and tablet) nothing bugs me more than a simplified mobile site without all the info and features of the full website. It frequently happens that I have read/seen something on a full site, then later go to look it up on my phone and I can’t find what I want because I am automatically sent to a simplified mobile site. I would say the best approach is to offer a simple, fast loading mobile home page with links into all the content on the full site. Designers and developers should not assume that mobile users only want certain content. Plenty of people have 4G now and power users tend to want more and better content and be more willing to spend money for it.

  11. 19

    Kenneth Brøgger-Luplau

    August 12, 2013 9:49 pm

    Hi guys

    For artificial downgrade of Internet, and logging, use Fiddler and the Simulate modem
    Speeds-functionality. This is far easier.

    You can also route a connection from your iPhone or iPad, or whatever, driectly to your localhost on your local development machine. This way you will reduce development time, by removing the upload to a server after each small change…

  12. 20

    I am not very sure about the “3 sec.” rule. Users are aware that using GPRS/2G/3G/4G and future Gs is affecting their loading times. If their minds can process that the cellular network is slow for their Facebook application, I am sure they can figure it out for the mobile browser too :)

    • 21

      I am not very sure about the “3 sec.” rule. Users are aware that using GPRS/2G/3G/4G and future Gs is affecting their loading times. If their minds can process that the cellular network is slow for their Facebook application, I am sure they can figure it out for the mobile browser too :)

      It still shouldn’t take 3 seconds for a page to load.

  13. 22

    robert mackin

    August 13, 2013 12:17 am


    This makes me wonder if it is better to create responsive websites rather then additional mobile sites.

  14. 23

    Nice read, but I think that altering the router configuration to simulate different network conditions is a bit excessive. I would suggest to achieve the same result with an app, like Slowy (on OSX) or something similar on Windows/Linux.

  15. 24

    I hope there will be a css command; “display:never-load” :D

  16. 25

    The author of this article makes his living off of a service that relies on having a separate mobile site vs a responsive site, so it’s impossible to take the author’s advice as objective.

    It is also difficult for me to take any article seriously that tries to persuade the reader that, “the user has the ability to view the original content at any time!”. Please don’t redirect me when I’m on a phone! I’m currently writing this post on an extremely capable smart phone. I want a consistent experience on websites and not have to decide whether or not the “full” or mobile version will work better for me. I paid good money for this phone, give me the full experience and make it load fast and be easy to navigate.

    A proper responsive, adaptive, mobile-first website will load faster on phones than on desktops and will be progressively enhanced to deliver a proper experience for every device. Separate content / sites are only making the web muddier, lets keep things consistent and clean for the user and always deliver the “original content”.

    There are some great points of knowledge and interest in this article, and I respect the authors opinion entirely, but the agenda-driven undertone has me a bit shocked that this article would even appear on Smashing Magazine.

  17. 26

    Agree with comments regarding the accuracy of the ‘three second rule’ with respect to mobile devices and usage. I suspect we have a second or two more to engage an average user on the move.

    Also we use Apple’s Network Link Conditioner Tool to simulate different connection speeds. Sounds like it does a similar job to the router firmware flashing.

  18. 27

    Nishant Desai

    August 14, 2013 11:08 am

    Thanks for sharing the information. I will try out the steps for my client’s website. I will contact you if need any support.

  19. 28

    I think you when you set out to truly build a mobile-only site, you can optimize more aggressively than when using RWD. That much is (largely) true. Yet in this article I have the feeling that the many cons of mobile-only sites are largely ignored, as well as the many pros of RWD.

    I am under the impression that the current consensus in the industry is that RWD is the new default, and mobile-only the exception, only when you have really strong reasons. This article flips that consensus, without strong points to back it up. By the way, what exactly is mobile? Up to 6″ now?

    I’m still a RWD believer. I believe it is entirely possible to build a fast, mobile-first RWD web experience that gets progressively richer and performs well (enough) overall. In fact, I have done so, but I won’t plug myself here, only if you ask me.

  20. 29

    Grant Bentley

    August 20, 2013 3:46 pm

    Has anyone been using New Relic software to help the performance monitoring process?

  21. 30

    A good tip on mobile websites… here’s the website with full of responsive designs named


↑ Back to top