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.
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.