WordPress Performance Optimization: How to kick WordPress into gear

If people weren’t already talking about performance optimization, they certainly have been since Google made loading times a ranking factor for websites. But what exactly is performance? And why do WordPress websites often need some extra help from special plugins to load faster? Check out this post to get answers on these and more questions about WordPress Performance Optimization.

1. Introduction: Performance on the Web

Performance generally describes the usability of a website:

• Do the individual pages load quickly in the browser?
• Is the navigation speedy?
• Does the website generally respond quickly to inputs and clicks? Is the user experience comfortable and direct?

While we measure “hard” performance, i.e. load times, in milliseconds and can often quite easily optimize results with technical means, the “perceived” performance plays at least as much of a role in the success of a website.

Why is performance so important for a website?

The aim of virtually any publicly accessible website is to “hold” people until they have performed some specific action. For example:

• submitting an order,
• dialing a phone number,
• not dialing a phone number but filling out a contact form instead,
• clicking an advertisement.

You call the completion of such an action conversion. Once “converted”, a visitor becomes an engaged user or even a customer.

Slow-loading websites and those that don’t perform well in some other aspect are detrimental to the conversion rate. Should the anticipated result take too long after a click, then the visit will usually end after a short while, the website is judged to be unattractive and the visitor leaves – back to the search engine and the next search result.

Speaking of search engines: Google punishes long load times and rewards better performing pages with a higher ranking!

In short: Load times and perceived performance and the success of a website correlate.

Why does a website respond slowly?

There are four possible reasons for a slowly answering website.

Bandwidth

The fewer “bars” are visible on the Wi-Fi display, the slower the internet and the longer loading processes will take in the browser. In many places in Germany, 3G is still very much a reality for smartphones. Even the most slimline websites need a little more time to load on 3G.

Volume

The sum total of loaded files (HTML, stylesheets, scripts, media) will often grow to unacceptable numbers on “trendy” looking websites. With the DSL connection that is standard in Germany, everything over 2 MB can potentially be perceived as unattractively slow; slower mobile connections have even less coming through as “quick” – unless the website takes steps to counteract the perceived performance.

Requests (HTTP requests)

Creating a server connection takes time even before the browser begins downloading the actual website data. Special requests to other servers outside the website’s own domain, e.g. to Facebook or other social network and advertising networks or to Google services can significantly increase loading times, because the responses from those servers cannot be optimized.

Design error

A design error can often cause an otherwise fast loading website to load a lot slower. Two notorious examples for such anti-patterns:

• Smooth Scroll: A would be “smooth” scrolling behavior that really doesn’t feel smooth at all, but is instead annoying and unnatural, because it replaces smooth scrolling with stepped scrolling instead.
• Animated page transitions: During the changeover from one page to the next, the content of the new page is covered with a “soft” animation until everything is loaded completely behind it – only then is it curtains up! Slow connections can make this “as you can see, there is nothing to see” super annoying, because there is no way of knowing how long it will take to load all content. Users, who are denied the chance to see what they are waiting for, will usually give up and will search for what they are looking for elsewhere.

Any attractive website will only realize its full potential if it also performs well. A beautiful design, aggressive pop-over and live chat module will not contribute to the conversion of visitors if they are long gone by the time the page is loaded.

General objectives for a quick website

Once again – performance optimization has two general objectives:

• Quick loading times – as a rule of thumb, a loading time of less than a second is ideal;
• generally quick response times, i.e. no delays because of “cosmetics” or script errors.

Important: A HTML page (including those generated by WordPress) can feel responsive if it is loaded cleverly, even if the browser hasn’t actually finished the loading process yet.

In other words, you don’t necessarily have to make compromises in terms of the wealth of content to make a website faster – images, videos and other media should nevertheless be optimized and carefully thought out within the entire concept of your presentation.

2. 6 Steps for WordPress performance optimization

These steps help to optimize your WordPress performance.

Step 1: Use server-side components

A PHP version with a 7 before the full stop on your own webspace not only means that a hosting provider handles the security of his customers with care. PHP 7 also offers significant performance advantages over previous versions.

