… so much so I am going to use it as a step by step on my own sites, adding my own non-technical-bloke experience, actions etc as I go.
I don’t Know if it is an acceptable practice to copy and paste the original post by Daniel Pataki into my post, to then use it as a walk through, but if he is the kind of guy who monitors back-links, and I expect he is, he can tell me to stop. I will send him a link to my completed work- through when i’m done anyway, he might be interested.
So why is it the best – and i’ve read plenty.
First up it isn’t written in the ten things that will revolutionise your website fashion. They are ok as far as they go, but often feel more like affiliate sales tools, or carefully balanced reviews, with just enough objectivity to make the selling of their own wares acceptable.
Second he does write as a tech who understands we are not all techs. He talks about the importance of good documentation, the easy blame game (host blames theme, theme blames plug in, and so on.
There probably is a third which i cant think of right now.
So, here is his original text from the ultimate mega guide to optimising wordpress
I will apply the method of :-
indenting my own experiences etc in red
- my outstanding questions in blue (not for him to answer necessarily, though i am in a trial with wpmu, so who knows, but as my own follow on actions)
highlighting any key points i found to be very important in terms of where i’m at.
it is a huge list of tasks which will take time, and i don’t have as much time as i’d like to, so i’ll show where i’m up to, y’know, on the off chance somebody does stumble across it.
in daniel’s original article there are several useful paragraphs of pre-amble, which anybody wanting to give this a try would be best advised to read, but i’ll get straight on to the actionable points.
The Ultimate Mega Guide to Speeding Up WordPress
I promised two sides to this coin: methods for developers and methods for non-developers. Note that this doesn’t mean that all tips for non-developers are easy to set up. I will be making the distinction based on how code-oriented the method is. Basically: anything that you need to do in the code of a theme or plugin will go into the developer section, everything else goes into the general section.
By general speed increases, I am referring to all the methods, tips and tricks you can perform without touching website code (themes and plugins). You may need to editor some server files and use terminal commands, but in general these speed increases will not be made by your developer, unless you have someone in-house who also knows a thing or two about servers.
Here’s a generous helping of things to do. I tried to follow the list I laid out in the “why is a website slow?” section to make things easier on you.
99.99999999% of us won’t be able to optimize our PHP, but we can make sure it is updated. In my experience, the more expensive your host, the more rigorously they update PHP for you in a managed environment. Many lower end servers will actually update your PHP version if you ask, but won’t do it automatically.
If you take a look at some PHP benchmarks, for example, you can see why this is important.
As you can see, various updates to PHP itself can make a huge impact, especially with the upcoming PHP 7.
How to go about updating your PHP version will be different – depending on your host. If you log in to your host, search for “PHP Configuration”. You may find a select box which allows you to switch to different versions.
Currently, the latest stable release is version 5.6.9. Ideally you should be running something within 5.6, but making sure you are at least running 5.4 should be key.
Before you make the switch, there are some dangers to updating PHP. The code for your website and your files won’t unexpectedly disappear, but if you have very old code running, you may bump into unexpected issues. If you are uncertain, make sure to ask your host if you can downgrade if things go south.
i updated my php from 5.4 to 5.6 a couple of weeks ago. this was at the suggestion of my theme developer following a tough and problem strewn theme update.
i was obviously lucky. they didn’t mention any potential for problems. i did take the precaution of noting what the settings were in my old php, and checked the same boxes in the new one. again something they didn’t mention the need to do, and i know that if i hadnt added opcode back in, for example, it would have caused problems elsewhere.
the process of updating it was easy, but clearly the ramifications of it need to be understood.
This one should go without saying by now, but I still see some sites running WordPress 3.5 for instance which is now 2.5 years old. CMS updates generally don’t provide a huge speed increase from one version to the next, but they do patch security issues.
Holes in your security can lead to malicious code being injected into your site which can make things slowly grind to a halt over time.
In addition, CMS updates tend to optimize the system, allowing better code to be written for it. As a result your database will be less crowded, your queries will be faster, translating to a speed increase average over time.
Again, don’t expect a speed jump going from WordPress 4.2 to 4.3 next month. What you can expect if you are diligent in your updates is a much longer time between speed decreases due to simple database congestion for example.
i am on the latest wordpress, and have not had any problems always adopting the latest version when available (but microsoft have taught me never to do so immediately – let somebody else have the problems they have to work out and issue fixes)
This is something we’ll be revisiting in detail in the developers’ section because it is much easier to fix while writing a theme or a plugin. There are some things you can do as a user to make things better, though.
First of all, to figure out how many requests your site is making you can use a bunch of tools. You can see all requests in your browser’s developer tools, or you can use a web-based tool like Pingdom to get a nice overview.
When adding content to your site you increase requests by adding images or other media items. You basically add one request per item.
If you add galleries to your posts and the first 5 images are displayed on your archive pages as well, you could be looking at as many as 60-70 requests on a single page.
If you are a photographer, an artist or an image loving person you probably don’t want to add fewer images. In these cases decreasing your posts per page settings, or showing fewer images on your archive lists may be a good way to go.
To decrease your posts per page go to the reading settings in WordPress and lower it to 8 or 6.
i reduced my max posts per page from 10 to 6 and reset my archive page to text only. i don’t like the look of it, but this isn’t about look at the moment. my intent is to follow all the guidance, then turn back on what i want to, noting its impact on pagespeed.
Consider cutting back on plugins that affect the front-end of the website. Many plugins add their own styles and scripts, disabling them will save you 1-2 requests if the plugin is well-coded or as many as 7-8 if it was a wasteful product.
Switching themes could also save you a lot of requests, although in many cases this is not a viable option. I’ve noticed that premium themes in particular – ones that offer absolutely every feature – tend to load way too many scripts and styles unnecessarily.
Lazy loading images is a powerful tool that can make your site seem faster. In reality, you are not decreasing the requests but you are staggering out the need to load them. The idea behind lazy loading is that images that appear further down the page don’t really need to be shown until the user scrolls near them. Rae wrote a great article comparing 6 lazy load plugins, take a look there for more info.
Some plugins like MinQueue, Merge + Minify + Refresh and Dependency + Minification automate the process somewhat, but I’ve had mixed results. Give it a go, if they work you might see a significant reduction in requests made.
While I particularly hate posts that contain pagination within them, in some cases it may make sense to split a post into multiple pages. Please don’t do it to increase page views, but if you have a hyper-mega-super resource which lists your favourite 500 hotels with images, it may be a good idea to split it into sections of 25 – 50.
Plugins not only increase your requests but could cause all sorts of other issues like memory, or even security leaks. A great plugin called P3 (Plugin Performance Profiler) can help you identify the most problematic culprits.
You can also deactivate anything you rarely use. I often use tools like Thumbnail Regenerator, Theme Check, or indeed P3. While these are invaluable when in use, I need each about once a month. When not using them I disable them to make sure they have absolutely zero performance impact.
The first example deals with frustrating elements. Let’s assume you have a user menu which folds out with a cool animation when you hover over it. When a user first sees it they’ll think that it’s pretty cool. However, after the third usage they’ll become increasingly annoyed – why should they have to wait a second for the darned menu to appear?
This is usually caused by programmers and site owners not using the site in the same way as their users. I usually just visit <code>/wp-admin/</code> to log into any site. Users will most probably use the login link or form in the header. Make sure to give your users a fluid experience, not one that just looks cool but is frustrating in the long run.
The second example is all about efficiency and conversion. My favorite example here is sliders. Almost every single research article points to the same conclusion: sliders are simply horrible. No one uses them, they take up too much space, they decrease your SEO and take a huge toll on your site’s speed.
I want to stress that for a business the goal of your website is not to look pretty. Looking pretty is a tool which is used to achieve the real goal: making money. If all research points to the fact that your should burn that slider to the ground. If this increases your revenue do you really care?
In an ideal world you should look at all elements of your site and make some decisions or at least educated guesses. Read up on the topic, do your research and most of all, measure the outcome.
Also, keep in mind that in some cases total removal is fine, in other cases you’ll want to replace an element. Simply removing your slider may lead to lower conversion rates, but maybe replacing it with simple text and links would increase it way above the level of the slider’s effect.
To me, CDNs are the magic bullet of websites, they make everything a lotsimpler and faster. There are two reasons I love to use CDNs: they allow me to host images off-server and they decrease image load times.
For this article, the latter reason is what we will focus on, thought only briefly – I like hosting images off-server because it frees my content from my media. I can change my domain. I can move from host to host. my media is always in the same place. An average website’s database and theme would take up maybe 10-25 Mb. However, there may be 2Gb of images to transfer as well. If these are all hosted off-server, you only need to worry about the 25 Mb which isn’t a lot.
Back to speed! The idea behind a CDN (Content Deliver Network) is to place requested resources geographically closer to you. My personal site is hosted somewhere in the US, but I use Amazon Cloudfront as a CDN. This means that if you access my site from California you might receive images from a data center within the state.
Meanwhile, I’m here in central Europe – in Budapest – so I may receive the same image from somewhere nearby, like Berlin. This reduces transfer times, hops (the number of routers/firewalls/etc. data needs to go through) and other parameters, leading to a faster site.
If you’d like to put this into practice read our roundup on top CDN servicesto help you get started. Many – such as Amazon Cloudfront – have WordPress integration plugins, which means you can set and forget.
Caching is probably the number one method to use because it can lead to the most drastic improvements. The idea behind caching can be understood with a simple analogy. Remember when you first learned addition in school? You physically needed to count out 5+4. You used your fingers or whatever was at hand (my Mom taught me with sugar cubes) to count it out.
Nowadays I’m betting you just remember the answer and automatically know that it is 9. Your brain has essentially cached the result for you, you no longer need to count up to it.
With websites there is a plot twist – the result of the equation is not always the same! Here’s why. Imagine a website that has nothing more than your name and the current year displayed. The content of this website only changes once a year. However, each time you load the site the server calculates what the current year is.
What caching can do is essentially save an HTML copy of the website for a given time. In our example above we could set the cache to expire once a day. This means that once a day the website would load normally: it would detect a request, get the server to process the code and spit back the result as HTML. It would also save the resulting HTML in memory.
The next time someone loads the site the cache would load the HTML from memory, instead of getting the server to process it. This may not be much for an example as simple as this but for an average site, this could shave seconds off the loading time.
What I’ve just described was a full page cache, there are many other types – caching is a profession in itself. Luckily, you can get started very easily if you work within WordPress.
Tom Ewer compared the top 3 caching plugins here on our blog – give the article a read and take your pick!
There are a bazillion settings for each plugin, I recommend reading up on each setting to get the best performance.
That said, in my experience, if you use only the basic settings you will achieve at least 80% of the maximum speed gains so it’s worth getting started even if you’re a relative newbie.
Since that comparison post was published, we’ve released our own performance and optimization plugin, Hummingbird, which zips through your site finding new ways to make it load faster, from file compression and minification to browser caching
You should also be aware that better caching can be achieved on the server level. Some managed WordPress solutions offer caching on a server level which will always be faster. Many of these hosts don’t allow you to install caching plugins, simply because it would just lead to a slower site.
Over time your database will acquire some deadweight, this is pretty much unavoidable. There are two major parts to this equation: unused data and database-level overhead.
Unused data could come from a number of places. If you have some custom solutions for deleting users, perhaps the methods used don’t delete associated user metadata. This could leave hundreds of rows in the database that aren’t attached to anyone.
You could also have used a number of custom fields in the database which are no longer needed. Since these custom fields may have been added to hundreds of posts we’re talking about hundreds – if not thousands – of rows.
Cleaning this up is not hugely difficult. Jenni McKinnon wrote a great article about keeping your database squeaky clean and I talk about this at length in the “Clean Up And Migrate The Database” section of my How To Rebuild Your Website article on this blog.
For the database level overhead, you can use a tool built into MySQL which takes care of it for you automatically – this is called table optimization. It is very much like disk defragmentation for hard drives. Take a look at the “Optimize Your Tables” section of Jenni’s post to see how this is done.
We’ve already talked about using fewer images, let’s turn our attention to those you actually do have to use. Compressing images could make them smaller by 30% – 80% without any noticeable difference.
One of the best tools to use is, of course, our very own WP Smush Pro, which is used by over 200,000 WordPress installations. You can even resize images automatically.
This can be another potentially huge speed gain. Gzip compression compresses various assets before sending them to your browser for interpretation. This is something that needs to be set up on your server. Take a look at this GTmetrix article for a quick tutorial on how to make this happen.
The reason this helps so much is that CSS and HTML uses a lot of repeated content. The more patterns you have in your content the better it can be compressed. A very rudimentary example:
If you have “Daniel is Awesome” 100 times in your website’s code (and why wouldn’t you?!) you could replace that text with “12d” saving a ton of space. This is the essence of any compression and the more (and longer) patterns you have the higher compression you can achieve.
This may not speed up your website directly, but it takes a load off your server, especially if you have a popular site. Hotlinking is when an image is served on a different website from your server.
In other words, instead of saving your image and uploading it to my own server I just link to it on your server, effectively stealing your bandwidth. This is just like stealing someone else’s Wifi.
I’m not going to go into this in too much detail because this could warrant a whole slew of articles. Choosing a good host is an art and somewhat of a gamble unless you’re very well-versed in the matter.
My very short, oversimplified guide is the following: do not use shared hosting unless you absolutely have to, or you have a lot of sites you don’t really use at all. These cost around $4/month and that’s about what you get. Unreliable service prone to going down due to others overusing resources.
I also don’t recommend getting dedicated hosting. If you don’t know what you’re doing you’ll be totally lost and if you do, you don’t need me telling you what type of hosting to get. Dedicated hosting is mostly for those with a very good grasp on server technologies or for websites with extremely high usage.
If you have a website which is so popular it requires dedicated servers you should probably look into employing someone who knows all about the tech behind it.
Basically, there are two choices left. VPS is a great way to go. I think I saw one plan around $5/month, but generally this will cost around $25 – $50 a month. High-end VPS servers are also probably more capable than low-end dedicated servers, so you could strike a pretty good deal here.
VPS servers are (almost) free from the bad neighbor effect, they give you more resources and often offer additional services like backups, automatic updates and more.
Another option is managed WordPress hosting. This type of hosting offers a more WordPress-centric approach. On a VPS you could run any application you like, managed WP hosting obviously only allows WordPress.
As a result the servers are built specifically with WordPress in mind, offer server-level caching and other goodies that will make your WordPress site run like the blazes.
On the flip-side, there may be some restrictions on what you can and can not do. The host may disable some plugins and themes due to speed or security concerns. At the end of the day these all serve a good purpose, but may be off-putting to some.
If you’re looking for a good host we have a WordPress host review, take a look around and choose one you like best. I recommend talking to customer service and explaining your exact needs, they’ll help you decide what you need and you’ll also get a feel for the level of support you can expect.
I have pretty well decided to go for vpn
these are my questions as put to 2 hosts today.
I’m asking both in terms of them being the answers i need, but also to get a first idea of their customer service. I do so with some caution though. My experience with godaddy is that their sales support is superb and instant. it is only on the other side it all vanishes into thin air.
This won’t speed up your website but will alert you when something goes wrong and you’ll be able to catch a downward trend in time. Reacting to a speed issue before it gets noticeable is a great way to retain happy users!
Domain monitoring services like Pingdom and others can automatically test your site regularly and automatically.
Developers like to say that website speed declines are – more often than not – the user’s fault. There is, of course, some truth to this, but I think many developers write code, which is akin to lying by omission.
Technically the code is not faulty, it does not contain errors, it doesn’t try to actively slow down your site. However, it doesn’t do a lot to increase speed or ensure it stays speedy for a while. There is absolutely no malevolence behind this, it’s just how a lot of our code has developed.
Here are some of the things we developers can do to ensure that our products run smoothly and help keep declining performance at bay for as long as possible.
This seems like such a simple little task, yet few developers seem to really understand what it means. There’s no way you’re going to know everything about something as big as WordPress. What you can do is pick up on signs when you should do research. In other words: know your craft and learn more continuously.
Let me give you my favorite example. Have you ever had to pull a large number of meta fields for a post? Perhaps using
get_post_meta() 20 times in close proximity? You may think this is wasteful, it seems like we are making 20 database requests.
I’ve seen people use the WPDB class to directly grab all post meta and use array functions to rearrange and get the post meta they need. While I appreciate the intention behind it, it is completely misplaced.
The first time you use
get_post_meta() it actually grabs all post meta all by itself and caches the result. Any subsequent calls to the same post will use the cached data, not the database directly.
Before you make any decisions like the one above, make sure to consult the WordPress Codex and read up on relevant materials.
Another powerful tool you have at your disposal is sprites. Sprites are concatenated images. Instead of loading all your social icons separately you can combine them into a single image and use that image as the background, positioning it just right so that only the are you need is visible. Twitter uses sprites, as though many, many other large websites due to their request-friendly properties.
When I need a sprite I usually use the excellent online tool Stitches. This tool allows you to upload images and arranges them for you optimally, generating the styles you need automatically.
Concatenation and minification usually go hand-in-hand. Once you’ve made your final files it’s high-time to make them as small as possible. After all, your browser doesn’t need all your nice comments, spaces, line breaks, indentations – it is perfectly happy with a mass of unreadable code.
Unless you absolutely must use a script in the header do make sure to load it in the footer. When using the
wp_enqueue_script() function set the fifth parameter to
true to get the script to load in the footer.
This will increase the apparent speed of the website. It doesn’t decrease requests or file sizes but it does make sure essential content is loaded first. In addition, if a script gets stuck it doesn’t prevent the content from being loaded.
Other content can also be prioritized, just like placing scripts in the footer. If your sidebar contains related info and non-essential content (like it probably should) you could make sure it is loaded later than the main content.
This is not always an option of course but if you try and load important content as soon as possible you’ll end up with a site that seems faster and possibly ranks higher from an SEO point of view as well.
When outputting images in WordPress you can specify the image size to use. Most often you know how big these images will be: featured images, small post icons, avatars and so on.
add_image_size() function you can specify these images sizes. This means that whenever an image is uploaded, WordPress will actually create a copy of the uploaded image at that size.
The idea here is that if we need a 600×320 image we should grab an image of that exact size for two reasons:
- If we grab a larger image we’re wasting bandwidth and decreasing speed
- Resizing an image – whether we’re down or upsizing – takes processing power on the client size and will also decrease image quality
Database queries can lead to significant speed drops mainly due to memory usage. I’ve worked on a project where the server crashed so many times due to faulty queries that the host disabled the site temporarily.
There are two tactics to use here. Decreasing and optimizing queries. Not that as I discussed above, optimizing could actually mean increasing the number of queries to replace a particularly resource guzzling one.
First of all, avoid raw database queries in WordPress. There are legions of functions at your disposal to get everything from posts to comments, custom taxonomies and metadata.
If you do need to write a query yourself make sure to use the WPDB class, for maximum safety and efficiency. Try to avoid joining tables or other complex things, in many cases it is better to use two separate but far faster queries.
There are tons of tools to figure out if your queries are well written, and to see all queries run during a request.
You can use the Query Monitor plugin or use
define('SAVEQUERIES', true) in your config file and print all queries via
You also have the option to log slow MySQL queries. This is turned on for many hosts or you can turn it on yourself, or ask your host to do it for you. You can find more information on this topic on the MySQL website.
Many things a plugin achieves doesn’t actually need to be done on each request. Creating additional roles, regenerating rewriting rules, adding custom database tables and so on are just a couple of them.
You should wrap these in an activation function, which will only run when the plugin is activated. This cuts back on processing, thus speeding things up.
On the other hand, you should make sure to remove some of these on deactivation and remove some of your components completely using the deactivation and uninstallation hooks.
This helps the WordPress database remain pristine, delaying the time that it will slow down due to overhead. When this does inevitably happen, a simple optimization will be enough to get things back on track again.
Yes, it’s true that clients and general users make their own websites slow in many cases but this is largely a factor of better educating them. Creating end-user documentation will help the site remain speedy, increasing client satisfaction and even lowering your workload in the long run.
Focus specifically on those aspects which can cause problems such as proper plugin usage, not installing 24 analytics tools all at once, and so on.
If it is to make you money you should put everything in the service of that goal. A goal is usually achieved through the clever balancing of multiple tools, website speed is just one of those tools.
You’ll need to make the website visually appealing, you need to make it user-friendly and you need to provide the necessary information for your users. This usually means making a compromise in other areas.
You should also weigh the financial and time cost of speeding up your website. Paying someone $2,000 or spending a month lowering your average load time from 3.4 seconds to 1.8 seconds may be well worth it, but the lower you go the harder it gets.
Spending another $2,000 or a month to get it from 1.8 to 1.2 may not be a good choice, you could spend that money or time to get additional sales leads, on marketing or just taking your team on a holiday.
I hope that this guide will help you to make your site a little bit faster – if you only do one or two things listed that’s already awesome. Every little bit counts.