This post originally appeared on the TES Engineering Blog.

This is the second in a series about improving page performance at TES. Part 1 discussed what we're measuring and how.

A video of me talking about the performance issues discussed in this post.

The problem

For the job details page, we accept banners supplied by schools which aren't compressed as well they could be.

Large images don't block the rendering of the main content, however they hog bandwidth, especially on mobile.

The banner on the test Job details page started out at 173Kb:

We flunked our Webpagetest on image compression:

The image took 2.5s to load over a cable connection:

Improvement 1: Use an image resizer service

Reference the image file via the image resizer service, replacing the direct reference to the CDN:

<img src="https://l.imgt.es/employer-assets/employers/1062258/brandimages/20160422_1033AM_desktop_1062258_header.jpg?profile=job-header-large" width="100%"/>

The banner was now 53Kb and downloaded in 0.2s over a cable connection.

It now appears much more quickly at around 2.9s:

Notice in the filmstrip how the space for the image isn't reserved until it's fully loaded. As a further improvement we could reserve the space for it. It's not as simple as giving the <img> width and height attributes in pixels, because the banner has a percentage width. And also banners can vary in height so there isn't a fixed aspect ratio. However, the individual width and height for each banner is stored in the API, we could take this and calculate the aspect ratio on a case-by-case basis, then use something like the responsive image component to hold the space open and stop the layout jumping.

Improvement 2: Use resource hints

Recalling how each file download has various stages:

The triplet of DNS lookup / initial connection / SSL negotiation is expensive, some typical totals might be ~300ms with a fast connection as above (28ms latency), or a second or more on mobile (our mobile Webpagetests run on a 'typical' 3G connection with 300ms latency).

Looking again at the last waterfall above, the browser preloader only starts making the connection to the image resizer host (https://l.imgt.es) when it comes across the <img> tag for the banner in the page.

We could start that connection to the host sooner - we know that every job details page is going to need to connect to that host, regardless of what the specific image URL is. Then when the browser comes across the specific image in the page, it can start downloading it immediately as the connection is already established.

To preconnect to the host we're using resource hints in <link> tags:

We're using a preconnect hint for Chrome and Firefox and a dns-prefetch hint for IE / Edge. Safari doesn't seem to support either.

The effect? The connection sequence detaches from the rest of the resource bar in the waterfall graph, and moves to the left (starts sooner):

The new filmstrip shows the banner starts rendering earlier, around 2.5s instead of 2.9s:

However the banner seems to take longer to fully render, even though it's downloaded fully sooner (full Webpagetest result). Several re-runs of the test confirmed this. Why? I don't know yet, more investigation required.

The next post in this series will talk about how we used the Accelerated Mobile Pages pattern to turbo-boost page speed. In the mean-time, for more details on AMP check out the project website.