WordPress has no problems at all with PHP 7 – quite the opposite: using the most recent version is expressly recommended. Problems with plugins and themes are few and far between. Well-maintained add-ons will usually also run smoothly with PHP 7. If in doubt, just look through the FAQ section to see if the providers ask any compatibility questions regarding PHP 7.

Other keywords for server performance optimization are NGINX, Varnish and HTTP/2. The use of these components will, however, in most cases require quite a bit of know-how, which is why they are (for now) maybe not the right idea for users of shared webspaces.

Step 2: Keeping page volumes low

Other than with the complex intricacies of a server configuration, the actual WordPress installation poses less problems. You can shave off load times virtually anywhere, from the choice of theme and the plugins used to the design of the page content.

Concept “Mobile first” to optimize the performance your WordPress installation

“Mobile fist”, for example, is not just a design model and a key quality feature for themes, it can also be used as a performance-friendly approach to content design.

The concept behind the name is simple: Building the website “small to large”, i.e. creating a concept for a mobile view first, loading only the type of content that impacts the user experience (and conversion) on a smartphone and to call-up these content types from WordPress in a volume that the relevant end device can actually display. The latter is easily automated with so-called responsive images, for example, meaning that images are provided in various sizes, from which the browser can choose one that fits.

Asychronous scripting: WordPress Performance Optimization with LazyLoad

LazyLoad is the name of another important piece of technology from the performance bag of tricks:

• The URLs of images are removed on a website before the images are called up, because their size (MB) would drive up the load time.
• Initially, only those images are loaded and displayed that are in the immediately visible part of the page. As the user scrolls down, other images are loaded and displayed depending on the scroll position.

A similar procedure is also available for CSS and JavaScript files. These too, can be loaded asynchronously (async) or deferred for the actual page construction, which means that the HTML document is ready to be displayed within a few hundred milliseconds, while scripts needed for blog comments, newsletter forms or page statistics (i.e. components that don’t have to be fully accessible within the first milliseconds) are called up afterwards.

Many caching plugins and performance optimization plugins offer setting options for LazyLoad and for asynchronous scripting. For the latter in particular, web development know-how is definitely a must, as unaddressed dependencies in the source code could otherwise easily result in a break in the layout or in the failure of essential functionality features on the website.

Keep page volumes low with compressing files

Compressing static files is another way of reducing page volume. There are a number of options:

• server-side compression of static files (HTML, CSS, JavaScript) using GZIP;
• automatic removal of unnecessary spaces and carriage returns in HTML, CSS and JavaScript files (minification);
• compression of image files with tools like ImageOptim, Imagify, Optimus or similar.

Step 3: Caching

We talk about caching when a resource is stored in a cache after loading to make it available for display without further request from the original source until something changes and the request must be sent again so that the cached view reflects the changes.

Step 4: Page Caching

Anything generated once as a HTML document from the WordPress database should be available in its static HTML form directly and for as long as possible.

Usually, a WordPress page is displayed in the browser using something like the following procedure:

• Browser sends a URL as a request to the server;
• Server notifies WordPress: this URL is required;
• WordPress searches its database for matching content;
• WordPress itself, as well as all kinds of plugins and of course the theme generate a complete HTML document from the content found in the database;
• Server sends HTML document to the browser;
• Browser starts the download of all required files and initiates the page display;
• Browser completes the download, the page is ready to be displayed.

This simplified illustration of the procedure needs between 2 and 5 seconds for completion on an average WordPress website. It will need that amount of time each time a user calls up this specific URL in the browser.

This can, of course, be simplified:

• Browser sends a URL as a request to the server;
• Server finds a complete HTML document for that specific URL in the cache;
• Server sends HTML document to the browser;
• and so on.

Voilà, WordPress doesn’t have to do anything. And the page is ready for viewing in the browser in a fraction of the time.

Step 5: Browser Caching

