WordPress Performance Tips, Part 1

 In WordPress

I have been thinking a lot lately about WordPress performance, specifically with respect to page loading. A lot of users take for granted that when they visit a web site a page just loads, but in reality there is a lot that goes on behind the scenes. HTML contains more than just text and formatting instructions; it also contains references to style sheets, javascript files, images, movies, and more. All of these resources must typically be downloaded in addition to the HTML in order for your page to display properly. So what looks like a single request for a web page to the user turns out to be dozens of requests under the hood, potentially to different servers.

Not only is page speed the biggest factor in overall user experience with a site, but increasingly it is becoming important for search engine page rankings. In 2010 Google announced page speed would begin affecting search rankings. And while some studies in the recent past have indicated page speed may not actually be a major contributor to page rankings, a lot of the SEO experts I work with tell me it can be a big differentiator when all else is equal. While it may only be a small factor in the overall page ranking algorithm, it may be what sets two  web sites apart if they are competing for the same keywords.

So with that introduction out of the way I wanted to explain a little why page loading can be so bad with WordPress sites, and in the second part I’ll explain some of the techniques and plugins I use to get to improve WordPress performance.

Back In My Day

I remember my first blog in 1999: I had a .html file I would open with Notepad and just add my new entry whenever I wanted to create a new post. This was incredibly fast and efficient from a page loading perspective because everything the web server needed to display the blog was right there in a single file. All it had to do was read that file off the hard drive and send it back to your web browser without much effort. Of course it was awful for a number of reasons: manually having to “archive” older posts was painful, and sorting the posts by anything other than the order I created them was impossible.

In addition to keeping the blog organized, trying to add new pages to the site overall with consistent formatting was difficult. There was a lot of code duplication, which led to a lot of work anytime the style of the site needed to change. For awhile it was cool to use frames, but those quickly became about as popular as the plague.

As an example, at one point I added a photo album to my site. Each album was just a single HTML file with a few headers and image tags, and I started by creating the first one to look exactly like I wanted. Then every time I created a new album I would copy an existing one and just change the text and file names for the photos. This works well if you’re happy with the layout and formatting of the albums for the rest of all time, but the second you decide to change one color or font you have to touch every HTML file. Having all these static HTML files that could be returned to the user as-is without any modification made the site very fast (ignoring that it was hosted off my personal computer), but the maintenance of the site quickly became a nightmare.

The Advent of Template Systems

I remember thinking back then “Man it sure would be nice if I only had to define the raw content and have some cool piece of software that could simply combine all my raw data and format it together nicely”. Then instead of changing dozens of files for a new font or color, I would simply change the cool piece of software in one place and be done. Unfortunately, I was never motivated enough to create such a cool piece of software, but luckily lots of other people did.

With WordPress and other content management systems solve these problems by not storing HTML pages on the server. Instead, the raw content of blog posts (and really this is true for any page type in WordPress) is stored in a database and an application on the web server pieces together the pages whenever someone requests them in their browser. So when a user requests a blog or a page, what really happens is:

  • The server queries the database for matching entries (could be all of them, matching a date range or category, etc).
  • Formats all their content to look nice.
  • Combines those back into a single blob of HTML.

Keep in mind, all of this is just for the blog entries or page that was requested. It hasn’t even loaded the menu bar and other widgets of the page the user eventually sees, which typically requires more database querying. So what looks like a single blob of HTML to the user is a complex series of database queries and data manipulation.

Thus the speed of building the single HTML page that the user sees really depends on many factors:

  • The number of posts in the database that match the user’s request.

The more entries in the database there are, the more time the server spends piecing them all together into the single HTML page.

  • Speed of the server (i.e. physical hardware available).

As with most software applications, you will always be limited by available memory and CPU. Especially if your site is hosted in a shared server environment, other web site spikes may impact you.

  • Connection from the WordPress server to the database server.

If the WordPress server lives on a different machine than the database server, there will me latency when trying to query for entries to display.

  • Number of visitors at the time.

The more visitors you have at a time, the more server resources will be consumed, leading to delays in querying the database and assembling the final HTML response.

Other Sources of Slowness

In addition to actually creating the HTML, other factors may contribute to page slowness. Once the HTML with all the blog content has been assembled and sent to the user, their browser begins to render it. This requires the browser to scan the HTML content for external resources such as style sheets, javascript files, and images to name just a few. It must then make separate requests for each of these resources, and this can cause further delays for the user.

One common culprit in slowness is WordPress plugins and themes. While many of these are helpful and simplify common tasks, many times the result is more resources being loaded with the final HTML page the user gets. For example, the Google Analytics plugin is incredibly useful for understanding user acquisition and behavior on your site. However, it works by adding a small snippet of javascript to every page that gets sent to the user, which results in not only more data being downloaded from the server, but also increased execution time when the page is rendered in a browser. In practice, most plugins and themes introduce new resources that can be loaded or executed asynchronously, which means it can be done in parallel with the user loading the page so it’s not noticeable. But this isn’t always possible, and over time the accumulation of plugins and themes can bog down a WordPress site.

Also, if your site uses SSL this can cause some delays as well. There is some extra network overhead associated with establishing a secure connection and sending data between your web browser and the web server. Additionally, when SSL is used the browser is limited in what it can cache, which may result in extra calls to the remote server to load images, etc. All of this adds up and can impact page loading time for your users.

And of course there are yet more things that can cause WordPress performance issues. The user might have their browser set to not cache anything, which leaves you with no options. The underlying web server may not be setting the proper response headers to indicate resources can be cached. This is pretty rare unless you install a rogue plugin that mucks with these settings, but it can happen. And there’s probably other things I’m not thinking of that others have run into.

Summary of Common WordPress Performance Issues

WordPress performance depends on a number of different factors, some that you can control and some that you cannot. With a basic understanding of how WordPress creates web pages for users, it’s easy to see that WordPress performance can go south in many different ways. In the next post, I’ll discuss various plugins and techniques that can be used to alleviate some areas of WordPress performance problems, and use one of my client’s sites to measure just how much performance gain can be realized.

Recent Posts