1. Identify pages with excessive RTRs.
Minimizing RTRs begins with awareness. Many pages will have more than 100 RTRs per page when really you should strive for less than 50. Often, developers or professionals of SEO who look at all of the requests on a page will find that some of the items requested are missing (404) and no one noticed. Even though they are missing, it still takes time for the browser to request and come back empty-handed, so these pages should be removed or fixed immediately.
You should also fix assets that have moved and return a 301 or 302 response. These responses mean the browser had to go to 1 place, then follow another set of instructions to go to another place to get the asset, but each new location takes more time. It’s like going to a grocery store, only to be told that they don’t carry what you need, but you can get it from another store down the road. Even worse, if there is a chain of redirects, it’s like going to the second grocery store to discover that they also stopped carrying the item, and now you must try a third.
2. Combine files where possible.
3. Optimize the order of rendering.
After you eliminate and consolidate to decrease the total number of RTRs, the next thing you can do is adjust the order in which things are requested to make it faster. The same way there are steps that must be completed in a recipe before other steps can begin, there is a certain order that a mobile browser will follow that must be adhered to when building a page. Following the grocery example, if your recipe calls for something to marinate for 2 days, it is important to get the items needed for the marinade first, so that it can begin while you are acquiring the rest of the ingredients, rather than after.
Translating this analogy to the web world, the marinade is like a render blocker, because nothing else can happen in the cooking process until it is done. You can only prepare for the next steps in the cooking process by getting the ingredients while things marinate. This is like critical-path rendering, in which you prioritize the critical items, like the head tag, the page content, and the basic layout of the page first, and delay the items that are less critical, especially if they will delay the loading of more critical items. This can drastically improve the loading experience for users, and give them confidence that the rest of the page will load quickly. It also gives them assets to begin evaluating while the loading process happens.
4. Create a page load strategy.
The best tool to use to find opportunities for lazy-loading images is Google PageSpeed Insights. You can also use Google’s Lazy-load image tag, but so far, this will only be respected in mobile and desktop Chrome browsers (though this could expand in the future). With either method, you should use the URL Inspection Tool in Google Search Console to verify that the items that are lazy-loaded are visible in the tool’s page rendering and in the rendered HTML.
5. Compress everything that you can.
After you minimize and prioritize the RTR for each page template, you should compress what you can. Compression helps increase page speed by saving bandwidth. Gzip is one way to compress files, and it can be set up on most servers, but other options are available. You can also run most code through a minification process, which reduces the size of the final transfer file. However, it is difficult to compress images through these methods. You can use the Performance Review page on WebPageTest.org to find the Full Optimization Checklist, which shows all of the assets on the page, whether they are gzipped, and their level of compression.
Instead of gzipping and minimizing your images, it is important that the designer hands them off to the developer in the most compressed format possible. Essentially, they need to make the end file size as small as possible without compromising the appearance of the image. Photos should generally be saved as JPG files and icons and illustrations should be saved as GIF files. To make large images look great on full-screen computers, without bogging down tiny mobile screens, consider using the responsive images protocol, or using an image server like the one from Fastly to dynamically send a pre-scaled version of the image to smaller screens.
6. Cache the right pages at the right time.
The next step is to help browsers and bots identify what can be reused, and what needs to be fetched anew every time. Most elements on a site—especially a site that doesn’t change more than once a week or share real-time information like news, weather, or sports scores can cache most of the elements on their pages for up to a year. Caching means that when users visit a page, the browsers will look locally in their memory to see if they already have a file that is needed to build a page. This saves on the round trip requests and improves load time. Search engine bots always view a page as if they have never seen it before, so they don’t use active caching, but they can perceive when caching is going on, and may use it to estimate the load time for a page.
The important thing to understand about caching is that it is based on file names and their location on the server. So if you use 1 file on many pages, like a logo, always reference it with the same file name and URL, even if it exists multiple places on your server. This can be used to your advantage because it means you simply need to update the file name of an item and its reference in the HTML to get a new version of the item cached. So for instance, if you make a tweak to your logo, simply changing the file name from ‘logo’ to ‘logov2’, it will cause the new version to be cached and the old version to be forgotten. In this way, when you allow something to cache for a year, you are not saying that you won’t change the item for the year, but that if you do, you will reference the updated or new item with a new file name.
Cache settings can be a bit complicated, so the best thing to do is to think of them like food that can expire. Some food expires more quickly than others, so you need to let the browser know which stuff gets old and needs to be thrown out quickly, and which can sit on the shelf for a while safely, without replacement. You can use a tool like WebPageTest.org to help you understand where the opportunities are. The important thing to understand here is that there is no expiration set, nor any maximum age for the item to exist in the cache. Therefore, the browser will just assume that it needs to be fetched freshly each time—browser caching cannot happen unless these details are specified.
Since cache settings tell a browser when an item is too old to be used, it is sometimes referenced as a “caching lifetime” or a “freshness lifetime.” If something is beyond its freshness or caching lifetime, the round trip to the server must be completed to get a fresh version. If items are listed as “expired” it means they are beyond their freshness lifetime, and in both the grocery and browser analogies must be replaced the next time they are needed.
In the same way that it is not useful to have shelves full of expired groceries, it is not useful to have a cache full of expired web content. Conversely, it is also inefficient to throw away groceries (files) that are still perfectly usable. When you are assigning caching lifetimes to your files, it is useful to think about this, and also consider the consequences of being generous with caching lifetime. If you make a minor change on your logo, it will not be the end of the world if the old logo is still shown, so you can keep that caching lifetime long, especially if you plan on being diligent with updating the file names when you make changes. With different file names, there is no concern that you will show the old logo.
7. Build Accelerated Mobile Pages (AMPs).
All of this is can seem complicated and that’s why Google created a simpler solution for page speed optimization. Accelerated Mobile Pages, or AMP, is a subset of HTML that follows much more stringent guidelines about what can be included. The goal is to get most pages to a 1-second load time on mobile, which it generally does. AMP allows Google to take control of most of the hard stuff by caching and configuring the loading process and most of the elements described above so that it is as optimized as possible.
In some cases, businesses create new AMP pages and link to them from existing pages on the site from the head tag. This tells Google to serve the AMP page when the person requesting the page is on a mobile device or a slow connection. In other cases, you can replace their existing pages (or their existing mobile pages, if they have separate sites) with AMP pages. This is called “Canonical AMP,” or “AMP canonical.” Google prefers this method, because AMP pages are exceedingly easy for Google to crawl, render, index, and rank. Businesses may not prefer it though, because the limitations and requirements of AMP can make pages a bit stark. AMP can also complicate or limit some of the tracking and testing that you can do on desktop pages, so this is another reason that some people avoid it.
Mobile browsers work differently than desktop browsers. They also have slower processors and less reliable connections. These factors make it important to review the load time for your site's pages from a worst-case mobile perspective to understand where there are real opportunities for improvement.