WordPress init

Today at Word Camp London I was sitting at the Happiness Bar (no shots – we’re there to engineer happiness by way of solving your problems, not by drowning them out) and a gentleman came to us and lamented his lack of sleep over a WordPress site he was building for a client. The public side was just fine, but it was taking over twelve seconds to load for logged-in users! Since being logged in was essential for the users of his site, this was a show-stopper. Engineers attack!

You will never find the problem

We spent a couple of hours pouring over this gentleman’s site with him as we tried to get it up to speed. We ended up with a sufficient boost in performance and found lots of issues along the way that confounded the causes behind his code’s lethargy and his insomnia. Not a single solution that we came up with was a smoking bullet, but taken together they accomplished our goal of making it not a miserable experience to use.

WordPress needs quality plugin love

It may only take five minutes to install a default WordPress installation, but it also feels like such a vanilla site might very well take five minutes to load. The problem and solution behind so many of your WordPress woes is how open it is and how powerful it’s plugins can be. It depends on smart caching to perform but can handle just about anything when this is done properly. I’m going to share what we discovered today as a lesson in getting your site ready to go live.

TL;DR

Don’t:
– eschew simplicity through eager optimization
– prefer death by the thousand cuts of plugin overkill
– submit to the anxiety, fear, and despair of impending project doom

Do:
– eschew complexity by focussing on content first
– prefer fewer but higher-quality components such as themes and plugins
– submit to the help and friendship of the WordPress community

Stop hiding your problems

The site we were working with today probably suffered from cheap server infrastructure: spinning hard drives being the chief culprit. It took us a while to make this conjecture though because we had to peel back so many layers of bandaids that had been applied to try make things work. The gentleman who built this site was rightfully concerned about speed, security, and safeguarding, but he was too eager to harden his site. He had installed an array or related plugins before asking if they were even required.

The first problem with this over-eager optimization is that we hide fixable problems. A good example of this is how by distraction we didn’t realize that gzip was disabled across the board for his web server. While true that lack of compression was wasting valuable seconds and that it was plain-as-day when looking at the response headers, we didn’t think to look there because of the massive TTFB delays we saw. Something like this should have been caught early on rather than right before deployment.

Another example is the first time delay loading the page. Because we knew that there were caching plugins installed, we cognitively dismissed the long page generation time at the fest load because we knew building the cache takes longer than just displaying the page. If the page loads had been consistently slow (and caching disabled) we would have probably looked for some misconfiguration.

These two examples illustrate the frustration of unravelling strange interactions of code. Almost every plugin and theme in WordPress was developed by an independent party who had to provide everything necessary to make it work, this in isolation or disregard of others.

On the one hand, this leads to proliferation of loaded resources. “Hey, why not use jQuery – the browser only needs it once!” Well, you might say, developers stick to certain versions of these things that don’t break their code and that don’t get messed up through caching. Every resource that this theme and several of the plugins pulled in requested the file with a specific version in the query parameters. Additionally, another plugin was trying to intercept some of these library requests and and pull them from Google instead of from the local server. One of the most effective ways to slow down your site is to load more resources. Because of these version-specific requests or sometimes because of laziness, sites can end up loading three or four slightly different versions of the same library when one would do. This not only fills the download queue, but it can kill minification efforts on account of the duplicate code. Trying to combine identical or very similar copies of JavaScript or CSS can lead to bloat at best and spurious cascading errors at worst.

On the other hand, even an expert in WordPress development will be oblivious to the internal workings of most plugins. Although the source code for every plugin is available for perusal, reading and understanding the different code paths and navigating through various code styles takes time and effort for low return on investment. Debugging certain problems comes down to, “it’s probably a plugin messing things up.” No evidence, no understanding, no good tools for discovery. We started debugging his site by disabling every plugin that didn’t noticeably alter his site so we could cross of those potential sources of breakage.

Finally, hiding problems takes away our ability to understand the fixes and improvements we make. If the first thing you add to your site is a caching plugin, how will know what impact it has on your load time? If someone asks you why you had to spend six hours to fix their site, how will you answer if all you did was start toggling plugins on and off until it got fixed? Measuring your work is not only part of being professional, but it will improve your skill at debugging and improve your efficiency for related issues in the future.

