Mobile web performance checklist

Many web designers and web developers are not paying enough attention to their mobile websites’ performance. And we as users are paying for that.

It’s important for mobile website creators to understand what harms performance and what might increase performance. Better performance leads to an increase in conversions, and—in the end—that means more money for you.

Here is a checklist of techniques to optimize performance for every mobile web project you are working on.

Basic data

Gathering metrics from different sources will help you see later if you’ve improved performance. Chapters three and four of High Performance Mobile Web provide details on how to get these metrics.

For a desktop viewport (>900 px):

• Time to first byte (ms)
• Start render (ms)
• Speed Index on initial view
• Speed Index on repeat view
• Page load time on initial view
• Page load time on repeat view
• Page speed insights score

For a tablet viewport (600–800 px):

• Time to first byte (ms)
• Start render (ms)
• Speed Index on initial view
• Speed Index on repeat view
• Page load time on initial view
• Page load time on repeat view

For a mobile viewport (320–400 px):

• Time to first byte (ms)
• Start render (ms)
• Speed Index on initial view
• Speed Index on repeat view
• Page load time on initial view
• Page load time on repeat view
• Page speed insights score

Also, it’s important to see if you can create your own custom metric to get a “Time to First Meaningful Interaction” based on what that means for your content. In this case, you will define how to calculate that metric using the APIs covered in chapter five.

For custom metrics, you will need the following:

• Name
• Description of the meaningful interaction
• Formula to measure

Network checklist

Here are a few things you should do on the network layer.

General technologies you should start implementing:

• TLS (HTTPS)
• HTTP/2
• Other mobile techniques rather than just responsive web design (RWD)

Features you must have:

• gzip enabled on all text files
• DNS queries kept to a minimum
• Keep-alive enabled
• No redirects

Features you should have:

• If serving on TLS, use HSTS
• Cookieless domain
• Small cookie size
• Flush HTML’s early from the server
• Static content with far-future expiration
• CDN for static content
• Domain sharding for HTTP/1.1
• If domain sharding enabled, disable it for HTTP/2 or use a multidomain certificate
• Don’t rely only on CSS media queries for RWD; use JS or server-side libraries
• Don’t set RWD as a goal for your project
• Use JavaScript measuring APIs to gather real-world data

Basic optimizations

These are optimizations that you should implement most of the time.

Tips for initial loading:

• Don’t use custom mobile app banners
• Don’t use client-side rendering for the initial view
• Announce DNS as soon as possible with
• Announce resources using Resource Hints
• Announce CSS ASAP
• Don’t use blocking JavaScript
• Minify JavaScript
• Minify CSS
• Combine essential JavaScript in one file
• Combine essential CSS in one file
• Use on-demand code when possible
• Analyze usage of or in every <script> element
• Use DOMContentLoaded instead of for initialization
• Use HTTP/2 server push when possible

Tips on images:

• Don’t use blocking images (Base64) as a general rule
• Resize images for the current device
• Apply responsive images with srcset and <picture>
• Use CSS Sprites on HTTP/1.1
• Use Base64 images in specific situations (only inside CSS or when loaded using prefetch techniques)
• Use SVG when possible
• Compress your images
• Replace animated GIFs with muted videos when possible
• Deliver hero images ASAP

Tips on web fonts:

• Use web fonts with a loader
• Use web fonts with a CDN
• Optimize web fonts, removing glyphs and unused characters

Tips for responsiveness:

• Verify that you don’t have scripts running for longer than 50 ms
• Verify that all feedback is given within 100 ms
• Use a mobile viewport or CSS to remove touch delay
• Use passive listeners, debouncing, or throttling on scroll events
• Use web workers for long tasks
• Use momentum for small scrollable areas
• Use will-change on elements that will be animated to avoid repaint
• Use CSS containment to reduce browsers’ useless recalculations
• Analyze using SSE or Web Sockets for some situations
• Use the browser’s developer tools to turn on an FPS meter and check that you are reaching your goal of 60 fps, mostly while scrolling or animating

Tips for native web solutions:

• Use WKWebView on iOS instead of UIWebView
• Use Crosswalk on Android as a web view replacement
• Use Custom Tabs on Android for in-app browsing
• Use a Safari view controller on iOS for in-app browsing

Extreme optimizations

Here are some possible extreme techniques that will lead to great performance but may require an architecture change in your implementation.

Network layer tips:

• Achieve your goal of one-second ATF page load on 3G connections
• Implement Brotli compression encoding
• Use other alternative compression methods

Architecture tips:

• For users who are offline or on a bad network, offer an alternative experience through service workers or the application cache
• Separate out ATF content
• Try to fit all the ATF content in 14 KB (after gzipping)
• Don’t use media queries for responsive web design
• Create AMP and Facebook Instant Article versions if applicable
• Use SD/HD techniques based on initial metrics
• Deliver a low-res version if the flag is on within Client Hints
• Analyze the creation of a custom cache
• Predict near-future browsing with prefetching
• Use lazy loading for components
• Use service workers as a progressive cache mechanism
• Avoid big frameworks for initial loading
• If using a client-side rendering framework, analyze creating a server-side initial rendering for it

Image tips:

• Opt in to HTTP Client Hints for server-side responsive images
• Use server-side libraries to help with HTTP Client Hints
• Use alternative image formats: WebP, JPEG-XR, JPEG-2000
• Use image preview techniques

Measuring improvement

After you apply one technique, it’s a good idea to retest the metrics you gathered in the Basic Data checklist above to see how much things have improved. You need to remember that sometimes one technique might not help in your particular case, so it’s better to isolate each technique to get a conclusion per case rather than applying several techniques in a row without measuring. Enjoy your future fast website, and remember that performance matters … a lot.