Unlike in professional sports, website performance enhancement is not only allowed, but encouraged. Your shared server is slower than a dedicated one, so pay attention to ways to speed it up. This will help with impatient users, and will boost SEO, since search engines penalize slow sites.
Table of Contents
Test Your Site’s Performance
I use the free testing service at gtmetrix.com to scan each site I’m working on (and any specific pages I have concerns about). This shows how the site stacks up against Internet averages, and what opportunities exist for improvement.
Because it’s on an inexpensive shared server, your site won’t be among the fastest on the Web. There’s nothing you can do to get it into the top 10 percent. But you can probably get it above average, and this test will let you see where a little work will pay off.
Use the Correct Size for Images
Unless your site is about photography, there’s probably no need to store full-size camera images, which are typically in excess of 3000 pixels in each dimension. In fact, WordPress automatically scales these to a more reasonable size when you upload them (currently 2560 pixels maximum), so you might as well save space on your web server and use a scaled down image to start with.
Note: if you do have a photography site and need full-size images, there are plugins for that.
Aside from storage space, there are performance considerations. If a website visitor has to receive a 4MB image file so that they can see the picture on your page, that’ll slow things down. If they really need to see it full size, fine, but if it’s displayed small, you might as well use a smaller file to speed things along.
If you use WordPress and the block editor, a lot of this is handled for you automatically. When you upload an image, WordPress automatically generates a set of scaled-down versions, in case you want to display them small. And the “image block” of the block editor takes things one step farther. Rather than making you choose one image size to include in your page, it does a special thing so when someone views the page, their browser receives a list of all the available sizes and it automatically requests the one that’s best for their situation, based on their screen resolution and whether they’ve zoomed in or out.
If you use the Classic editor, however, the web browser will only receive information about one image – the size you choose while editing. In that case, think about what’s the maximum size someone’s likely to zoom this image, and select that size – then maybe scale it down a little for the benefit of people with smaller screens.
This is one reason I prefer the Block editor.
Refer to Image Size for more information about image sizes and their relationship to performance. For your Mooberry book grids, the image displayed in the grid is selected based on the image you selected as the cover on the book page. Mooberry is smart enough to choose the scaled image nearest in size to what it needs for the grid, without going under. That’s pretty efficient already, but you can improve it further by arranging that the exact image size Mooberry wants for the grid is automatically available.
Wait to do this until you settle on a size for your book grid images. At that point, visit the dashboard screen Settings > Media, where you can set the sizes of the scaled images that WordPress creates from all your graphics. Under Image Settings, set the Medium size height to the same number as the default cover height of your Mooberry grids. This gives Mooberry a perfect picture to select for the grid.
Changing this setting will control what happens with future images. However, it will not affect the scaled images for pictures you added to your library earlier. To do that, install and activate the plugin Perfect Images. Among other useful functions, this plugin has an option to recreate all scaled images to the new sizes you specified.
Note: the “thumbnail” image size might be closer to what you want for your grids, but Mooberry never uses thumbnails. This is because by default, thumbnails are cropped to a square, so you can’t assume it shows the whole cover. My setup tool changes this stupid setting so your thumbnails are not cropped, but Mooberry doesn’t know that.
Optimize Images
The previous section was about avoiding unnecessary scaling down of images to reduce the sizes of the image files sent to the browser. Various plugins are available to reduce the file sizes of images without reducing their dimensions. This is done by encoding the information in a different way to make the file smaller. It’s like the difference between saying “white pixel, white pixel, white pixel…” 87 times, versus saying “87 white pixels”.
There’s a reasonably good chance your hosting provider makes a plugin available to do this. It helps them too, by making their shared servers stretch farther. For instance, if your site is hosted on SiteGround, they include the Siteground Optimizer plugin which compresses images, among other functions.
If the hosting provider doesn’t supply something along these lines, I recommend the evocatively named Smush – Lazy Load Images, Optimize & Compress Images, by WPMU DEV. Smush also includes a function to process all the images you uploaded before it was installed.
The use of the right-size image, combined with optimization/compression, is a one-two punch that makes that aspect of your site as efficient as it can be.
I recommend Smush because it’s free, easy to use and does a decent job. Some other plugins (and the paid version of Smush) generate even smaller files, and give you more control over the process (for instance, offering the option to use “lossy” compression). Unless your site is graphics-intensive or you are technically inclined, these may not be worth the trouble.
Encourage Browser Caching
You can make your website tell the web browser, “This image you just requested? It won’t change anytime soon, so save it and don’t ask me for it again for a couple of months.” This makes the page load faster the next time the same person visits it, and if the same image is used elsewhere on the site, the improvement applies to those other pages.
The gtmetrix performance test will tell you whether you need to enable browser caching. These days, many hosting providers automatically install caching plugins in WordPress sites, so it might be already happening, or you might just have to turn this feature on.
If you don’t already have a caching plugin, I recommend the plugin Browser Caching with .htaccess by Tobias Merz. Because this makes changes to the security-sensitive “.htaccess” file, you may have to temporarily disable any security plugins before you can activate the plugin. (If your site is hosted on SiteGround, they include the Siteground Optimizer plugin, which does the same thing.)
If you do change images or other things, and need your browser to request a fresh copy, reload the page using the F5 function key (or the circle-arrow “reload” button in your browser). This tells the browser to discard the stored images and fetch fresh copies. Just reentering the URL in the address bar does not do this. In some cases you may have to use Ctrl+F5 (on Windows) or CMD+R (on Mac) to do a really thorough refresh.
Lazy Load
WordPress includes a feature that speeds up your web pages by checking what part of the screen is visible on the browser, and only fetching images visible in that part of the page. When you scroll the page, the images in the newly visible part of the page are loaded. This is turned on by default.
Because this is a recently added feature of the base WordPress software, some plugins duplicate this functionality. The built-in function is fine, however. In the rare case that it causes problems, you can disable it for the whole site, at the cost of slowing down page “load times”.
Let the Server Cache Pages
WordPress pages are generated on the fly. This lets you vary your content dynamically, but also is slower than sending a page of “static” HTML that doesn’t have to be calculated every time. Page cache creates a super-fast HTML file out of each of your pages and stores it on your server. When someone requests the same page, the server sends that pre-calculated file.
But we need our dynamically generated pages to show visitors the latest info, so these caching plugins also include logic to notice when you’re changing something on your site – writing a new blog post, for instance – and discard their saved file so the next requester gets a fresh copy. (There will also be a function in the dashboard or toolbar to dump the cache, in case the logic makes a mistake.)
Many hosting providers do page caching by default. On SiteGround, the Siteground Optimizer plugin does this for you.
If your hosting provider doesn’t cache automatically, install and activate the plugin WP Super Cache by Automattic.
This still might not be enough to make everything work properly. If your site displays randomly changing information—a quote of the day, for instance – caching may make it fail to randomly change often enough. So, it’s still possible that caching software will break something on your site. If so, you’ll have to decide whether whatever it breaks is more important to you than the speed boost from caching.
Use a Content Delivery Network
A “content delivery network” or CDN speeds up your site by making copies of images, scripts, and other files referenced by your web pages. The CDN service’s servers are faster than yours, and they have lots of them in different locations, so they can choose one geographically closest to the requester, which makes for a faster response.
This also provides some protection against denial-of-service attacks on your website, if that’s a concern for you. Because much of the information isn’t coming from your site, your servers can handle more requests per second. CDN providers will deflect such attacks for their own sake, if nothing else.
Your hosting provider may provide a free CDN as part of your hosting service. In the case of SiteGround, this service is called CloudFlare, and you just have to go to the Site Tools and turn it on for your site.
It’s best to wait to enable the CDN until you’re done developing your site, so if you change things, you don’t have to wait for the CDN to notice the change and update its files before you can see the effects. This is always the down side of caching.
It can be a little confusing to think about the ways all these different forms of caching interact. That’s why performance tuning happens after the site design is set, so you don’t need to deal with this complexity. However, updating caches for regular activities such as writing new blog posts and adding new images is handled automatically even when you cache to the max.
Deactivate Unused Plugins
It can be hard to know whether a plugin is still in use because you installed it last year and you don’t necessarily remember why. It’s risky to just deactivate them and see what happens, because the effect might not be immediately obvious. But in cases where you can be certain, you’ll speed up your site a bit by turning them off. The Regenerate Thumbnails plugin, for instance, doesn’t do anything useful unless you deliberately ask it to do its thing. Activate it when you need it, use it, then deactivate.
For other plugins that aren’t so obvious, it makes sense to make notes about why you included it, so if the reason become obsolete, you’ll know.
Turning off things you aren’t using also decreases your security exposure. Hackers can’t exploit something that just sits there not doing anything.