12 Steps To Decrease Your WordPress Page Load Time
Is Your WordPress Page Load Time Killing Your Blog?
Let’s face it, today’s society is all about instant gratification. We want everything yesterday. Impatiences abound in everything we do. We want websites to have a super fast page load time, fast food, fast cars, and fast women…..
Ok, maybe not that last one, but the point is true that we as a society want things as fast as possible, especially when we need it. This fact most apparent every single time you load your Internet browser.
How many of you will wait for a website that takes a full minute to load. Sure 60 seconds page load time is not that long in the grand scheme of the universe and many of us “old-timers” like myself remember waiting well more then that when the Internet was new.
Just ask anyone over the age of 40 what downloading on a modem “back in the day” was like compared to the speed at which a page loads today and watch them laugh,
As time has gone on electronics and technology have made our lives more complex and yet faster. We want instant email, high-speed downloads and website pages that load in under a second.
As a website builder, we often come across this most common of problem from a different viewpoint. We are inundated with client requests to make sure the websites are loading “as fast os possible”, or in laymen’s terms – NOW!!!!!
But the truth is that no matter how fast a computer is there will always be limitations on how fast your website can load.
So what is the average Joe going to do to decrease their WordPress page load time?
Lets take a look a moment to run into a common scenerio that happened to on customer of ours. Here are the basics of his situation:
The client had three websites all of which were on WordPress. All three sites had same general installation with the main plugin for this client being WooCommerce. The smallest of his three sites was loading much slower then the other two. This is what we discussed with him..
- He had 3 sites that are very similar
- all three sites run on the same server
- the problem site is much slower then the other two
- all three are running WordPress and WooCommerce
We next made some very basic assessments. These were:
- While it was on a shared hosting server, there was nothing affecting other sites on the server – Not like a server issue.
- Based on a GTMetrix scan (on the right) we determined that the likely issue was related to either plugins or images.
The customers first concern was whether or not he should consider getting a new web-host for this site.
I told him “Seeing as the system can handle more then 2 sites, you must take the time to investigate what the differences are for the third site. Before you simply run out an purchase an upgraded hosting account take into account some of what is actually already going on. If you don’t fix the problem now it will follow you to the new host.“
How we (and You) can get your sites’s WordPress page load time to come down.
Since all WordPress sites are running WordPress, let’s cover some of the more common issues (depending on your situation) that can adversely affect your site’s loading times:
- Plugins – one of the largest factors when it comes to WordPress lag is plugins. The more of them you have the worse things can be. A small site of 6 pages should not be slow. It could entirely be the fault of a plugin that you installed on this third site that is eating up load times. Try disabling them one by one and see if the performance goes up.
- Themes – Not all themes are created equal. If you’re not already using a default theme consider changing the theme of the slow site to a default theme like 2016 from WordPress. Many free themes are not very well optimized.
- Images – Remember that the larger the image the longer it takes to load/download to the end user. Double check to see what the files sizes of the images you have are. IF they are too large, consider using a free software tool such as Gimp to “scale” the images to a smaller size. I would recommend keeping them comparable to your standard screen sizes. Also consider lower resolutions, low quality, image compression (depending on your level of comfort using image editing software). Otherwise consider WP Smush – Image Optimization
There are many things that can affect the WordPress page load time of a site, so here are a few others:
- To many revisions – WP stores all your edits. consider Revision Control
- Cache Settings – If you have three sites all using the same caching plugin, make sure they are all using the same setup. It only takes one checkbox out of place to make a difference, I suggest taking screenshots or loading both sites in separate windows for your comparison checks. BASIC W3TC Setup Guide
- Database Issues – Database issues can affect site loads. After all WP is database driven. Consider running a DB cleaner/optimizer plugin such as Cleanup Optimizer
- GZip Compression – most hosts and even a few plugins offer some form of compression. Smush above will compress your images but what about the rest of your site? W3 Total Cache also has an option for compression. Just about all of your files can be compressed in one form or another. Enable GZIP compression plugin will also work if your not using W3TC.
Using tools like GTMetrix can give you a list of more then a dozen things that can be done to affect a website’s page loading speeds. Here are the favorite tools that we like to use:
- GTMetrix – is one of the most commonly used and free tools that analyzes your page’s speed performance using Google Page Speed and YSlow. We use it daily to get detailed reports about clients site’s performance.
- Pingdom – Similar to GTMetrix above.
- Google PageSpeed Insights – Google’s web speed analyzing tool.
- CSS Compressor – see just how small you can make your CSS files. More on CSS compressing techniques.
Many of the issues above can be fixed with correctly installed plugins (or custom coding of you feel up to it) and will greatly impact your sites page loading speed. The overall performance of your site can increase dramatically.
There will be some issues that persist and in some cases just don’t go away.
Once such issue we encountered recent was the issue of “Leveraging Browser Cache”.
In order to fix the “leveraging browser cache” type issues you would generally need to make edits to the .htaccess file of your site. While this may not be your exact issue (likely one of the issues above), you can increase your GTMetrix score additionally by making sure Browser caches are expressly set. Even W3Cache may not accurately trigger this condition as far as GTMetrix is concerned.
Browser caching for .htaccess
The code below tells browsers what to cache and how long to “remember” it. It should be added to the top of your .htaccess file.
- ## EXPIRES CACHING ##
- <IfModule mod_expires.c>
- ExpiresActive On
- ExpiresByType image/jpg “access 1 year”
- ExpiresByType image/jpeg “access 1 year”
- ExpiresByType image/gif “access 1 year”
- ExpiresByType image/png “access 1 year”
- ExpiresByType text/css “access 1 month”
- ExpiresByType text/html “access 1 month”
- ExpiresByType application/pdf “access 1 month”
- ExpiresByType application/x–shockwave–flash “access 1 month”
- ExpiresByType image/x–icon “access 1 year”
- ExpiresDefault “access 1 month”
- ## EXPIRES CACHING ##
The problem encountered was that adding this code to the sites HTaccess file did not actually cause the browser to cache the files properly. This meant we had to find alternative solutions to implementing cache on a site where this feature should have already worked.
This particular site oddly required the removal of the “IfModule” lines of the htaccess code. While it no longer looks for the module, it does work for sites on this clients hosting. We have sent in a ticket to the host to see if there is a specific issue with there Apache config. Hopefully we will hear back from them.
Bear in mind that all host services setup their servers differently and not all fixes will work for everyone. Even with the clients site properly implementing browser cache the site times cut in half.
Using cloud services to cut page load time.
In addition to using browser and site based caching features consider using a Content Delivery Network (CDN).
A content delivery network (CDN) is a system of distributed servers (network) that deliver webpages and other Web content to a user based on the geographic locations of the user, the origin of the webpage and a content delivery server. – Wikipedia
Basically your CDN would store a copy of your files and cache them for you. Site files like the WordPress core and those that do not change a lot can be served considerably faster with the help of a CDN.
There are a number of CDNs out there. The most common ones you will find are:
- CloudFlare – Has a free option to get you started with learning about how CDNS work.
- MaxCDN – Entry level runs $9 per month.
- KeyCDN – Offers traffic price per gigabyte.
Any of these can be great entries in the use of CDNs to offload much of the static file loading to their cloud system instead of your own hosted server.
Special consideration, using a CDN requires you to change the DNS settings for your domain. This means traffic goes from customer to the CDN cloud then to your website and back again. (see below)
Since there are more steps along the route there could be some outages during DNS related issues along the route. As the CDN using cloud-servers this should hopefully be at a minimum.
Largest issue affecting your WordPress page load time.
This leads us to the last and largest issue that affects site-wide performance is your web-hosting company and their hosting configurations. Hosting configurations come in several basic packages:
- Shared Hosting – most cheap basic hosting accounts and may include thousands of sites.
- WordPress Optimized Hosting – Still shared but with additional tweaks to accommodate WordPress installs.
- Virtual Private Server (VPS) – A better form of shared hosting, each server holds a specific number of virtual boxed server installations, acting as there own device, but physical machine could still have hundreds of VPS with potentially thousands of sites. So if something affects the physical machine it will affect your VPS on that machine.
- Dedicated Hosting – A single server, your to host from one site to as many as you want.
As you go from shared hosting to dedicated the price range can jump dramatically. Many sites start out on shared hosting and work their way up as traffic increases and the site grows in popularity.
If you start a site on shared hosting you will not likely be running the host resources dry anytime soon Unfortunately with shared hosting there is no way to know whether or not anyone else will kill the server load times. There are just too many factors that can affect the server performance. Its a risk you take for the cost savings.
Sure there are too many factors on shared hosting to consider but let’s look at ones you can control.
Either login to your sites control panel and check the resources that site is using or use a plugin such as WP Server Stats.
If you see that your site is using up too much of your systems resources then consider upgrading the hosting. Bear in mind that if you are already encountering a problem with the other items listed above (such as overly large images) then you may still show spikes in system resources WHILE any problem exists.
As stated above there is NO GUARANTEE that ANY problems with a slow page load time is actually a “server” specific issue.
You can also adjust the amount of memory that WordPress has access to which can help your page load time. Your Cpanel account generally shows a value that will be a cap for your hosting account’s available memory.
WordPress defines memory usage values in the WP-CONFIG.PHP File, so you will need to make edits.
Increasing memory allocated to PHP
WP_MEMORY_LIMIT option allows you to specify the maximum amount of memory that can be consumed by PHP. This setting may be necessary in the event you receive a message such as “Allowed memory size of xxxxxx bytes exhausted”.This setting increases PHP Memory only for WordPress, not other applications.
By default, WordPress will attempt to increase memory allocated to PHP to 40MB (code is at the beginning of /wp-includes/default-constants.php) for single site and 64MB for multisite, so the setting in wp-config.php should reflect something higher than 40MB or 64MB depending on your setup.WordPress will automatically check if PHP has been allocated less memory than the entered value before utilizing this function.
For example, if PHP has been allocated 64MB, there is no need to set this value to 64M as WordPress will automatically use all 64MB if need be.Please note, this setting may not work if your host does not allow for increasing the PHP memory limit–in that event, contact your host to increase the PHP memory limit. Also, note that many hosts set the PHP limit at 8MB.Increase PHP Memory to 64MBdefine( ‘WP_MEMORY_LIMIT’, ’64M’ );
Increase PHP Memory to 96MBdefine( ‘WP_MEMORY_LIMIT’, ’96M’ );
Administration tasks require much memory than usual operation. When in the administration area, the memory can be increased or decreased from the WP_MEMORY_LIMIT by defining WP_MAX_MEMORY_LIMIT.define( ‘WP_MAX_MEMORY_LIMIT’, ‘256M’ );
Please note, this has to be put before wp-settings.php inclusion.
Most of the sites I have setup in the past will run fine on shared hosting accounts and will not max out the memory usage of the server. In rare occasion a traffic spike might hurt but that is what the caching is for.
This has covered a lot of ground on speeding up your WordPress iste and bring that all important page load time down as low as “possible”. You will find that you can run a test 100 times aver and get 100 slightly different results. The best practice is to learn how to do each of the major steps effectively. Using a plugin like Smush for example can be eliminated if your not using a ton of images or are creating and optimizing them manually. However you choose to spend your efforts speeding up your site keep in mind that there are things you can’t control and that getting everything right will take time and effort.