Simplicity is a tool

For whichever definition of simplicity you ascribe to, it likely implies the removal of those things that aren’t necessary. Simplifying your wardrobe could mean getting rid of the pile of clothes you haven’t worn in a year, certainly not removing all of your clothes though. It’s a tool because it removes unnecessary burden from your life. Why add to the stress by worrying about what you will wear – just grab the shirt at the top and go with it.

Simplifying in WordPress similarly means the removal of those components that get executed but don’t materially contribute to the end result of your website. It might involve deleting deactivated plugins or plugins that provide tracking functionality or caching, for example; it certainly doesn’t mean that you would remove your eCommerce plugin for your online storefront. It could also mean finding better plugins that accomplish more, better, with less. JetPack is an example of a plugin with strong support and robust functionality. It can provide functionality that would normally require several other plugins: serving images from an optimized CDN, protection from spammers and bots, and related post functionality just to name a few.

While the availability of free plugins and themes does wonders to keep the barrier-to-entry low in the WordPress community, these resources are certainly not always the best or cheapest alternatives. Premium themes can seem expensive, but often times they are maintained by a focussed team and dramatically cut down the amount of time developers need to build and maintain their sites. Time is an expensive and non-renewable resource.

More installed components means more opportunities to introduce bugs and strange interoperability issues between the different pieces of code in your site. These interactions are among some of the worst problems to resolve because they often occur sporadically and disappear when the plugins are being separated and individually tested.

In our case study, we found some of the worst offenders in the plugins in these regards. We had a plugin that was modifying some core WordPress functionality in a faulty way, which left its trail after deleting it because the author included no proper uninstall. There were several image optimization plugins all activated at the same time, one for backup, another for continuous anti-virus and anti-spam, plugins to spread requests out to CDNs, and plugins to pull content from CDNs to the local server. We couldn’t figure out if and how the image plugins interacted, but most likely they all ran one after another to try and optimize things, in the mean time spending three times as much time processing pictures and increasing the site’s memory footprint. The caching plugin was complaining in wp-admin that some minified file had an error in it.

The installed “optimizations” were in large part the cause behind the performance degradation. They were accomplishing their anti-goal. Ironically, if our gentleman had been less concerned in his own mind about performance and security, he would have avoided this frenetic plugin bonanza and his site would have been fine.

Participate in the community

The WordPress community (the forums, Slack team, meet-ups, and Word Camps) is a great place to learn and teach. It thrives on the participation of its members. The gentleman who came to me today at the Happiness Bar had spent all week trying to fix his site, but he lacked the experience to be able to pinpoint the areas to look for trouble. As soon as my colleague and I got involved we were able to quickly start resolving this. In the end, it still took over two hours to patch up, but not only did he get his site working, but he acquired new skills as we worked together. Since most people in the WordPress community have benefited from the experience of others, they tend to spend some of their own time to voluntarily help others who are earlier on in their journey. Sometimes it’s worth struggling through the challenge of fixing what broke, but when the deadlines are pressing, accept the help of someone who can listen to your problem, give a moment’s pause to consider it, then home in on it like a laser-guided bomb. You’ll be glad you did, and you’ll sleep better at night.

