Contents

  • Pages
  • Resources

Pages

Preloading a page tells the browser that the user is definitely going to visit a page and the browser should get that page ready to load immediately.

For example, an application has an intro screen to describe what the application is about. Once users accept entry into the application, the logical next page they would visit would be the home or main page. Ideally, users would want that page to load as quickly as possible. By prerendering the main page, the browser can serve it as quickly as possible.

Their is a possibility that the user will not decide to proceed to the main page, but they are only loading the main page once (in the preload) and then they decide not to load it again. However, if the user is constantly hitting the main page, they would have it prerendered and the cache would be built, making it faster. Additionally, any scripts or assets that would be prerendered should be kept to a low size so that if the user does not decide to proceed they are not being “taxed” with a high amount of data.

Resources “Resource Hinting”

A potential specification for preloading assets is out there stating that instead of prefetching the asset if you might need it, a preload will always download the asset.

Currently this specification is not supported in any browser, but that could change in the future.

Update: Resource hinting is one method to indicate that a resource can be preloaded into the cache and then applied to a page. This can be achieved by using the as property within the <link rel="preload">.

The example below shows this:

<link rel="preload" as="style" href='https://fonts.googleapis.com/css?family=Roboto:100,900|Material+Icons'>

Another example shows how to load woff2 font files:

<link rel="preload" as="font" type="font/woff2" href="https://cdn.example.com/font.woff2" crossorigin>

However, as the Aligator.io article stated, the CSS will not be applied immediately. This is due to the resource being only stored in memory and not actually being applied to the webpage. This is actually a good thing, it allows us to preload the resource, keep it from blocking the “critical path” and then apply it when we need it and it has been loaded.

Many examples show that once the onload event has been issued, the resource can then be applied via JavaScript. One possible side-effect of this is that some styles may change after the resource has been applied. This is a situation where there should be sufficient fallbacks or progressive enhancement to handle this issue.

The example below shows the resource being applied via the onload event:

<link 
  rel="preload" 
  as="style" 
  onload="this.rel = 'stylesheet'" 
  href='https://fonts.googleapis.com/css?family=Roboto:100,900|Material+Icons'>

*NOTE: This same technique of changing the rel="stylesheet" can be applied to prefetching as well.

Preloading JavaScript

Here’s a sample of preloading JavaScript and then applying it. It is a slightly different syntax as the script node actually has to be created and inserted into the DOM for it to work. The preloading is still done through the <link> element but the <script> tag needs to be there (makes sense).

<link rel="preload" href="used-later.js" as="script">
<!-- ... -->
<script>
  var usedLaterScript = document.createElement('script');
  usedLaterScript.src = 'used-later.js';
  document.body.appendChild(usedLaterScript);
</script>

Sources