Why is JS slowing your mobile sites down?
- A suite of user-interface components (for example, code for widgets, carousels or drawers)
- A client-side framework or user-interface library
- Polyfills (often for modern browsers that don't need them)
- Full libraries vs only what they use (for example, Moment.js and locales vs a smaller alternative like date-fns or Luxon)
This code adds up. The more there is, the longer it will take for a page to load.
Loading a modern web page
Loading a web page is like a film strip that has three key moments:
- Is it happening? The moment you're able to deliver some content to the screen. Has the navigation started, has the server started responding?
- Is it useful? The moment when you've painted text or content that enables the user to derive value from the experience and engage with it.
- Is it usable? The moment when a user can start meaningfully interacting with the experience and have something happen.
Keep in mind that resources on the web have different costs. A 200kB script has a different set of costs to a 200kB JPG. They might take the same amount of time to download but when it comes to processing the costs aren't the same.
What is a good target for interactivity?
We on the Chrome team feel your baseline should be getting interactive in under five seconds on a slow 3G or 4G connection on a median mobile device. You might say: 'My users are all on fast networks and high-end phones!' But are they? You may be on 'fast' coffee-shop Wi-Fi but effectively only getting 2G or 3G speeds. Variability matters.
Mobile is a spectrum composed of low-end, median and high-end devices. If we're fortunate, we may have a high-end phone, but the reality is that not all users will have those devices. If your device isn't up to your storage needs, try these cloud storage options.
Some users won't be on a fast network or have the latest and greatest phone, so it's vital that we start testing on real phones and networks. Fast devices and networks can actually sometimes be slow; variability can end up reducing the speed of absolutely everything. Test on a real phone or at least with mobile emulation. Developing with a slow baseline ensures everyone – both on fast and slow setups – benefits.
Checking your analytics to understand what devices your users are accessing your site with is a useful exercise. WebPageTest has a number of Moto G4 phones preconfigured under the Mobile profiles. This is valuable in case you're unable to purchase your own set of median-class hardware for testing.
It's really important to know your audience. Not every site needs to perform well on 2G on a low-end phone. That said, aiming for a high level of performance across the entire spectrum ensures that every potential user accessing your site has a chance to load it up fast.