WordPress init checklist

  • Do the initial site design and build with caching and optimization plugins disabled
  • As you formulate your design, research the availability of themes that are designed for similar goals. Try to find some premium themes that have a multitude of strong reviews. Having a reliable support team and a well-vetted theme will far outweigh the meagre costs upfront.
  • Once you invest in a theme, remove any other themes you have installed but aren’t using. They will only get in the way and cause you headaches as you try to keep them updated.
  • Do similar research for your plugins. You can probably even get by with fewer plugins than you think. Every new theme and every new plugin is a potential attack vector for malicious activity.
  • Strongly avoid plugins that come with warnings, such as “Be careful when using this – it could break your site.” Yes, they do exist, and yes, more often than you think. It doesn’t mean the authors are bad programmers; it could just mean that they have limited time and deadlines of their own and they haven’t been able to take care of everything that needs care (another reason why it’s worth your money to have components designed by professional teams who will stand by their work and save you from trouble).
  • Install the Jetpack plugin by Automattic and link it to your WordPress.com account. This adds considerable value to your site and will save you time as you manage it (and others). This is not a shameless plug because I work for Automattic, and I understand the concerns some people have with linking their private installations to WordPress.com. Rather, my recommendation comes from the multitude of benefits I have experienced since starting to use Jetpack with my self-hosted WordPress installations. (By the way, Jetpack is not an all-or-nothing deal. You can selectively activate its various features).
  • Create an API key on Akismet.com and activate your spam-shield. Accounts are free but please contribute out of courtesy if the site will be generating revue. You don’t want to wait until spam comments are a problem to deal with them.
  • Get some help with an automated backup solution. Be very weary about backup plugins because they often slow your site down and they will never work if your site is really broken since they depend on the same code. Consider something like a subscription to VaultPress, which does daily automatic backups and security scans against your site without causing a significant impact.
  • Develop your design, create your content, and publish your pages and posts. This should be the biggest and most important step!
  • When the above step is finished and the site looks right and behaves properly, use webpagetest.com to analyze its performance. Run the test a few times so you can identify spurious tests if they exist.
  • What is the time to the first byte (TTFB)? It’s best to try and keep this below 500 ms. Ideally it would be just a bit longer than your ping time, but that will rarely ever happen, especially on shared WordPress hosts.
  • Pay special attention to long TTFB metrics from simple and static files, such as from images. An image should never take much time to deliver, so if you see a long wait before the server starts sending the data, something is probably broken.
  • How many resources are being loaded? One hundred is a lot of files to be loading, and they are probably loading for each page of your site. Do you see repetitive JavaScript libraries or stylesheets? Maybe you can eliminate some of these.
  • Inspect some text files (HTML, CSS, JavaScript) and make sure that they are being sent compressed: gzip is preferred, but deflate is still much better than nothing. This is a server setting and not a WordPress setting. It should be handled through the Apache or Nginx config. If you don’t have access to this, prioritize a support-ticket with your provider so that they can help you activate it. The text files that build websites are incredibly good candidates for compression and you could probably find examples of shrinking the used data by over 90%. Less data means less time spent transmitting and it means less bandwidth usage for our mobile friends – they appreciate it when you consider their data caps.
  • Make sure you run the tests both while logged-in to your website and also when logged out. There’s a huge difference between these two states.
  • If the performance is good, you have done a good job and can and should move on to installing a caching plugin. If your site is taking more than four seconds to load, you likely have a solvable problem or a poor host. If you don’t know how to make things faster, turn to the community for help.
  • Install W3 Total Cache and activate the Page cache on Disk: Enhanced mode; leave everything else off. Navigate around your site to prime the cache and then rerun the performance tests on webpagetest.com. You should see a significant improvement. Target a load time of 0.5 s but don’t flip if it takes between one and two seconds.
  • If your load time is still above two seconds and you have a bunch of resources loading that you can’t eliminate, try turning on the minify setting in in W3 Total Cache. Do extensive testing for how the site looks and behaves and abort if anything is wrong or if you don’t eliminate a bunch of resource loads. The risk is not worth a small improvements.
  • If things feel smooth enough on your site, leave things as they are. If you want to continue to harden your site or speed it up, look for some other experiences in the Forums or ask someone in Slack their opinion. Be weary of plugins.

Congratulations!

You made it! Your site is ready to go live. You know what question that man had that prompted this support session? He wanted to know how he could profile the execution of his site’s PHP. He had even installed a debug plugin to analyze the database calls being made on each page (pretty slick, actually). This kind of deep optimization should be totally unnecessary for building a site. It’s very technical and very granular, like the sleight-of-hand from a magician it more often distracts us from what’s really happening while we chase down rabbit holes. Unless you are a core developer or love to explore, don’t waste your time on these things: if your site is unbearably slow or inefficient or broken, get some help and fix it!

Categories technologyTags ,

1 thought on “WordPress init

  1. Reblogged this on Snell Family Adventures and commented:

    Helping people solve their problems is one way I love to learn how to solve my own 😉The following technical post is a follow-up from my weekend at a WordPress community event called Word Camp London where I spent some time helping a man discover why his website was taking over twelve seconds to load and fix it.

Leave a Reply

%d
search previous next tag category expand menu location phone mail time cart zoom edit close