Key Points
- There is a nearly infinite range of device sizes and capabilities. This is adding a great deal to the complexity of publishing a site for the mobile web.
- Correct annotations communicate a relationship between a desktop page and its smartphone-optimized equivalent. Knowing this relationship allows Google’s algorithms to handle both URLs correctly.
- The HTTP Vary: User-agent header helps caches to not show a desktop user-agent a cached smartphone page, and vice versa, and it’s a signal that Googlebot-Mobile for smartphones should crawl this page.
- Responsive Web Design can be implemented in a way where the full content of the page does not need to be downloaded to a mobile device. There are many options and considerations that apply to each page and webmasters need to figure out what optimizations are best for their content.
- While thinking about what a mobile device downloads, also consider how it gets downloaded and rendered.
- It may be advantageous to inline part of the CSS or JavaScript to help the browser render the page, or at least part of the page, faster while the rest downloads in the background.
- RWD does come with the baggage of the full content being delivered to the device and the screen size optimizations being performed client-side.
- There is plenty of evidence that searchers use smartphones to do tasks that webmasters have historically considered “desktop only”, and do so in locations where a desktop with a broadband connection is available such as at home or work.
- Consider the technologies used on your pages. For example, Flash content is not viewable on a large number of smartphone devices.
- Looking at what different responsive websites do shows that similar websites emphasize different aspects of their pages, and do so differently.
We have all seen that the use of mobile is exploding. Yet publishers have been slow to fully optimize their sites for this new web experience.
One thing Pierre pointed out to me is that people get confused about what mobile refers to. Historically it used to mean what we now call “feature phones”. Ironically, in my view, these are the phones without features! They usually have very small screen sizes and numeric only keypads.
Nowadays this definition includes smartphones, with their larger screen sizes and more complete keyboard capabilities. For many, the definition also includes tablets as these devices are meant to be carried with you. Google itself has blurred this definition a bit with their Enhanced Campaigns for AdWords, which lumps tablets together with desktops.
“In addition, we keep seeing new devices which are oversized smartphones, and other new devices which are smaller and smaller tablets. As a result, we have a nearly infinite range of device sizes and capabilities.”
In addition, we keep seeing new devices which are oversized smartphones, and other new devices which are smaller and smaller tablets. As a result, we have a nearly infinite range of device sizes and capabilities. This is adding a great deal to the complexity of publishing a site for the mobile web.
Pierre Far is one of Google’s experts on the mobile web so I sent him some questions by email to get his take on how publishers should approach these new challenges.
Eric Enge: What are the best practices for tagging desktop pages and mobile pages in a mobile sub-domain architecture?
Pierre Far: We support three configurations for smartphone-optimized websites. Having a separate site on subdomains is one type of separate URLs setup and the annotations are explained in our recommendations site.
Notes from Eric: From the above listed link, here is a look at the basic annotations recommended by Google:
If the desktop page URL is http://www.example.com/page-1, than the rel alternate tag on the desktop page should point to: http://m.example.com/page-1.
If the mobile page URL is http://www.example.com/page-1, than the rel canonical tag on the mobile page should point to: http://www.example.com/page-1.
You can also note the presence of the two versions of the page in your XML Sitemaps file:
Pierre Far: The annotations essentially communicate a relationship between a desktop page and its smartphone-optimized equivalent. Knowing this relationship allows our algorithms to handle both URLs correctly.
Eric Enge: What are best practices for tagging desktop pages and mobile pages that are shown on the same URL (not using RWD)?
Pierre Far: This is called dynamic serving and it’s one of the configurations we support. The trick here is to communicate to Googlebot and to ISP caches that the content of the page varies depending on the user agent.
HTTP has a standard mechanism for that, using the HTTP Vary: User-agent header. This helps caches to not show a desktop user-agent a cached smartphone page, and vice versa, and it’s a signal that Googlebot-Mobile for smartphones should crawl this page.
Notes from Eric: Here is what the HTTP Vary: User-Agent header looks like:
The header signals to Googlebot and ISP Caches that the different user agents may be served different content. Googlebot uses this as a flag that there is a mobile optimized version of the content.
Eric Enge: Can (Responsive Web Design) RWD be implemented in a way where the full content of the page does not need to be downloaded to a mobile device? One of the worries publishers have is that the page size may be too large for mobile devices.
Pierre Far: In short: Yes. There are many options and considerations that apply to each page, and webmasters need to figure out what optimizations are best for their content.
“While thinking about what a mobile device downloads, also consider how it gets downloaded and rendered. For example, it may be advantageous to inline part of the CSS or JavaScript to help the browser render the page, or at least part of the page, faster while the rest downloads in the background.”
While thinking about what a mobile device downloads, also consider how it gets downloaded and rendered. For example, it may be advantageous to inline part of the CSS or JavaScript to help the browser render the page, or at least part of the page, faster while the rest downloads in the background. Page speed for smartphones is a big topic and we have some starting points here.
Notes from Eric: Expanding on Pierre’s response, my research shows that RWD does come with the baggage of the full content being delivered to the device and the screen size optimizations being performed client-side. However, there are some things you can do to reduce this burden.
The link provided by Pierre links to four other articles on mobile web performance:
- Make Your Mobile Pages Render in Under One Second
- Make the Mobile Web Faster
- Optimize for Mobile
- Google Pagespeed Insights
Here are some suggestions from the article referenced by Pierre:
- Move the Javascript and CSS for rendering the content above the fold out of external files and into the code of the page inline. The reason this helps is that the time to go fetch external files on a mobile device are a big time sink.
- Delay or make asynchronous the loading of Javascript and CSS for content below the fold.
- Keep the initial HTML payload to load the page (above the fold) as small as possible. If you can keep it under 15 KB, this will allow the transfer of this data to happen in about 100 ms.
- Minimize server backend time to generate the HTML. Ideally under 100 ms as well.
- Eliminate redirects from the process.
- Make landing page redirects cacheable by the user’s browser. This speeds things up on return visits by the user.
- ” HTML5 browsers that support CSS3 (again, Mobile Safari, Android) can use attributes for rounded corners, gradients, shadows, text transformations, canvas, and more. Using CSS to design your page instead of images can reduce data transfer.” (https://developers.google.com/speed/articles/mobile)
There are many other suggestions in these articles, and if you are very serious about mobile you should not only read these articles (or have your developer read them), but you should integrate a deep understanding of them into your development plan.
Some other resources of interest include:
- How to do Server Side Device Detection
- Building a Better Responsive Web Design Site
- How to Not Load Some Images in a Responsive Design
- Source Shuffling – Responsive Images Based on Media Queries
Eric Enge: What should publishers using RWD do if they have some pages they want to implement that are mobile only? Or, correspondingly, what should publishers using RWD do if they have some pages these wanted to implement that are desktop only?
Pierre Far: Firstly, I would take a step back and think about the assertion that a page can be “desktop only” or “smartphone only”. Sure, some pages may be used more by users on different devices, but I’ve yet to see an example where content is useful only for one type of device. On the contrary: there is plenty of evidence that searchers use smartphones to do tasks that webmasters have historically considered “desktop only”, and do so in locations where a desktop with a broadband connection is available such as at home or work (the Mobile Search Moments Study from Google has more details).
Secondly, as a rule of thumb, such pages will be indexed normally (assuming Googlebot can crawl them and there isn’t a noindex meta tag) and will be shown in search results if we think they’re relevant to the user’s query.
Thirdly, consider the technologies used on your pages. For example, Flash content is not viewable on a large number of smartphone devices. Similarly, different video encodings are needed for the video to play on different devices; the HTML < video > and < source > tags help in this case.
Eric Enge: What should publishers do if they want a more substantial content change between the page that shows on a Smartphone vs. a desktop size screen. For example, they might want to emphasize the phone number and driving directions on a Smartphone size screen and not have that at all on the desktop version of the page. Is there a way (or need) to alert Google to this type of scenario?
Pierre Far: Great question and it’s one I pay attention to a lot. Fundamentally this is a design question about what and how to emphasize. Looking at what different responsive websites do shows that similar websites emphasize different aspects of their pages, and do so differently. For example, I’ve seen some retailers emphasize their latest offers while others emphasize their store locator or their site search feature. Only the webmaster can choose what to emphasize, and you can do so with CSS and JavaScript.
Using CSS media queries to alter the rendering of a page is fairly easy to understand. For more complex page changes, you can use JavaScript to include different content for different devices. Assuming that content included using JavaScript is genuinely not useful on specific devices, this may be a good solution. We have tips about using JavaScript in conjunction with responsive design.
As for “alerting” Google this is happening, webmasters should make sure that Googlebot is able to crawl all the page assets including images, CSS and JavaScript, as that allows us to access all the content as a user would see it, and index content accurately.
Eric Enge: Thanks Pierre!
Pierre Far: Thank you Eric!
About Pierre
As a webmaster trends analyst, Pierre follows industry trends in SEO and web development in order to help different Google teams build better tools for webmasters and improve search quality. Pierre also writes for the Webmaster Central Blog and participates in Google and external forums, helping site owners troubleshoot search-related problems and get the most out of Google Webmaster Tools.
