How to make your site faster
Rejected title: 'Cache me outside, how bout dat?'
For someone who’s never visited before, the homepage loads in about 1.2 seconds on a good, wired connection. Although often forgotten about, page load time is a ridiculously important metric to keep an eye on, as it directly impacts user experience, and therefore conversion.
- 53% of users leave a website that takes longer than three seconds to load.
- 74% of users will abandon a mobile site that takes longer than five seconds to load.
- A 100ms page response delay can lead to a 7% reduction in lead conversions.
- Lead conversion rates are highest when a website takes between one and two seconds to load.
- 85% of B2B buyers expect mobile-optimized content.
- A two-second delay in web page load time increase bounce rates by 103 percent
On the homepage, we display the latest activity centres to have come on board. Not only that, but we work out which ones have time slots coming up with space. This calculation involves around 12 different tables, as there are lot of things to consider. Making sure this query performs well was hard, but worth it. We can do it in about 40ms, reliably and scalably.
With this query, we then render all of the bits of the homepage. And this bit can take some time, up to around 250ms, which isn't very fun. So, we cache the html we generated with the initial query, and only regenerate the html if the results in the query change. In our case, this is done with Rails' fragment caching. We actually go a step further, and cache each of the little cards individually too, so if you bust the 'outer' cache, we'd only need to regenerate some of the cards.
ETagHTTP response header is an identifier for a specific version of a resource.
If you visit our homepage, and then come back to it 3 mins later, chances are it hasn't changed. So we send an ETag to your browser with a certain timestamp. Let's say (simplified for readability)
Monday 12th 11:00 UTC
This is the time the homepage was last updated.
We have certain conditions in which we know we need to update the homepage, like when a user logs in/out (as you need to see the new navbar).
If you make another request to the homepage, and we haven't updated since Monday 12th at 11:00, our server will just tell your browser that it's completely the same, so just use the local version. That's why if you refresh the homepage, you'll download less than a kilobyte worth of data.
We've all been there: you visit the site, and it's completely white for a while, then you see some shitty unstyled content, and then BOOM, suddenly it looks all fancy and stuff. That's because your browser is waiting to download the (probably large) main CSS file for that page, whilst you sit there looking at invisible or mostly-broken content.
At eola, we've worked out what the minimum amount of CSS is that's needed by your browser to render a mostly-nice page. We take this critical CSS, and inline it inside the html, meaning your browser doesn't need to make another request for it.
We then, via JS, programatically download the 'full' CSS, and store in your cookies that you've received it. That way we know we don't need to inline it in future requests!
Image caching and srcset
Every image you see on eola is hosted by our image CDN of choice, Cloudinary. The images are highly optimised, and the actual format you receive is secretly adjusted for your browser. For example, if you visit us on Chrome, you can download webp images, which can be compressed even further. All of these images are then set to be cached locally by your browser.
We then take advantage of the html image srcset attribute, allowing us to specify different sizes of images to load for different screen sizes. There's no point downloading a huge desktop hero image if you're looking at it on your Apple watch ¯\_(ツ)_/¯
CDN asset caching
We use Cloudflare to store cached versions of our assets on their servers, meaning more people can access them even faster from more places! We also use them to manage our DNS, as they offer a free, super-fast proxy service.
Whilst a large topic which our frontend wizard Jaime writes about on his blog, this is simply the idea of letting each visit to the site start with the basics. Simple html and css, and everything beyond that is an enhancement. Ultimately, the goal is to make the page work with as little as possible, resulting in users seeing meaningful content in the shortest possible time. We conditionally load JS based on the requirements of the specific page, sometimes the specific browser (using enhance.js) and always after the page has finished the first meaningful paint - meaning the enhancements are not render-blocking.
Font Loading with Font Face Observer and critical fonts
We use Font Face Observer for some clever font loading, avoiding Flashes Of Invisible Text (FOIT). We use system fonts, then cleverly download the eola fonts in the background, then switch out the unstyled fonts to the fancy ones. Critical fonts allow us to get closer to the final experience in less package trips and a smoother perceived performance until the complete set of font files loads
Sounds awesome, right?
That's cos it is. We've (rather unexpectedly) received first-hand feedback from some of our outlets that the difference in speed between our system and what they've been using before is 'absolutely crazy'.
If you'd like to help us advance at lightspeed, we're currently looking for more tech expertise, take a look here.
Enjoyed this? Free this weekend?
We have the best deals for adventure sports across the UK.
Check out activities
Next article: Why we are great for horse riding centres