This content originally appeared on Hidde's blog and was authored by Hidde de Vries
From 21 April, Google will start preferring sites it considers “mobile friendly”. The criteria are listed in a blog post and Google provide a tool for web masters to check whether they deem websites eligible for the label.
First, we should define what we are trying to be friendly for here. What’s the ‘mobile’ in ‘mobile friendly’? Is it people on small screen widths, people on the move, people with a slow connection? The latter is interesting, as there are people using their fast home WiFi on a mobile device on the couch or loo. There are also people who access painfully slow hotel WiFi on their laptops.
Assumptions are pretty much useless for making decisions about what someone is doing on your site. Mobile, as argued before by many, is not a context that helps us make design decisions. We’ll accept that for the purpose of this article, and think of mobile as a worst-case scenario that we can implement technical improvements for: people on-the-go, using small devices on non-stable connection speeds.
Great principles to start with
So what are Google’s criteria for mobile friendliness? According to their blog post, they consider a website mobile friendly if it:
- Avoids software that is not common on mobile devices, like Flash
- Uses text that is readable without zooming
- Sizes content to the screen so users don’t have to scroll horizontally or zoom
- Places links far enough apart so that the correct one can be easily tapped
(Source)
Websites that stick to these criteria will be much friendlier to mobile users than websites that don’t. Still, do they cover all it gets to be mobile friendly?
It passes heavy websites, too
At Fronteers, we celebrated April Fool’s by announcing, tongue-in-cheek, that we went all Single Page App. We included as many JavaScript libraries into the website as we could, without ever actually making use of them. It made the page much heavier in size. We also wrapped all of our markup in elements, with no actual JavaScript code to fetch and render content. The site became non-functional for users with JavaScript on. External scripts were included in the <head> of the page, so that their requests would block the page from rendering. With JavaScript turned off, the site was usable as usual, with JavaScript on, all the user saw was an animated spinner gif.
All the user saw was an animated spinner gif
Probably not particularly funny, but it showed a problem that many modern websites have: loading content is made dependent on loading JavaScript, and lots of it. This is not user friendly, and certainly not friendly to users on wobbly mobile connections. In our extreme case, the content was made inaccessible. Still, as Krijn Hoetmer pointed out on Twitter this morning, the joke —still live on the page announcing it (view the source) — passed Google’s test for mobile friendliness:
Nope, Google, a media query doesn’t make a site “Mobile-friendly”. Your algo needs some love: google.com/search?q=site:… pic.twitter.com/GPgEfkpKLV
I think he is right, the algorithm could be improved. This is not trivial, because the algorithm has no way to find out if we intended to do anything more than display a spinner. Maybe we really required all the frameworks.
The tweet inspired me to formulate some other criteria that are not currently part of Google’s algorithm, but are essential for mobile friendliness.
Even more friendly mobile sites
There are various additional things we can do:
Minimise resources to reach goals
Slow loading pages are particularly unfriendly to mobile users. Therefore, we should probably:
- Be careful with web fonts
Using web fonts instead of native fonts often cause blank text due to font requests (29% of page loads on Chrome for Android displayed blank text). This is even worse for requests on mobile networks as they often travel longer. Possible warning: “Your website’s text was blank for x seconds due to web fonts” - Initially, only load code we absolutely need
On bad mobile connections, every byte counts. Minimising render-blocking code is a great way to be friendlier to mobile users. Tools like Filament’s loadCSS / loadJS and Addy Osmani’s Critical are useful for this. Possible warning: “You have loaded more than 300 lines of JavaScript, is it absolutely needed before content display?” - Don’t load large images on small screens
Possible warning: “Your website shows large images to small screens”
Google has fantastic resources for measuring page speed. Its tool Pagespeed Insights is particularly helpful to determine if you are optimising enough. A reason not to include it in the “mobile friendly” algorithm, is that speed is arguably not a mobile specific issue.
Use enough contrast
If someone wants to read your content in their garden, on the window seat of a moving train or anywhere with plenty of light, they require contrast in the colours used. The same applies to users with low brightness screens, and those with ultramodern, bright screens who turned down their brightness to deal with battery incapacity.
Using grey text on a white background can make content much harder to read on small screens. Added benefit for using plenty of contrast: it is also a good accessibility practice.
Again, this is probably not mobile specific; more contrast helps many others.
Attach our JavaScript handlers to ‘mobile’ events
Peter-Paul Koch dedicated a chapter of his Mobile Web Handbook to touch and pointer events. Most mobile browsers have mouse events for backwards compatibility reasons (MWH, 148), he describes. That is to say, many websites check for mouse clicks in their scripts. Mobile browser makers decided not to wait for all the developers to also check for touch behaviour. So, mobile browser makers implemented a touch version of the mouse click behaviour, so that click events also fired on touch.
Most mobile browsers listen to touch events, like touchstart or gesturechange (iOS). So maybe we could measure mobile friendliness by checking if such events are listened to? This is a tricky one, because a script that only listens to click events can be mobile friendly, because of backwards compatibility.
Depending on the functionality, JavaScript interactions can be improved by making use of mobile specific events. Carousels (if you really need to) are a good example of this: adding some swipe events to your script can make it much more mobile friendly. Or actually, like the two above, it would make it friendlier for all users, including those with non-mobile touch screens.
Even more friendly sites
Page speed, colour contrast and touch events may not be mobile specific, but I would say that goes for all four of Google’s criteria too. Legible text helps all users. Tappable text also helps users of non-mobile touch screens.
If we are talking about improving just for mobile, Google’s criteria are a great start. But we need to work harder to achieve more mobile friendliness. Above, I’ve suggested some other things we should do. Some can be measured, like improving load times and providing enough contrast. These things are friendly to all users, including mobile ones. Other things will have to be decided case by case, like including ‘mobile’ events in JavaScript, but probably also how much of our CSS or JavaScript is critical. As always, it depends.
This content originally appeared on Hidde's blog and was authored by Hidde de Vries
Hidde de Vries | Sciencx (2015-04-16T00:00:00+00:00) Making our websites even more mobile friendly. Retrieved from https://www.scien.cx/2015/04/16/making-our-websites-even-more-mobile-friendly/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.