Get Free Quote
« SMX Liveblog: Baidu... | Blog home | How to Set Up Google... »
June 5, 2015

Google Wants You to Make Your Site Faster or They’ll Do It For You. Will You Like the Result?

  • Print Friendly

In April, around the time of Google’s “Mobilegeddon” mobile ranking update, the search engine announced another mobile optimization in testing. Via the Webmaster Central Blog, Google said they’d “developed a way to optimize pages to be faster and lighter, while preserving most of the relevant content.” In other words, if you don’t optimize your site so that it loads quickly for mobile devices, Google will try to do it for you.

(Get your All-In-One Mobile SEO and Design Checklist here.)

Called transcoding, Google says it’s a feature intended to help deliver results quickly to searchers on slow mobile connections. Google’s early tests show that transcoding returns pages with 80 percent fewer bytes and 50 percent faster load times. Indonesia has been the staging ground for early field tests, displaying transcoded sites when a mobile searcher is on a slow connection, like 2G.

Sounds cool, right? Now website owners and SEOs don’t need to worry about optimizing sites to be fast; Google is going to do it for us! What a magnanimous thing for Google to do. Except that there are a couple of reasons why Google’s low bandwidth transcoder should give developers and webmasters pause.

The Cons of Transcoding

  1. Google says the optimized versions preserve “most of the relevant content.” There are two editorial decisions in that phrase: most and relevant. The biggest problem here is that Google, not you, decides which of your content is relevant, and how much of it to show.
  1. You probably didn’t hire a bot to design your website; do you want a bot optimizing it? Take, for example, the BruceClay.com home page, where it becomes evident that a lot of styling gets stripped out:

 

google-transcoder-example

A page optimized by Google transcoding (left) next to the original version of the page (right). Click to enlarge.

 

The Pros of Transcoding

For each of the cons, some sites could see real benefits from Google’s transcoding:

  1. For many websites owners, users’ seeing a stripped-down version of a site is better than not seeing it at all.
  1. Google includes a link to the original page on the transcoded version, so users have the option to see the page how you built it.
  1. Transcoded pages are undoubtedly fast. For a detailed comparison, I ran the two pages above through GTMetrix and came up with the following results:
Page Load Time Total Page Size Total Requests
Original Version 3.71 seconds 1.94 MB 155
Transcoded Page 0.56 seconds 17.3 KB 2

 

Viewing Your Transcoded Page

If you’re curious to see how your site renders when it’s been transcoded by Google, there’s a tool to show you just that. You’ll need to do a little workaround if you’re outside of Indonesia:

  1. Using the Chrome browser, go to the Low Bandwidth Transcoder emulator at https://www.google.com/webmasters/tools/transcoder.
  2. Click the toggle menu in the top right corner of the browser window, then click More tools and then Developer tools.
  3. Along the top of the window you’ll see two drop-down menus: Device and Network. Select any smartphone device from the menu selection, like the Google Nexus 4.
  4. Enter the URL you want to test in the “Your website” field and click the Preview button.
  5. Click the URL that appears below the text “Transcoded page:” and you will see how the page renders as Google transcodes it.

 

When Will We See Transcoding in the Wild?

A lot of this has to do with being lightweight; it’s not enough to use CDNs or have a high-end server. Google cares about the experience of people who access the web at the narrow end of a bottleneck, which is completely out of the hands of web developers. Your fast server only means so much to users on a 2G network.

At this point, we have no idea when, if at all, this functionality will be implemented anywhere outside of Indonesia. However, Google’s underlying statement is clear: websites should be really, really fast.

For information on how to optimize your pages for speed and mobile SEO, we recommend starting with these resources:

mobile-seo-and-design-checklist

  • Print Friendly




