Many bloggers know the problem: at first, their WordPress site is fast. After a while it starts to get slow. The same happened to BeyondJava.net. Time to do something about it. I didn't want to wait until the Google rankings began to drop.
Backup your website before you start
No matter what you do, make a backup of your website before you start. Save both the files and the database. Otherwise, there's no way back if something fails.
Measuring
The first thing you should do is measuring. Open the web development tool (by hitting the F12 key) of your browser and check the network tab. How long does your page load take? How many files are loaded? If you aren't familiar with the web tools, there are many websites out there to do it for you. As to my impression, many of them are not serious, so proceed with care. Three websites that worked fine for me are GTmetrix.com, WebPagetest.org and Googles PageSpeed tools.
Before I started optimizing BeyondJava.net, page loads took 3-5 seconds. In the EU, the page loads a lot faster than in the USA. The number of files played a crucial role: The page required 28 CSS files, give or take a few. These are Javascript files, CSS style sheets, fonts and so on. Most browser load eight files in parallel, so reducing the number of files makes a big difference. Now BeyondJava requires 15-18 files (depending on which article you read). Page load time went down to 1.5 to 2.5 seconds, sometimes 3 seconds in the USA.
Funny thing is, the Alexa toolbar raised their "average load time" to 5 second this evening. No idea where they get their information from. Chances are they are using old data (say: the average of the last 30 days). Plus, the admin area of BeyondJava.net had become extremely slow. Most likely, Alexa doesn't distinguish between the admin area and the user area, so their data are biased by me. In a couple of weeks, their "average load time" of BeyondJava.net should go down again.
Avoid redirects
One odd thing caught my eye immediately when I ran a WebPagetest.org from the USA. When you enter "www.beyondjava.net", the browser is redirected to "https://www.beyondjava.net/blog", and after that to "https://www.beyondjava.net/blog/" (note the trailing slash). As it happens, my server is on the other side of the ocean, so there was a lot of latency. The redirects add one or two seconds to the page load time. That doesn't seem to be much, but these days users are spoilt by Google, which delivers even the most complicated search results virtually in no time.
It's better to install your blog in the root folder of your domain. There's another advantage: Search engines honor blogs in the root folder. When I implemented the redirection, visitor count doubled immediately.
Clean up your .htaccess file
That's something I do not recommend.
I maintain a long list of malicious user agents and servers to the block list of my .htaccess files. Among others, I added every list of Wizcraft computer services. That's a very long list. Surely it consumes a lot of time? Mind you, the list has to be read on every file access.
When I removed the entries, BeyondJava.net was faster. Maybe 10, 20 milliseconds per file access. The disadvantage of this approach was that I gathered 60 spam comments within the first hour. The spammers slowed down after a while (sorry, guys, this is a moderated blog!), but it became obvious that the long block list is valuable indeed.
So please block spammers from your blog using the .htaccess files (and install a captcha plugin, install WordFence, install Block Bad Queries, just to name a few, and keep your list up-to-date). Apache parses the file incredibly fast. 20 milliseconds is a small price to pay.
Delete revisions
Every time you save a blog post, a new revision is stored. That's good, because you can go back in time and look what your post looked before your last edit. Over the years, that's quite a lot of revisions. Getting rid of them makes the blog faster (but only a bit). The recipe to do this is described on SolidlyStated.com:
SELECT count(*) FROM wp_posts a LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id) LEFT JOIN wp_postmeta c ON (a.ID = c.post_id) WHERE a.post_type = 'revision'; SELECT count(*) FROM wp_posts a LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id) LEFT JOIN wp_postmeta c ON (a.ID = c.post_id); -- DELETE a,b,c FROM wp_posts a LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id) LEFT JOIN wp_postmeta c ON (a.ID = c.post_id) WHERE a.post_type = 'revision';Please be careful with this statement. Do this only after backing up your database! If something gets wrong, you loose every blog post you ever wrote. To prevent this, the DELETE statement is commented. Mind you, despite all caution even my SQL statement might be wrong.
The first two SELECT statements count the total number of blog posts and the number of revisions. The difference should be the number of published posts and drafts. If so, you can uncomment and execute the DELETE statement.
Fonts
WordPress themes usually use custom fonts. For instance, Twenty Twelve uses Open Sans, which is a nice and clear font. However, when I opened the browser developer tools (the "F12 tools"), I was surprised the fonts delayed page rendering by almost a second. If you observe something like this, you can disable the custom font by deactivating it in your theme's function.php. Don't do it in the original file - it's better to create a child theme. Otherwise, you'll loose your changes with the next update of the theme.
However, after some consideration, I reactivated the fonts. Open Sans looks a lot more attractive than the standard fonts of the browser. Plus, most people should have the font already in their caches, so the extra time can be neglected.
CDNs
The trouble I had with fonts and a couple of other files were CDNs. For some reason, hosting files on a CDN slows BeyondJava.net down. That's weird - in theory, CDNs make your website faster (and I've seen WordPress installations that benefit from using a CDN, indeed). So don't use a CDN without checking. When I checked the page load times again a couple of days later, the CDN were fast again - so maybe it was just a temporary problem.
In any case, some lawyers doubt you can use a CDN legally. Does the CDN obey to your country's privacy laws? So better avoid them, even if it adds to your page load times.
Remove plugins you don't need
Every plugin adds to the load time of your blog pages. Usually, most plugins also add Javascript and CSS files, which have to be downloaded to the client computer. Deactivate plugins you don't need.
Minification
Usually, it takes more time to load several small files than to combine them and download a bigger file. BWP Minify does just that. It merges several Javascript files into a larger Javascript file, and minifies it on the way. It does the same with CSS style sheets. The plugin is a bit difficult to configure, especially if you use the Syntaxhighlighter Evolved plugin. But once I've found out how to do it right, network traffic went down significantly.
Images
Tools like GTmetrix insist you define the width and height of your images. This allows the browser to render the rest of the page before the image has been loaded. However, those tools are often mistaken: they don't evaluate CSS style sheets.
GTmetrix also analyzes your images and tries to compress them better. It's astonishing, but this seems to make a difference. In any case, the images often seem to slow down page loads: the header image of this blog takes roughly half a second.
Caching
There are a number of caching tools available for WordPress. After installing one of them, you have to check two things:
- Does the cache tool speed page loading? Some tools don't deliver the speed boost they offer. Sometimes they can't, because they would stop your plugins.
- Does your website work properly after activating the cache? For instance, Counterize doesn't work with most caches. Many people believed their cache scare people away from their site because Counterize silently ceases to work.
Counterize
Counterize is a nice visitor counter that slows your admin area down after a while. Plus, it can't be used with a caching plugin. It's better to use a Javascript-based counter. These counters work asynchronously, so they don't slow down the page much. Another benefit is they tend to count less bots. Bots usually don't bother with executing Javascript code.
You have to be very careful about privacy. Counterize does not comply with German (European?) law because it doesn't offer an option to opt-out. As far as I can see, it doesn't even evaluate the "do not track" setting. I chose Piwik because it allows me to store the data locally, so I don't have to worry what third parties do with your data. Even so, it's quite a challenge to use Piwik legally. The minimum requirement is the "privacy" page which has to offer an opt-out setting.
jQuery
Current WordPress installations load both jQuery and jQuery Migrate. Most likely you don't need jQuery Migrate. It's only there for compatibility reasons. Chances are you don't even need jQuery itself to display your blog, but it's highly discouraged to remove it. If nothing else, the admin area of WordPress relies on jQuery. Plus, many plugins need jQuery.
However, it's possible to get rid of jQuery Migrate by adding a few lines to the end of your theme's function.php of your child theme:
Read the full story at Paulund.co.uk.
SyntaxHighlighter Evolved
The syntax highlighter plugin seems to slow down rendering, too. Rendering is stopped until the
Wrapping it up
Well, that's quite a bit of work to shave off - what? Maybe one or two seconds. Page load times of BeyondJava.net dropped from 3-5 to 1.5-2.5 seconds. That's a big difference in user experience, but it's still a bit disappointing. You can do a lot better by giving up WordPress completely. One of the alternatives is