The first iteration of this website was slow—dog slow. Using tools such as Google Pagespeed Insights or GTMetrix, the time for an entire page to load was typically in the 7- to 12-second range. Unacceptable! Using the same tools today, our pages load somewhere in the range of 1.5 to 4 seconds, depending on the page in question. Much better!
When you use a performance tool, typically you get a long list of things you could fix or address to improve your site’s performance. These lists, with each priority itemized, are helpful, but not all the fixes presented are as significant as the tools suggest. You can make herculean efforts without seeing a meaningful difference in your site’s performance. The lists look like this:
For Co-Op Gaming Dot Info, I went through one-by-one and attempted to address each issue. In the earliest stages of optimizing the site, nothing seemed to have a sizable impact.
For example, on GTMetrix, the highest priority changes had to do with page caching, minifying HTML/CSS/JS, and using something called “gzip compression.” I completed these changes, but they shaved just a second or two.
On Google Pagespeed Insights, we were told to use next-gen images. For a while we served webp images on the site. There were a lot of technical issues, and webp images broke the rendering on certain browsers. It’s a nice suggestion, but due to its technical complexity, it’s not something I imagine most mom-and-pop websites can implement. There’s another side effect—serving webp images prevents users from saving your images. That may not sound like a big deal, but it fundamentally changes one of the most basic ways that users can interact with your site.
After a lot of testing and optimizing, we got our page load speeds down to an acceptable level. Here are the changes that made the largest impact on Co-Op Gaming Dot Info:
Drastically Reducing Image Sizes Using Shortpixel’s Image Optimization Plugin.
In the beginning, we used a more popular image optimization service: Smush. Smush is a great piece of software, but its optimizer barely reduced the sizes of our biggest, gnarliest images. Shortpixel’s software, by contrast, whipped our images into shape, causing them to weigh in at 100 to 200 KB. You can also use something like https://imagecompressor.com/ if you’d prefer not to use a plugin to “bulk” optimize your images, but then you must process and compress images before uploading them to WordPress.
Overall, this change reduced some of our network payloads from 5 to 7 MB down to 1 to 3 MB. Reducing the total amount of data required for your website to render will lead to the largest performance boost. Sounds like a no-brainer, but we don’t always use our brains for everything.
Implementing Caching and GZip Compression with WP Fastest Cache
We tested a number of WordPress browser-caching solutions, but often they caused pages to render differently or introduced unpredictable behaviors to the website. I wish I had kept closer track of what went wrong with the 4 or 5 plugins I tested. Because I didn’t, all I can do is make the recommendation for the plugin that worked best in the end.
Here are the WP fastest cache configuration settings we use:
Also note that implementing browser caching will probably not directly improve your page load times in testing tools. But for users, page loads will be a little snappier.
It’s difficult to quantify what sort of direct impact this had on website because many things changed at once. From an end-user’s point of view, the website loads more quickly and cleanly than it did in the past, not because pages built in Elementor are inherently speedier, but because implementing Elementor on the website meant we cut down on our use of bloated plugins. (A big SEO boost came from this, too.)
Serving dynamic content can be hairy with WordPress. Archive pages need to be edited in PHP files, and it’s hard to make them look neat and tidy. WordPress gives you some wonderful functions to render dynamic lists of posts, but unless you’re working with a totally custom solution, these can be difficult to fit into the context of your pages. Moreover, you often want your posts to look a certain way, to have more features, or for different post types to have different layouts.
Unless you buy a new theme, it’s difficult to control these things. It’s tempting to find dirty workarounds or use bloated plugins to handle small features. For example, we were using a plugin called The Grid to dynamically generate lists of posts. The plugin had massive overhead, far in excess of what is justifiable to get pretty lists of posts. And it was almost impossible to control the content and make it look like we wanted. Another example: We were using custom page layouts, built in a page builder. Search engines had a hard time reading and indexing these pages, and their maintenance required massive administrative costs in terms of upkeep and even creating new content.
Elementor solved both problems. Using the theme builder, you can create layouts for elements of your website and control where those layouts are used. Then, with the layouts set, you can use WordPress’s basic functionality to create new content. It’s ultra powerful and super efficient—and Elementor-based Theme Builder layouts load a lot more quickly than layouts built in other page builders (subjective, I know). What’s more, Elementor post widgets are rendered super quickly compared to similar dynamic post lists generated by other plugins.
Then, implementing custom post types with Pods, we were able to specifically control the layouts for different post types. We were even able to add custom fields to posts. This is useful for displaying metadata related to content and for allowing content-creators to add data where an otherwise more complex system may be required.
The ways Elementor optimized our site is probably worth another post on its own!
Serving Images on CDN Using Shortpixel Again
Using Shortpixel and another plugin, Autoptimize, you can upload your images and use them on WordPress in the usual way. Then, seamlessly, your images are loaded from a CDN rather than your own server.
Bringing Adsense Ads Under Control
As a small-time content website, we’re using Adsense. Google strongly pushes you to use “Auto ads,” which essentially allows Google to place ads on your website wherever their computers deem best. I admit I’m tempted to let Google run wild with ads, but they often place 7 to 8 ads at once in highly prominent places. Many of the ads even broke our layouts. Worst of all, many ads use GIFs and other high-fidelity assets. These can double or triple your page load times, even if your site is optimized.
What worked best for Co-Op Gaming Dot Info was to disable auto ads, except for some specific instances (mobile sticky ads, for one, seem unobtrusive), and to limit Google ads only to blocks that we defined ourselves. Perhaps this cuts into the already paltry ad revenue we do generate, but it was the only way that we could serve ads without taking heavy performance and UX hits.
When it comes to optimizing this site’s performance, we really have tried everything under the sun. We’ve discarded many optimizations, including an AMP implementation, more extensive caching, next-gen images, deferral of CSS and JS to be inline, and more. We’ve gotten to a point where our site performance is decent.
Ultimately, web performance isn’t that tricky: If you keep the website simple, and deliver only a reasonable network payload whenever someone accesses a page, you’re already most of the way there. Working with WordPress, it’s easy to use plugins to add layers of complexity to the site, in a way that is not always easy to see or comprehend. Keep in mind that as you add more features, content, and integrations, your website will continually slow down. It’s wonderful to add a Twitter feed to a webpage, but don’t forget that your website will need to make a call to Twitter on every page load, and that Twitter may need to load images, GIFs, videos, and a whole boatload of scripts.