The whole process can be accelerated even more if not just the server, but also the browser can cache files, once they are loaded. The loading time can again be reduced significantly if the browser can find some of the downloaded files in its own local cache and call them up from there. A 2-5 second database request can therefore be reduced to a few hundred milliseconds and the HTML page is ready for viewing in the browser in a flash.

The following applies to both page caching and browser caching: Storing resources is pretty easy. But how do the server and the browser know if the saved resources are still current? Perhaps some content or files have changed since the last call-up. Cache validation is an extremely complex task. WordPress offers some powerful plugins that automate the entire caching process.

Step 6: Be frugal with HTTP requests

Every image, video or Like button, every Instagram feed, slider or form – basically everything on a website that isn’t text – generates HTTP requests for files outside the HTML document. That is completely normal and absolutely ok.

HTTP requests create (exceptions prove the rule) new server connections and additional loading times for resource downloads to the browser to eventually display the website in its entirety. That too is completely normal and absolutely ok.

The problem

What is not ok and can become an issue is if an individual WordPress HTML page issues hundreds of these requests and must wait for a response and for the download of the relevant files, before it can continue loading more content. It is – unfortunately – not unusual to have over 100 requests per page these days. The number of requests on “do-it-yourself” WordPress websites without any optimization by web development experts, for example, can quickly ramp up.

• The theme loads CSS and JavaScript files.
• The slider loads CSS and JavaScript files, as well as half a dozen images (of which only the first one ever gets noticed at all).
• More images are loaded for teasers below the slider.
• The newsletter form plugin loads CSS and JavaScript files.
• The Social Sharing plugin loads CSS and JavaScript files from WordPress, as well as one or two dozen more from Facebook, Instagram, Pinterest, Google and Twitter servers (and nobody can predict beforehand how reliably these will respond at any given time).
• The Ads plugin loads scripts, CSS, images and video ads from the advertising network.
• Google Analytics loads scripts from a Google server.
• Google Maps loads additional scripts and images from the Google server.
• And so on.

When themes and plugins, whose providers don’t have performance optimization on their radar as an absolute must-have, are used for request fireworks like these, delays of several seconds can easily be the result. Visitors leave the site, the conversion rate suffers.

The solution

Performance and caching plugins can help here too, as they can automatically combine multiple JavaScript or CSS files in one larger file (concatenation), for example. That way, you can at least reduce the number of WordPress-internal HTTP requests. External requests to Google, Facebook, etc. still remain a problem even then. Because Google or Facebook etc. control the servers on which the requested files are stored. Requests like these can only be prevented from slowing down page construction wherever possible, using asynchronous loading.

3. WordPress themes: Flexibility with consequences

Thousands of WordPress themes, some of them free of charge, some available for relatively little outlay – how can users without any programming know-how make an informed decision when it comes to choosing a theme? One useful guideline might be the rough differentiation between two types of theme: multi-purpose themes and niche themes.

Niche themes deliver ready-made designs for specific use cases, e.g. a restaurant website or a travel blog. They are generally very easy to personalize and offer a functional and design scope that matches their specific purpose. Well-made niche themes often conform to the 4S standard: slimline, simple, secure and speedy – one quality feature that multi-purpose themes almost never have to offer, because they simply are not made for a specific, clearly defined purpose, but serve an application range that is kept as broad as possible to cover virtually any topic.

Multi-purpose themes are created and marketed with one single promise. They enable people to build a website with no prior knowledge of how to do so. From a performance point of view, the emphasis on flexibility can easily create conflict. Where flexibility in terms of usability for the providers and users of multi-purpose themes has top priority, the accessibility and performance of the resulting websites will take second and third place respectively.

Thinking about these issues may be very helpful in validating one’s own expectations for the performance of a theme.

4. WordPress plugins: It’s all about quality, not quantity

In light of the tens of thousands of WordPress plugins available it would to some degree be foolhardy to want to give specific recommendations for or against individual plugins on the topic of performance. We would like to clear up some of the rampant misconceptions about plugins instead:

