You may have heard that as of early July, Google updated its search algorithm to include the load time of mobile URLs. While we knew this was coming back in January (way to go Google for the pre-update announcement). For the performance tester, it has real implications – let’s take a look.
The stats available to the public only illuminate the fact that the mobile user experience has been suffering, that something had to be done to keep marketers in check:
- 53% of mobile users leave a page that takes >3 seconds to load
- Average load time for a website on a mobile device is 15 seconds (7 seconds faster than in 2017)
- 70% of websites take more than 5 seconds to display all visual content above the fold
- 53% of mobile URLs are larger than 2 MB
- Most mobile pages are loaded over 3G or 4G connections
As of early July, page speed (how fast the page loads on a mobile device) is now a ranking factor for mobile searches.
Google’s thinking is that it will only affect pages which deliver the slowest experience to users and, therefore, change a small percentage of queries. Regardless, they will apply the same standard to all pages, no matter the technology used to build the page.
What Does this Mean for Performance Testing?
If it wasn’t already an increasing phenomenon, this change makes it clear that performance testing will play an essential role in how an app is developed. And, if nothing else, the ranking can now serve as an additional success metric under which developers, their work can be evaluated.
While there is no tool that can indicate whether a page is affected by this new ranking factor, there are some resources that can be used to evaluate a page’s current performance.
One is a performance model called RAIL. RAIL enables designers and developers to “reliably target the work that has the highest impact on user experience,” according to Google.
As the diagram shows, there are four parts to the RAIL performance model. It is a user-centric framework aiming to help developers/designers ensure a good user experience for each of these specific actions.
Keeping the User Involved
Response measures the completion of the transition after the user input is initiated. Its goal is to complete the process within 100ms maximum. If not, the user loses the connection between their action and the app’s response.
Google found that users spend the majority of their time waiting for sites to respond to their input, not waiting for the sites to load as one might think. This shows how important a quick response is to the user experience.
If it is going to take longer than 50ms or so to perform, some amount of feedback to the user is recommended to keep them invested.
Produce a Frame in Ten Milliseconds
The key to smooth animation is to do nothing where you can, and the absolute minimum where you can’t. A frame every 10ms gives enough time for the image to be rendered (6ms), and a frame every 16ms gives the optimal rate of 60fps.
Whenever possible, it’s good practice to make use of the 100ms of response time to pre-calculate “expensive” work. That will maximize the chances of hitting the desired 60fps rate.
A steady frame rate is desirable because users will notice any changes in it that may occur.
Maximize Idle Time
The idea is to use idle time to wrap-up all deferred work from other steps. During initial page load, using this concept would have one load as little data as possible, leveraging remaining idle time to load the rest. Of course, any user input occurring while “idling” should take priority.
Deliver Content and Become Interactive in Under 5 Seconds
A 5-second target load is suggested for the initial load of midrange devices over 3G connections. For subsequent loads, 2 seconds would be more realistic.
The perception of a complete load by the user may be satisfied even if all content isn’t there. Progressive rendering as well as doing some of the work in the background can significantly improve user expectation.
While all previous concepts concentrate on the front-end of the app (e.g., what is being done on the device), Google will focus their metrics using the Chrome viewers – evaluating Chrome performance may directly help.
The Chrome Dev Tools (CDT) is the simplest way to get an in-depth analysis of what happens while the page loads or runs in Chrome. The CPU or the network can be throttled to see what effect this would have.
There are sub-tools under CDT like Lighthouse, which will simulate a mid-range device with a slow 3G connection (the kind they suggest testing with) and runs a series of audits on that page. It comes up with a report on load performance, as well as suggestions on how to improve. Checks are also provided to improve accessibility and make the page easier to maintain.
Now, it is still essential to have a responsive back end no matter how well the front end looks. All of the key areas surveyed will be impacted by bottlenecks and failure to deliver needed information to the viewing device. The front and back parts of the app have to be in harmony to have a good throughput. Although Google will probably concentrate on the front-end response for ranking, just doing optimization on that will not save a pokey app from a low rank.
In short, there are some ways that will make the front end of the mobile app respond faster so Google will rank it higher. But, if the way the app gets fed information is still subpar, not much will help.
Larry Loeb has written for many of the last century’s dominant “dead tree” computer magazines including BYTE Magazine (Consulting Editor) and the launch of WebWeek (Senior Editor). Additional works to his credit include a seven-year engagement with IBM DeveloperWorks and a book on the Secure Electronic Transaction (SET) Internet Protocol. His latest entry, “Hack Proofing XML,” takes its name based on what he felt was the commercially acceptable thing to do.
Larry’s been online since UUCP “bang” (where the world seemed to exist relative to DEC VAX) and has served as editor of the Macintosh Exchange on BIX and the VARBusiness Exchange. He lives in Lexington, Kentucky and can be found on LinkedIn here, or on Twitter at @larryloeb.