People are lazier than you’d think—according to Google’s research, 53% of mobile users will leave your site if it takes over three seconds to load. You want your site to be quick to improve your conversion rate and search engine rankings.
How To Check Your Website’s Speed
Arguably the most important metric of your site’s speed is Google’s PageSpeed Insights test. Since Google is the arbitrator of how well your site performs in its rankings, you’ll want to appease them as much as possible. A good score on the PageSpeed Insights test will directly affect your SEO. Simply enter your site’s URL, and hit “Analyze” to view your results.
PageSpeed Insights gives a very thorough overview of what’s currently wrong with your site. You should work through them like a checklist until your score is much higher. Google maintains a list of in depth recommendations that you can check against.
If you want to dig into how exactly your page gets loaded by your browser, you can open up the Chrome Developer Tools (Right click > Inspect, or from the settings menu). In here are two useful tabs: Network and Performance.
The Network tab shows an easy to use timeline of requests made to your site, how big the response was, and how long it took. The Performance tab shows a much more detailed view of everything that’s going on with your website:
From here, you can diagnose nearly any issue with your site’s performance, including unoptimized JavaScript code, re-renders, and style recalculations.
Install Google’s PageSpeed Module
The PageSpeed extension for Apache and Nginx does a lot of automations for general optimization of your site, such as minifying and compressing your HTML, compressing your images, combining multiple JS and CSS files into one download, and in general just cuts down on bulk. It’s not a catch-all, but it’s an easy fix for a lot of common issues.
Reduce Your Website’s Size
Reducing the size of your website directly reduces how much time it takes to download. While desktop users might still download your site fairly quickly, people on mobile connections can find your website grinding to a halt if it isn’t optimized.
Compress and Lazy Load Images
The first way of reducing size deals with images. Images (and other media) are often a major culprit of slow sites. If you’re not checking the size of your images, there’s a chance many of them are multiple megabytes in size, which can take forever to load on slow connections.
You should check the size of your images (which you can do from the Network tab in the Chrome Dev Console) and make sure none of them break into the megabyte range. Most of the images on this site are around 100 Kb.
If you have large images, you’ll want to compress them. There are many online tools that can do this, or you can manually re-export them from Photoshop, or you can convert an entire folder from the command line with ImageMagick:
for f in *.jpg; do convert -quality 70 $f $f; done
This compresses every
.jpg file to 70% quality, which should save a lot of space while being nearly indistinguishable from higher quality settings.
Images aren’t render blocking, meaning the rest of the site will load while waiting for your images. But you don’t need to load them all at once, especially when there are more important things to be downloading before the images.
You can solve this by lazy loading your images. This technique delays loading of your images until they’re needed, and displays a placeholder instead (which prevents your content from shifting around when the real images load). These placeholders are often made to be the “dominant color” or a smaller, blurred image that’s quicker to load, minimizing the jarring effect of loading.
You can lazy load images with a WordPress plugin, with some simple JavaScript, or with a JS library.
Minify And Gzip JavaScript Files
You should try to not have a ton of JavaScript, but if you must, you should curb the size of the script files. The main method of this is minifying and compressing them.
Minifying is a technique where all the the unnecessary bulk of your code is removed and replaced with fewer characters. Whitespaces, new lines, tabs—all gone. Function and variable names are replaced with single characters. Admittedly, it looks awful:
But it reduces file size, and nobody is going to be admiring it anyway. Minifying is something you do during deployment, so don’t worry, you don’t have to work on code like this.
Gzipping is another step which involves actual text compression, which can save even more space. There is a slight CPU overhead when the browser has to decrypt the file, but the size savings justify this cost. Browsers that are compatible with compressed files will send an
Accept-Encoding: gzip header in their resource requests, which lets the server know it can serve up the compressed versions.
Both of these steps speed up the loading of your JavaScript resources. In fact, minified JavaScript actually parses and executes a bit faster, so it’s better in that regard as well.
Get Rid Of Unnecessary Bulk
The final step to improving site performance is just to remove the stuff you don’t need. If you’re loading a bunch of JavaScript libraries, consider coding a simpler solution without the need for an external resource. jQuery is an example of this; it’s great to have and makes working with JS much easier, but it’s render blocking and often clunkier than vanilla JS. If you’re going for “as fast as possible,” don’t use jQuery.
The same thing goes for WordPress plugins and widgets; if they’re not entirely necessary, they could be weighing your site down. Look to streamline your site whenever possible.
Avoid Render Blocking Resources
Certain resources on your site are render blocking which means the page will absolutely not load until those resources are downloaded. Obviously, your HTML is render blocking, but your JavaScript usually is as well. This means a user will make a request to your site, wait to download your HTML, see that they need an additional JS file, and then wait to download that file as well. This is a major issue, as it directly increases your load times.
There are a few solutions to this:
- Inline the JavaScript. Instead of linking to an external resource, paste the whole content of the JavaScript file you’re trying to load into a
<script>tag in your HTML file. This prevents any external loading in the first place, and is the easiest solution. - Defer JavaScript loading until after the page finishes parsing. For anything that doesn’t need to run right away, add the
defertag to the<script>tag to load it later. - For things that do need to run right away, but don’t really depend on anything else being loaded in a particular order, use the
asynctag, which will execute the JavaScript asynchronously from the page loading.
If you’re making heavy use of client-side JavaScript with frameworks like React and Vue, you can speed up this render blocking problem by implementing server-side rendering.
Another render blocking resource is fonts. Web fonts from sites like Google Fonts are great looking, but they slow page load, and in most cases will block text from rendering until they are downloaded. You’ll want to avoid them in most cases, but if you must include them you can load them asynchronously with the
font-display: optional directive.@font-face {
font-family: 'CustomFont';
src: url("CustomFont.woff") format('woff');
font-display: optional;
}
This is technically still render blocking, but only for a very short period of time, so desktop users will likely not see text changing fonts. If you really need speed, you can use
font-display: swap instead, which will render a fallback font and then switch to the loaded font once it’s available.Use a CDN and Cache Your Dynamic Content
A content delivery network (CDN) can speed up your site considerably. A CDN serves your site from many servers (called points-of-presence) across the globe, which dramatically reduces latency to the client. If you need to make additional requests to the server, it will be much faster with a CDN.
The type of CDN you’ll want to be using is an origin pull CDN, like CloudFlare or Fastly, which will cache your site at each point of presence, speeding up the travel time and taking some load of your web server in the process. CDNs can even resize your images at the edge, since they can detect the device very quickly and serve up smaller versions to mobile users.
You can also make use of an origin push CDN to serve static resources to more people than a traditional monolithic web server could manage. This is often used for video hosting, but can serve images and files as well.
An origin pull CDN also improves latency by reducing the trips your web server makes to your database every time dynamic content is requested. WordPress and PHP are major culprits of this; every time a post is requested, the PHP script will fetch the page content from the database. This is entirely unnecessary to do multiple times a second. Caching solves this issue by storing the “results” of a request for a minute or so, which means your database gets bugged far less often. If you don’t have a CDN, you can still implement WordPress caching with a plugin like W3 Total Cache.
Leverage Browser Caching
Browsers can cache content so that future visits will be faster. This doesn’t have an effect on the first page load, so it’s only really useful for sites that have frequently have multiple visits per user in a short amount of time (think daily news, social media, etc.). Though this also applies to common resources like your logo, which will be displayed on every page. You’ll want to cache these so that if a user clicks around on your site, it won’t have to waste time reloading stuff it already has.
This is done with the
cache-control header. You can use a CDN to get more granular control over your caching rules, but controlling it from the web server should work just as well.
In nginx, the
max-age part of the cache-control header is set with the expires directive. For example, to set all images, CSS, and JavaScript files to be cached for a year, you could use:location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
}
The problem with caching this way is that if you want to make changes to cached files, those changes won’t propagate to clients until they expire, which should ideally be a long time. The solution to this is to use versioned file names, and change versions if you need to make changes:
<link rel="stylesheet" href="styles_v1.0.css" />
Or even:
<link rel="stylesheet" href="styles.css?v1" />
Either way, you’ll have to be mindful of what you cache, and for how long. You shouldn’t really use the browser cache on things like a static homepage; if you want to cache your HTML content, you should use a full-site CDN to implement caching on the server side.
Additionally, you can set the
cache-control mode with add_header:location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
add_header Cache-Control "public";
}
“Public” enables anything to cache it, including a CDN. Do not use this for anything that requires authentication. “Private” will cache something on a users browser, but not on CDNs. “No-store” will disable caching altogether.
Comments
Post a Comment