Implementing a large number of plugins will not necessarily make a WordPress website slower.
Theoretically, the number of plugins used has no effect on the performance of a WordPress website, as long as each plugin functions correctly. There are no increases in load times just because of the number of plugins you use. Statistically, however, this preconception is not completely unfounded: For users without coding competence, the potential risk of introducing a bad egg into the setup increases with the number of plugins used. In other words: Performance separates the wheat from the chaff.

The problem with “do-it-yourself” Websites

Of course you can “do it yourself” when it comes to making a WordPress website. The WordPress market is in many ways similar to a food discounter. You will find virtually anything you might need for the kitchen and for the fridge. All you have to do is load up your shopping cart.

Basing your diet solely on machine-processed, ready-made meals, however, will soon take its toll. If you eat junk food long enough, you will at some point feel the consequences in your own physical performance. Your weight will gain, lethargy, susceptibility to physical and psychological complaints and a heightened risk of disease. You will only regain your original level of fitness, once you start eating properly again, get the exercise you need and. And last but not least: change your shopping behavior.

The same applies to a WordPress installation if it is filled to the brim with plugins without any thought about quality or performance. And anyone thinking they can achieve performance optimization by simply installing a caching plugin will be pretty disappointed. Caching plugins can do a lot, but they aren’t a magic wand. 200% faster loading times may be 200% faster loading times – but the question still remains in the end: 200% of what?

The only reasonable approach to get a handle on the loading times of an obese WordPress website may be a professional code analysis and a revision of the setup with a view to plugin performance.

5. The page speed paradox

An article about performance optimization would not be complete without mentioning tools like Google PageSpeed Insights, probably the most important thing to remember when using PageSpeed Insights and the like is: PageSpeed is not the same as page speed.

• PageSpeed Insights doesn’t measure load times; instead, it assigns a “Performance Level for a website, arbitrarily specified by Google. That performance level only looks at the degree of similarity with a specific catalog of criteria – meaning a sort of internal tool checklist.
• Google’s search algorithms do not take the PageSpeed score into account for the ranking of a website. It only looks at the load time – which doesn’t even appear on a PageSpeed Report.

The PageSpeed Insights recommendations can help to speed up a website. But only if someone is looking at them with sufficient relevant background knowledge. They will, however, cause more harm than good for users without specialist know-how and may result in hours of fruitless searches for “errors” that aren’t really errors.

Example: The PageSpeed paradox

A typical example for the PageSpeed paradox is the tool’s complaint about non-activated browser caching. A closer look will often reveal that the files for which PageSpeed is complaining about are not even loaded from the website’s own server, but from Google or Facebook instead. Right…what’s Google’s phone number again? Hi there, could you please activate browser caching for the Analytics script …

The recommendation regarding “CSS and JavaScript preventing rendering” can be similarly confusing. A slow WordPress website usually has a lot of problems with page volume being far too high. This might be due to arbitrary page design, sluggish AJAX requests and too many external resources. Render-blocking JavaScript should be at the very end of a long list of meaningful performance optimizations for anyone not well-versed in coding.

6. Performance testing with Pingdom tools

Offer a healthy compromise between sophisticated performance tests and comfortable usability. The following is a checklist for testing your own website:

• Choose a good server location. (For German language websites: Sweden, because this is the closest available location for Germany, Austria and Switzerland.)
• Concentrate on loading times!
  Forget about the score (from PageSpeed Insights) to start with; 60/100 is not necessarily bad and 90/100 is not automatically great.
• Scroll down to the table “File requests” for a detailed analysis and sort by “Load time”.
• Identify and where possible eliminate slow requests.
• Important: Always carry out several tests in series from the same server location to get a representative mean value.

Bottom line

Performance optimization for WordPress begins with the choice of theme and plugins for a website. The design and concept creation for the content plays a central role. You already won half the battle if you can think in terms of conversion criteria, instead of blindly following trends for sliders and large format background videos.

Specialist caching plugins can help in the automation of standard measures like page caching, browser caching, minification and concatenation. LazyLoad and asynchronous script requests can help boost load times. Whatever optimization they provide will only ever be relative to the original performance of the website.