If you're a content publisher that utilizes
Google Webmaster
Tools to monitor the health of your website, you may have received a rather
ominous email from Google recently proclaiming the mobile unfriendly nature of
your site with a side serving of upcoming detriment to your search engine ranking as a
result. For our site JavaScript Kit, that email was equally grandioso, with
apparently all of the 1200+ pages on our site giving mobile users the cold
shoulder:

Screenshot: Ominous email from Google

It turns out these warning emails are more than just benign
suggestions; starting on April 21st, 2015, a significant update to
Google's rankings will apparently prioritize mobile optimized sites placements
over non optimized in Google's search results for mobile searches, or searches
done in mobile devices. If your site has a growing mobile audience you will be
at the front line of experiencing a negative hit from the new Google update. For
the rest of us the writing is on the wall.

-Is my site mobile friendly?

Google has released the
Mobile Friendly Test Tool to let you quickly determine if a page passes the
mobile test. Enter a URL to see if a page passes muster, and in turn,
deduce the same for similar pages.

-2 steps to resolving mobile usability issues with Google

The aim of the following guide is to help you quickly address
those pesky mobile usability issues Google is complaining about that will
adversely affect your search engine rankings from April 21st 2015 and onwards.
It is not meant as a comprehensive guide to making your site mobile optimized.
From there you will want to delve deeper into the subject of transforming your
site to be fully responsive and future proof.

STEP 1: Add the proper DOCTYPE and viewport META TAG to the top of your page

The start of every mobile friendly page begins with the
following- adding the HTML5 DOCTYPE to the very top of your page and the
viewport META tag to the HEAD portion:

These new additions are the vey first things Google checks for
for mobile usability compliance. The
viewport meta tag once added does something tangible- it triggers the mobile
browser to start showing your page in its actual dimensions relative to
the dimensions of the mobile browser, so a 800px wide page on a 320px wide mobile
device will now show, well, only 320 pixels of the page at a time. Prior to
adding the viewport meta tag, the mobile browser will automatically put the page
into a "virtual window" that's zoomed out to fit the entire 800px wide page on
its tiny 320px screen, zooming out everything to make that possible:

With the viewport meta tag added, there's now no going back on
your journey to making your page mobile friendly, as stopping here will actually
do more harm than good to the mobile user experience- with no automatic zooming
out of the page, everything on the page appears as is dimensions wise on the
tiny screen. Without further optimizations from the webmaster -you- it makes
viewing the page even more cumbersome for mobile users, having to scroll a
million miles to get to various portions of the page.

Once the doctype and viewport tag are added, the next items on
Google's checklist are:

Whether the layout of your page adapts to the width of the
mobile device's width, so users don't have to constantly scroll horizontally
to view the primary content in its entirety. If your layout currently
uses a fixed unit such as 960px for its width, that needs to be changed to a
fluid unit (ie: %), at least when the page is being viewed in a mobile
setting.

Whether the font size and line spacing are adequate, Usually
on a mobile device, both need to be increased from their default values for
an optimal experience.

All this may sound rather daunting, but fortunately there is an
existing tool within CSS that can handily take care of both issues
while allowing you to surprise the wife and kids in time for a lunch date if you
are so inclined. That weaponry is
CSS Media queries,
a universally supported CSS feature whose key trick is its ability to be
triggered based on the desired "media" condition, which includes everything from
the dimensions of the mobile device or browser, orientation, to pixel density of
the screen. In other words, everything we need to react to the device
currently viewing the page.

Taking the simplest/fastest path to getting your page Google
mobile friendly certified, what you'll want to do is to use CSS media queries to
conditionally hide secondary elements on the page so the primary content is
front and center and viewable without horizontal scrolling when the screen gets
sufficiently small. We start by doing the following:

Identify non primary elements on your page such as the left
side bar and large banner ads and assign these containers each an unique ID
attribute in which to refer to them in your CSS later.

Identify the primary content on the page and give its
container an unique ID attribute as well.

The strategy is to hide the non primary elements and optimize
the primary content container so the later becomes fluid in width, its font and line spacing
increased when the screen becomes sufficiently small (detectable using CSS media
queries). On a two column page built on top of a legacy two columns TABLE
layout, here's a graphical look of the game plan:

To accomplish the above, we'll make use of the much touted CSS
media queries, by adding to the very end of our existing CSS file (.css) or
inline <style> tag the following:

The syntax is pretty straightforward- each media query condition
consists of @media (conditions){...}, where normal CSS is added
inside its curly parenthesis that are only applied when the specified
condition(s) are met (and removed when not).

In the above I've defined two CSS media queries that are matched
when the user's browser/device width is 860px or below, and 600px, respectively.
Resize the browser window past the defined breaking points to see how the page
responds. Like everything in CSS, styles from multiple media queries cascade and are
applied to in addition to if multiple conditions are matched. So in the case of
the second media query of 600px and below, when matched, the page also receives
the styles defined inside the 800px media query as well. Notice how I've given
certain CSS rules a suffix of !important- do this whenever you
notice the proceeding defined CSS value not being applied despite a matching
condition, which can occur if there exists any CSS styles on the target element
already with a higher
CSS specificity than that of your mobile style's. Inline CSS declarations
directly defined within an element's tag for example always takes precedence over
those defined in an external CSS file or globally in the HEAD section, which can
sideline our carefully crafted mobile styles without !important to
the rescue.

- Check it now Google!

The above two steps are sufficient in transforming most
desktop-era pages to be mobile friendly enough to pass Google's discerning eyes.
The proof is in the Google mobile usability test results:

So our road to passing Google's mobile test has been the
following: Add a valid doctype and viewport meta tag to your page, then use CSS media queries to hide secondary elements on your page
while making the primary content fluid in width to span the entire viewport.
Hiding the secondary elements helps free up valuable real estate for the primary
content to live in and prevent horizontal scrolling to access portions of the
content. Finally, when the device screen is small enough, increase the font size
and line-height spacing if needed to make it more legible on the
small screen.

A tale of two max widths- max-width and max-device-width
In the CSS media queries of Step 2 above, we've used the keyword max-width
exclusively to detect the size of the browser window at and below the desired
threshold before the enclosed CSS gets applied. There is another keyword you can
use instead in its place, and that's max-device-width.
max-device-width matches not the the width of the browser window, which
on a desktop computer can be resized by the user, but rather, the device's
entire screen width, which does not change. On a desktop
with screen resolution 1024x768 for example, the device-width is
always 1024. On an iPhone 6, that value is 375. Substituting max-width with
max-device-width instead in our CSS media queries is useful if you wish to only
apply the mobile CSS to actual mobile devices, instead of desktop browsers as
well whose browser widths are sufficiently small. A modified CSS media query of:

will essentially only be applied on actual mobile devices with device-width of
600px or less, as no modern desktop computer has a resolution of 600px
horizontally these days. This approach can be desirable if you want to maximize
the viewership of your default non mobile layout, as desktop users will always
receive the default set of CSS. See "Introduction
to CSS Media Queries" for additional info on the subject.

Testing your CSS media queries by resizing your desktop's
browser window isn't always sufficient in getting an accurate glimpse of how the
page will look on mobile devices. That's why on the next page, we'll check out
two invaluable tools for simulating/ testing your page in different devices.