How to write for mobile

Focus on the subject at hand and tell the story upfront. For writing to work across a range of devices and viewports, make sure to get your main points across at the start: as a rule, ideally in the first four paragraphs, in around 70 words.

Ask yourself what people want from your site. Are they trying to find something out? If people visit your site for information, make sure that all your text is oriented to helping them achieve their goal. Write in the active voice, offer actions and solutions.

80% of people preferred sentences written in clear English — and the more
complex the issue, the greater that preference (e.g., 97% preferred "among
other things" over the Latin "inter alia").

The more educated the person and the more specialist their knowledge, the
greater their preference for plain English.

In other words: use plain language, shorter words and simple sentence structures — even for a literate, technical audience. Unless there's a good reason not to, keep your tone of voice conversational. An old rule of journalism is to write as if you are speaking to an intelligent 11 year old.

The next billion users

The pared-down approach to writing is particularly important for readers on mobile devices, and is crucial when creating content for low-cost phones with small viewports that require more scrolling and may have lower quality displays and less responsive screens.

Most of the next billion users coming online will have cheap devices. They will not want to spend their data budget on navigating long-winded content, and may not be reading in their first language. Trim your text: use short sentences, minimal punctuation, paragraphs five lines or less, and single line headings. Consider responsive text (for example, using shorter headlines for smaller viewports) but beware of the downsides.

A minimalist attitude to text will also make your content easier to localize and internationalize — and make it more likely that your content gets quoted in social media.

Ask yourself: what are people are trying to achieve when they visit my site?

Does every page component help users achieve their goal?

Remove redundant page elements

HTML files constitute nearly 70k and more than nine requests for the average web page, according to HTTP Archive.

Many popular sites use several thousand HTML elements per page, and several thousand lines of code, even on mobile. Excessive HTML file size may not make pages load more slowly, but a heavy HTML payload can be a sign of content bloat: larger .html files mean more elements, more text content, or both.

Reducing HTML complexity will also reduce page weight, help enable localization and internationalization and make responsive design easier to plan and debug. For information about writing more efficient HTML, see High performance HTML.

Every step you make a user perform before they get value out of your app will cost you 20% of users

The same applies to content: help users get to what they want as quickly as possible.

Don't just hide content from mobile users. Aim for content parity, since guessing what features your mobile users won't miss is bound to fail for someone. If you have the resources, create alternative versions of the same content for different viewport sizes — even if only for high priority page elements.

Remove redundant images

Images can be beautiful, fun and informative — but they also use page real estate, add to page weight, and increase the number of file requests. Latency gets worse as connectivity gets worse, meaning that an excess of image file requests is an increasing problem as the web goes mobile.

Images constitute over 60% of page weight.

Images also consume power. After the screen, radio is the second biggest drain on your battery. More image requests, more radio usage, more flat batteries. Even just to render images takes power – and this is proportional to size and number. Check out the Stanford report Who Killed My Battery?

If you can, get rid of images!

Here are some suggestions:

Consider designs that avoid images altogether, or use images sparingly. Text-only can be beautiful! Ask yourself, "What are visitors to my site trying to achieve? Do images help that process?"

In the old days, it was commonplace to save headings and other text as graphics. That approach does not respond well to viewport size changes, and adds to page weight and latency. Using text as a graphic also means the text can't be found by search engines, and isn't accessible by screenreaders and other assistive technologies. Use "real" text where possible — Web Fonts and CSS can enable beautiful typography.

Design content to work well across different viewport sizes

Great designers don't "optimize for mobile" — they think responsively to build sites that work across a range of devices. The structure of text and other page content is critical to cross-device success.

Many of the next billion users coming online use low-cost devices with small viewports. Reading on a low resolution 3.5" or 4" screen can be hard work.

Here is a photograph of the two together:

On the larger screen, text is small but readable.

On the smaller screen the browser renders the layout correctly, but the text is unreadable, even when zoomed in. The display is blurry and has a 'color cast' — white doesn't look white — making content less legible.

Users visit your site to achieve a goal. Ask yourself what they need to achieve that goal and get rid of everything else. Get tough on visual and textual embellishments, legacy content, excessive links, and other clutter.

Be careful with social sharing icons; they can clutter layouts, and the code for them can slow down page loading.

Understand data cost

Users avoid sites or apps perceived to be slow or expensive, so it's crucial to understand the cost of loading page and app components.

Reducing page weight can also be profitable. Chris Zacharias from YouTube found that when they reduced the watch-page size from 1.2MB to 250KB:

Large numbers of people who were previously unable to use YouTube before were suddenly able to.

In other words, reducing page weight can open up whole new markets.

Calculate page weight

There are a number of tools for calculating page weight. The Chrome DevTools Network panel shows the total byte size for all resources, and can be used to ascertain weights for individual asset types. You can also check which items have been retrieved from the browser cache.

Firefox and other browsers offer similar tools.

WebPagetest provides the ability to test first and subsequent page loads. You can automate testing with scripts (for example, to log in to a site) or by using their RESTful APIs. The following example (loading developers.google.com/web) shows that caching was successful and that subsequent page loads required no additional resources.

WebPagetest also gives a size and request breakdown by MIME type.

Calculate page cost

For many users, data doesn't just cost bytes and performance — it costs money.

The site What Does My Site Cost? enables you to estimate the actual financial cost of loading your site. The histogram below shows how much it costs (using a prepaid data plan) to load amazon.com.

Bear in mind that this doesn't take into account affordability relative to income. Data from blog.jana.com shows the cost of data.

500MB data plancost (USD)

Hourly minimumwage (USD)

Hours of work to payfor 500MB data plan

India

$3.38

$0.20

17 hours

Indonesia

$2.39

$0.43

6 hours

Brazil

$13.77

$1.04

13 hours

Page weight isn't just a problem for emerging markets. In many countries, people use mobile plans with limited data, and will avoid your site or app if they perceive it to be heavy and expensive. Even "unlimited" cell and wifi data plans generally have a data limit beyond which they are blocked or throttled.