Seated comfortably in the age of digital consumption, there’s no argument: We like digital products to be fast. Evermore so, there’s a growing concern for how our web applications perform under the microscope. A timely announcement from Google this month highlights those concerns for website owners, and if you’re failing to meet the necessary requirements for delivering your site within a suitable response time you can expect to see that information indicated in Google search results.
We recently took on a (sizeable) WordPress site suffering from some clear performance impacts; using performance-measuring tools such as GTMetrix and Lighthouse/PageInsights, page load was being recorded as anything between 5 and 11 seconds – a huge usability obstacle for site visitors and garish red flag regarding SEO.
Here are three steps we took to reduce that time to 0.8 seconds.
EWWW Image Optimizer Cloud
You may think that image optimisation is something you’d only need to consider if your website displays a large number of images. For example, a site or application in the vein of Pinterest or Flickr, or at a less enterprise-scale a site that displays multiple images in a gallery. However, the benefits of image optimisation are such that they can noticeably improve the speed of your website even if images are simply a part of your broader site content.
There are a number of image optimisation solutions available, but the service we have found the most impressive (optimisation/features/pricing) has been EWWW Image Optimizer Cloud. It’s features include ‘lazy loading’ images (images that only load when scrolled into view) and depending on the level of account you decide is right for you, EWWW integrates seamlessly with ExactDN – a CDN that caches and delivers your compressed images at speed.
When handling the files that determine the layout and appearance of your website, it’s common to bundle these up into a ball and send them out with your page as global CSS and JS. These global files are then sent with every page request, regardless of whether the page needs the kitchen sink.
At a foundational level, we wanted to divide styling and functionality limited to specific areas and bundle those as separate assets. The assets required to display a dashboard, for instance, are not needed unless you’re a logged-in user – so bundling those particular assets and sending them according to where they are needed reduced file size bloat and the strain on ‘render-blocking’ static asset load time.
For medium-to-large sites, a solid caching solution will alleviate much of the work your server has to do when processing page requests. Instead of fetching pages from the depths of your database and processing the output, it stores a pre-baked version in an easy to reach location, ready for the next request.
Having previously used another WordPress plugin to handle caching site content, we switched to WP Rocket to measure the difference. It showed a huge improvement to page load time. It’s simple to install and configure, and comes with options for minifying and further condensing page markup and clearing out unnecessary database bloat. In our case, the server response time moved from 2.7 seconds to 0.8 seconds – an invaluable saving that moved the performance needle to well within the expected overall page load.
Performance is a broad subject and, especially for those with limited technical knowledge, can feel like a big problem to tackle. Perhaps you have an existing project and aren’t sure how to integrate the necessary changes, or perhaps you’re in the planning stages of a project and want to make sure you’ve got the right bases covered. Either way, (whether using WordPress or not) these steps might give you an idea of what to plan for.