The data on web speed is staggering. Over the last few years, companies like Google have been investing millions and millions of dollars into discovering how fast the internet operates, and what they’ve found is unacceptable. Between 2010-2017, the size of web pages ballooned while the infrastructure required to load them only made incremental improvements. In 2017, Google revealed that the average load time for a web page on a mobile device was 22 seconds, while data suggested that 53% of users leave a site that doesn’t load in 3. If a site had failed to load above the fold in 10 seconds, almost no users remained. Companies—obsessed with new plugins and widgets, with animated backgrounds and excessive tracking scripts, with all those technical fireworks—were destroying their own bottom line.
That Google report shook the industry, and things have been improving. The average mobile load time in 2018 was 15 seconds, and 2019 looks to continue this trend. There’s still a long way to go, but serious efforts are being made to properly-optimize web pages. If you’re serious about staying ahead of the competition, you should’ve gotten serious about web optimization the day before yesterday.
One of the big things that has come out of the last few years is a variety of web speed diagnostic tools. Whether it’s Google’s inhouse insights and Lighthouse or third party tools like Pingdom, GTmetrix or YSlow, it a straightforward process to figure out how well your site is performing and where some issues might lie. Of particular note is the waterfall chart that you’ll see in services like GTmetrix. It will look something like this:
You can get the guide linked above if you want to go into detail, but the crux of it is that it tells you what order things load in, and how long they take to load. It’s one of the best ways to identify if a particular image, script or other element is causing you more trouble than it needs to.
The #1 cause of oversized pages and slow load times on the internet, and most people don’t even realise they’re doing it. Say you’ve got a picture of your pet rabbit that you want to put on your site. It’s 3000×2000 pixels. Under the hood, an HTML image looks like this:
<img src="fluffbunny.jpg" alt="my rabbit, Thomas" style="width: 300px; height: 200px; border: 1;" />
You determine the size it appears using HTML. However, since fluffybunny.jpg is still 3000×2000 pixels, the web page is loading a huge image and then having to resize it. That’s a lot of work for nothing: if you made fluffybunny.jpg 300×200 pixels in the first place, you’d save a huge amount of processing overhead.
Consider for a second how many images you have on your web page, and how many times this is happening every single time somebody wants to load it, and you’ll see why this is the major issue holding a lot of sites back.
GZip compression lets you compress the data before it leaves your server and have the end users’ browser extract it. It is supported by almost every modern browser. It can compress everything, including the HTML file itself. Proper implementation of this can—like all compression—shrink your file size down by orders of magnitude. This not only means the individual files take up less space, it significantly reduces the number of HTTP requests and lower the Keepalive duration.
Plugin, plug out
Plugins and widgets are 3rd-party scripts you can put into your website. You’ll see them most commonly in self-hosted CMS solutions like WordPress but there’s plugins for everything these days. If you have a window displaying your most recent tweets, a link to an eBay store or an embedded YouTube video, or a tracking script, you’re likely dealing with a plugin or widget. They’re a major source of page bloat. One site I was looking at recently had three different Youtube plugins running on its main page, which were accounting for 60% of the site’s size and were slowing it down by about 4 seconds on desktop and 12 seconds on mobile.
They can be extremely useful and I don’t recommend scrapping every single one, but it’s important to ask yourself “how much do I need this?” and weighing up whether it’s worth the increased load time.
One easy way to greatly speed up your website and reduce the load on your server is to serve cached pages where possible. There’s no need to re-run the PHP for a page that will likely serve the same output.
The way to go about this depends on the type of site you are running, and many content management systems have built in cache controls, but you may want to look for a plugin or something that lets you cache more and have finer control over it. Caching pages is essential for large amounts of traffic, as well as people revisiting a site.
You may want to take a look at the cache control HTTP header. This specifies how the browser handles caching the page, the time to live, and its maximum age before a new page must be provided.
Web fonts are fonts that are stored online, rather than on your operating system. Fonts particular to a certain OS (‘system fonts’) often have issues rendering on systems they weren’t designed for, and web fonts circumvent this by being intentionally designed to run cleanly on different OSs. This is a tricky one. We love webfonts. You’ll get a much cleaner and more accurate text render than if you run system fonts but—
They cost you resources that you might not be able to spare. Their load isn’t odious on its own, but bloat problems aren’t often caused by a single line of code: they’re caused by an overload of smaller things that each take up just a little too much room. If you’re using web fonts and you find that pretty text matters less than load time, you might want to replace them with system fonts.
AMP is an HTML/CSS/JS framework sponsored by Google. It’s designed to make the fastest-loading mobile pages possible, and can reduce your load time by up to 85%. AMP requires a skilled developer, doesn’t run on desktop, has a heavily restricted feature set and will make very stripped-down pages. Still, it allows you to get lightning-fast load times unrivalled by your competitors. If you want to get really serious about mobile optimization, this is your ticket.
301 redirects are pages that move a user from the place they are to the place you want them to be. They’re mostly commonly used when you’ve deleted a page, but people still search for it and you want to keep them on your site. Having a few 301s when needed is reasonable, but don’t chain them, and having too many overall (especially chained ones) will slow down an apache based server.
While we’re here, look out for 404s too. 404 and 414 still require an HTTP request to be sent out, but in that case it’s getting the user nothing at all. There’s two sorts of issues you see when talking about load speed: big singular issues where a plugin or image is taking up more space than it needs, or clusters of smaller issues that come together in a landslide. 404s are a pretty major part of the latter.
There are web factors that you can’t account for: somebody using municipal wifi in a small town outside Surabaya is going to have a different load time than somebody in Tokyo using the latest fibre landline. You can’t really account for these factors, but it’s good to keep them in mind—”it runs fine for me” is not a good metric for how well it’s going to load for users. A lot of testing sites like GTmetrix allow you to hit your site from a variety of different server locations, and this helps a lot in building a more complete picture.
CDNs have become incredibly advanced in the last 5-6 years, with an Amazon user able to buy an eBook in a single click and have it on their eReader in less than a second. Because a CDN houses the files elsewhere, this reduces page load times. The type of CDN you need (or even if you need it) depends on whether you just want to have things like images served by the CDN or you plan to provide large files for visitors to download.
Cloudflare really deserves its own section as far as CDNs go: it’s not just a CDN, it’s a suite of performance and security services that keep your site safe while making sure it operates at peak efficiency. Cloudflare’s Anycast system routes your request to the nearest server—they have a distributed global server network, so somebody in Manila will make requests from a server in Manila, and somebody in Manitoba will make requests from a server in Manitoba. They claim this can cut load times in half. I’ve not seen it be quite that fast, but it definitely gets results. It does all this while increasing data security, preventing DDoS attacks, and more. It’s a CDN, a host, and a security kit rolled into one. Speaking of:
Who is handling your web hosting? You could have the most well-written AMP site on the internet and still get awful load times if your host isn’t doing their job properly. There are handy tools like bitcatcha that can help you to figure out if the problem is on your end or their end. There’s not a huge amount you can do about a bad host except go to somebody else or upgrading your plan, but it’s worth knowing if that’s where your problem lies.
Some hosts are optimized for specific platforms e.g. Kinsta is built to support WordPress, or Aspiration for Magento storefronts. A lot of the time you’ll see a fit that works but doesn’t work well-even though everything seems fine, it’s secretly bloating your load times and causing other issues.
If you want more advice or support with any of these issues, don’t be afraid to get in touch with our team at CodeClouds. We’ve got over 200 web developers who are happy to help you out in making your website the best it can be. If you need to hire a web designer, PHP developer, or CRM/CMS specialist, get in touch with us today.