Sorry, your site is not responsive

Responsive sites are here and have been for a while now. I think they’re great but I cannot help feeling that a lot of people are missing an important point.

After years in the making you’re finally ready to show your brand new site off to the world. You happily smile and take the compliments and proudly say its responsive. You talk about all the hours spent on the design, on prototyping ideas, on user testing and on getting the content just right. But something is not quite right, the site feels sluggish and slow. That’s because an important step was rushed. The build.

It seems to me that many site owners are seeing the build as a barrier to getting a website operational. “When will it be ready” seems to be a question I hear a lot. It’s a fair and important question but one that is already saying to me, hurry up please.

We should be educating our clients as to the importance of page performance and discussing ways in which we might load imagery and other static files, providing options for implementing a CDN and processes for compressing files. We mustn’t let these things be pushed into “phase 2” development in an attempt to get to an earlier release date.

Just this week Halifax has updated its website and made it “responsive”. They even provide a definition for what responsive means:

It means that no matter what device you’re using to visit halifax.co.uk, the site will adapt to fit to your screen. You can see and interact with the same content, from mobile phones to home computer screens.Halifax

Well, ok. But let’s look at the load time over a 3G network for the new site.

halifax load time 3g

This diagram shows that content doesn’t appear for over seven seconds, which is way too long. Surely you cannot claim that a site is responsive if it takes this long to load on a mobile device?

So what could be done to improve Halifax’s site?

Google PageSpeed Insights is quite a helpful starting place. The ranking can be sometimes seem quite brutal for seemingly “little” things but it can give you a feel for where you are at (36/100 for mobile speaks volumes for Halifax).

I would recommend that Halifax focuses on the following three major issues and potential fixes to help improve site performance.

Enable compression

Enabling compression for the Halifax homepage could save 716 KiB, or put another way, 83% of the respective files. But what does this achieve? Surely compressing content on the server to uncompress it on the client side will just add extra strain? Yes, it does increase CPU time but it saves more time than it uses.

To demonstrate this, I conducted a small experiment that had just over 10,000 requests (50 active users requesting the site every second) to compressed and uncompressed versions of a homepage. The first graphic shows response times for an uncompressed version of the page. The second graphic shows the same test with a compressed version. As you can see there is a significant saving of 17%

load times uncompressed
10,000 requests to an uncompressed homepage shows an average response time of 168ms
load times compressed
10,000 request to a compressed homepage shows an average response time of 140ms

Eliminate render-blocking JavaScript and CSS in above-the-fold content

There are nine scripts files and eight CSS files blocking the page from loading. This is almost definitely what is causing the page to take over seven seconds to start showing content. It is a bit harder to solve given the page can have dependencies on these files and not loading them in the correct order can also cause issues.

Regardless, it is a big issue that needs careful thought. However, in general, putting all your javascript files at the bottom of the page can stop render-blocking. You could even get a little more fancy and load non-essential javascript files in via AJAX call. Taking this even further, since a website should work without any javascript files, then you could AJAX all your files.

Leverage browser caching

You can leverage browser caching by setting a few lines in a .htaccess file or web.config file. Not doing so makes no sense. Images, CSS, fonts and Javascript (and more) would hardly ever change so why not inform the browser to use the last file you sent it? When the time does come for changes then you can rename the file or append a version number to the query string.

Is it really worth it?

You bet it is! If you really want a site to be responsive then you need to tackle all the issues and site performance is definitely one of them. It’s great to see people are doing it and there is an excellent case study from Smashing Magazine that shows how they achieved it.

  • Ben

    A lot of really good info here but the hijacking of the term “responsive” I find annoying. “Responsive” has a very specific definition in the web development field (the definition that Halifax provided). What this article is discussing is “performance” not “responsiveness”.

    On a daily basis I have to deal with too many people, even other web developers, who are confused about what responsiveness means. An article like this only helps foster this confusion. Performance is a very important topic and is something that too many developers ignore. Let’s be clear about the topic rather than using misleading terminology.

    • mazurka

      Responsive design may have a specific definition but that’s becoming an archaic way of thinking, considering we are pushing toward responsive as a web philosophy, which most definitely includes performance. In fact, responsive may have been a philosophy all along but perhaps Ethan found it appropriate to first introduce the design component which is easily digestible.

      • Ben

        I think it’s archaic only in the sense that we shouldn’t even be talking about making a site responsive. It should simply be baked in to all web design/development. We’re clearly moving that way but we’ve still got a ways to go.

        There’s definitely been more of a push to increase site performance in the industry but I’ve seen people using terms like “high performance” or “performant” rather than “responsive”.

        Given the current state of the industry I just see using “responsive” and “performant” interchangeably as inviting confusion rather than removing it.

        • mazurka

          “we shouldn’t even be talking about making a site responsive. It should simply be baked in to all web design/development.”
          great point.

  • level2d

    Very good article. We constantly fight this battle with clients and we have found that putting dates on completed projects is increasingly more difficult because of the increasing variables. What is the typical length of time you allocate for a medium to large web project?

    • Chris

      On most projects it will only take a day or so to make sure the site is compressed, the server caches, and everything is minified. However, more time could be spent improving the deployment process of the website and how you make sure every release has minified files etc. Realistically for medium and large projects this should only add a few more days.

      Tackling issues such as image optimisation and render-blocking content could take more time. With some websites this might be a few days but it could go up quickly, especially if you are dealing with legacy code.

  • DOMContentLoaded (“DOM ready”) is probably not a good metric for determining how fast content is displayed, as the top-most content might be rendered much sooner depending on how big and complex the site is. The best metric for this is the Speed Index, I think (measured via webpagetest.org).

Headscape