17 responses to “Google Wants You to Make Your Site Faster or They’ll Do It For You. Will You Like the Result?”

  1. Andy kuiper writes:

    interesting – going to try a test – thanks John :-)

  2. John Alexander writes:

    Andy- glad to help. I think it’s good to be reminded that some of visitors to our websites are dealing with older technology, and the faster our content loads, the easier we make life for the user. That being said, I know how technically difficult it can be to implement these things.

  3. Richard Brus writes:

    That styling comparison image you’ve shown makes the homepage look very amateurish indeed. I wonder if they’ll invent a meta tag to give site owners the choice of whether they want their sites transcoded it or not. For certain types of sites that dramatic styling change would cut conversions in half. Hopefully they’ll come up with an option in Webmaster tools to give site owners a choice.

  4. R.Rogerson writes:

    Well, to be honest – Good.
    It’s been years since Google started telling us to make sites faster.
    People only paid a bit of attention when they thought (mistakenly) that speeding up their site would improve their rankings.
    But instead – most sites are still far slower than they could be – with no real reason bar laziness of designers.

    It’s not like people like Steve Souders (who ended up at Google) didn’t supply plenty of information years ago.
    Even Google and Yahoo went to the lengths of creating Tools to measure your speed and recommend what to fix.
    But still, the vast majority of sites load up numerous CSS and JS files, have unoptimised images and use poor-performing 3rd party content calls (like adverts).

    You looked at your homepage.
    So are you surprised at G’s treatment of it?
    Because I’m not.
    * All those iframes mean additional page requests.
    * You are requesting several JS files multiple times. Even if caching properly on the browser (and mobile tends to have issues with that), you still make the requests for freshness. On mobile that’s more noticeable too.
    * Multiple different JS files, rather than a single combined one?
    * Try using Defer of Async for JS file calls, (or at least shove them at the bottom of the /body section).
    * Multiple different CSS files, rather than a single combined one?
    * No freshness headers on some of the CSS and images – why make people re-download that content … esp. if on a mobile network?

    And that’s a 15 second look. You could easily shave of a whole second with a tiny bit of effort,
    and that’s without getting into complicated stuff like sharding domains or attempting to Device sniff to remove certain content (hiding it doesn’t mean it won’t be downloaded – it just means you waste their bandwidth and time for something they won’t see).

    So chances are, G will automatically do that sort of thing for slower device users. And so they should!
    They have no choice, because far to many people haven’t bothered to follow the best-practices.

    I’m going to guess that there are certain triggers for it.
    Though basing it on complete-size (we are talking about 2G networks) would make some sense … it seems a little extreme.
    Overall speed is an obvious one – but I think things like the number of resource requests will also be used, along with with content/resources are compressed.

    Why not do some testing?
    Copy your homepage several times (after stripping the iframes).
    1) Point to multiple uncompressed CSS/JS
    2) Point to multiple compressed CSS/JS
    3) Point to combined but uncompressed CSS/JS
    4) Point to combined and compressed CSS/JS
    Try those base versions with additional paired-variants,
    such as sending/not sending Cache Control headers for the CSS/JS/Img/HTML and using compressed/uncompressed HTML.

    That should show you if there is a trigger, and allow you to identify it, (if it’s not based solely on “size”).
    Be an interesting followup post, no?

  5. John Alexander writes:

    R.Rogerson- thank you for your analysis. I agree that this was a much-needed shot in the arm for web design in general, and I appreciate your recommendations for our own site; I’d love to write that followup post, so stay tuned.

  6. Cathie Dunklee-Donnell writes:

    This surprises me that Google would do this. They are going to make sites faster for free? I have to try it out.

  7. Cathie Dunklee-Donnell writes:

    I tried it and it is awesome. It makes slow and non-mobile friendly sites look great on a smart phone. I worry no clients will want us to make them mobile-friendly after this.

  8. John Alexander writes:

    Cathie- thanks for the feedback! However, I would offer a couple of caveats.
    1. In the post-Mobile-geddon world, we know that Google uses mobile-friendliness as a ranking factor in mobile searches. (Bing has been doing this for quite a while.) So relying on the transcoder, rather than making your site mobile-friendly, could hurt rankings.
    2. Even though some might, not all sites are going to look “awesome” when transcoded. This is Google’s version of web-design triage, and in some instances valuable design elements will be stripped from your site because they take up too much space. Wouldn’t it be better to make your site load quickly and retain your design elements, rather than run the risk of getting them cut out by an algorithm?

    That being said, this is a very cool technology that opens up new functionality for people on slower internet connections, and it will be interesting to see what comes next.

  9. Scott Paparella writes:

    I’ve found no identified threshold for when Google would decide to use their transcoded version over yours, and vice versa. Any ideas as to what that number is? It sounds like we need a schema to identify priority for the transcoder to follow.
    Good article, John.

  10. John Alexander writes:

    Scott: I like the idea of a schema to prioritize on-page content. However, truly optimized web design involves prioritizing the load order of pages, so that all above-the-fold content loads quickly. So Google’s stance would be that your above-the-fold content should load in under a second anyways. (http://googlewebmastercentral.blogspot.com/2013/08/making-smartphone-sites-load-fast.html)
    It seems that Google offers webmasters another option, if you don’t want your site “transcoded”: by using the rel=”alternate” tag you can designate a faster, streamlined version of your important pages for mobile users. (https://support.google.com/webmasters/answer/35312?hl=en)

  11. R.Rogerson writes:

    Thank you for the response John … was beginning to think my text smelled bad or something :D

    I would love to see the testing and the results (I think you’d be the first?).
    I know setting up such tests is a pain in the idiomatics, but could yield some useful information.

    As for the rel-alternate…
    … though G may point it out – there is no guarantee they will adhere to it – now or in the future. Such things tend to be viewed as a strong hint. Further, G prefers a single URL (though I’m sure that originally they suggested 2 different URLs to begin with?).
    Else we are kind of working backwards, to the “good old days” (feels sickening just thinking about it) of browser sniffing, and providing variant content dependant on platform.

  12. Website Designing writes:

    Many many thanks John. This is alarming as nobody would want a bot to decide what to show and what to not, out of our hard work. Is there anyway to optimize the website for transcoded version. Pls let us know.

  13. John Alexander writes:

    Website Designing: the only reason that sites get transcoded is because they’re too slow to load on slower network connections. So to avoid having that happening, we need to make websites that are really, really fast. Google explicitly states that they prefer sites that can load in under a second. (http://googlewebmastercentral.blogspot.com/2013/08/making-smartphone-sites-load-fast.html) And that was back in 2013! That blog post has some high-level recommendations; you can also use the PageSpeed Insights tool (or even run an audit in Chrome using the Developer Tool) to find what is slowing your site down.

  14. Website Designing Company writes:

    Thanks for sharing the link to the Blog. The Page Insight Tools is great to implement the fixes required for faster page caching.

  15. Jeff Pederson writes:

    Thanks for sharing. I would say in most cases I would not want Google using this. To have ones site ever look super stripped down is not a good alternative for waiting to make your site responsive.

  16. SEO Sultan writes:

    Very interesting, I just wrote a post about this and created a WordPress plugin to disable / prevent Google from trying to optimize your website. You can click my name to go to it.

    I was amazed there was no plugin out there to help WordPress users on this, so I created my own – it’s relatively simple, so hopefully it’ll help everyone who’s looking to avoid having ad / analytic traffic stolen from this change.

  17. NIRANKAR SHARMA writes:

    Dear Sir

    Really I had wonderful results by using the Google Trans-Coding facility in my Smart Phone (Spice M-6112)having basic features only.

    Thanks a Lot.



Get Started
Learn SEO

Subscribe to Blog Updates

Get email notifications when we publish new blog posts, usually two to three times a week.

  

a monthly digest keeping digital marketers in the know with SEO, SEM, social media and content marketing hot topics, live events, corporate shuffles, and deserved kudos.

We respect your privacy and never share your email address

Free Executives Guide To SEO
By continuing to use the site, you agree to the use of cookies. AcceptDo Not Accept
css.php