So far we have covered sending less data and over shorter distances. In this entry I will discuss the options to send files earlier in the process than might otherwise be possible.
Why Send Files Earlier?
A web browsers ability to load page quickly will be either constrained by one or more of computation capacity, network capacity and/or the speed with which it is fed the data it needs to construct the page.
If the browser is constrained by CPU cycles available to build the page then sending data earlier is probably not going to improve much. Neither is it going to help if the pipe into the browser is the bottle neck.
However, if for some reason it is the ability of the browser to fetch in a timely fashion, the data it needs to construct a page, then getting data there as (or even before) the browser needs it makes sense.
How can you get files to the browser earlier?
There are a number of techniques which have been used to push files to browsers in advance of the browser needing them which have been in use for years.
For example, image sprites (which provide for multiple images being sent to the browser as one image), are used for improving the user experience on the particular page being loaded at a point in time but have also been used to send images to the browser which the user may need for subsequent page loads. By sending them earlier as part of an image sprite, they can be stored in the users cache ready for use in subsequent pages should the browser actually reach those pages.
Predictive prefetching and pre rendering of assets in web transactions is also possible. Most browsers such as Chrome are built to support pre fetch and pre render of;
• DNS hostnames which might be used later by the browser
• Assets which can be stored in the browser cache (such as images)
• HTML for pages which the browser may visit next
Techniques involves in predictive pre fetching and pre rendering can mostly be left to the browsers to actively help with. However, the more you can do to identify assets which are available for pre fetch or pre render, the more the browser will do.
Rather than sending the whole file earlier, you can also fake it a little bit for some situations and send a part of the file earlier to let the user feel as though the page is loading quickly before adding or swapping out that file sent earlier for the real deal later. Sometimes this is referred to as streaming assets. Images are a great example where streaming can be effective. You can send down a light lower resolution image for the user to see early in the page load before swapping it out with a higher resolution image later in the page load cycle.
There is some quality technical work you can walk through to enable your tech stack to send data to the customers browser earlier (or even before they might need it). However, in doing so, there is a balance to find between sending too much data too early (which could both slow down the first page load experience and hog the users bandwidth) and not sending any at all.
One of the first places to start in deciding whether it is worth sending more data early is to understand what is limiting your browsers ability to load pages more quickly. If it is CPU or network, then it might be better to start there.