October Slides: High-Performance WordPress Websites with Sonja London

Presentation Summary

Speed matters. No one wants to wait around for your site to load, especially on a phone. And WordPress isn’t known for being fast: one of the key selling points of WordPress managed hosting is the server-side caching.

Sonja London has been doing performance tuning since before WordPress was invented. She explains how to determine what’s slowing your site down and what to do about it. Don’t settle for the generic suggestions provided by Google PageSpeed Insights: following them may make no difference at all if your real problem lies somewhere else.

Presentation Slides

High-Performance WordPress Websites

Sallie’s Notes

Remember to ask

• How fast does it need to be?
• Are you being paid to speed it up?

What Is Performance?

Performance is not speed, but speed is a component of performance. You want your page to load in under 2 seconds. Or at least most of your pages.

Throughput is the number of transactions per second that an application can handle. Throughput can assassinate speed.

Using tests as metrics vs. what the client experiences (what if they have an iPhone 3?)

Latency is (usually) defined the time between making a request and beginning to see a result. (Start of page load.) If a site is slow everywhere for everyone, it’s probably the site. But if the site is slow only for people in a certain area, it’s probably something to do with their connection. Latency is usually beyond your control as a developer.

A HILARIOUS slide of a test where the site is rated F but loads in 1.2 seconds.

What are you testing? Where does the test bot live? Some of the criteria used by GTmetrix et al. are not very logical. Sonja says that Google Pagespeed Insights may be a better tool for beginners

Use PingPlotter for measuring latency and also packet loss.

Deliver only what you need, where you need it, when you need it, from where it should be. And make your clients do it, too.

Hosting

The most important things for your host: location, location, location (well, for their data centers, anyway)

Server configuration: memory, SSD, CPU speed/cores

Who is really hosting? Do they have their own data centers, or do they buy rack space from somewhere?

That’s not necessarily bad, but you want to be sure that the actual servers are good.

Plugin performance: the simple thing is to test speed first, install, test after.

Use SEO Framework instead of Yoast. (I’ll have to look at it.)

If you have to use a page builder, read Pippin Williamson’s review.

The Database

There are multiple MySQL engines. Find out what your host uses. Some are better than others for transactions. You can have more than one kind of engine in a database (by table). If you write a plugin that creates a table, you can specify the engine. And most hosts let you choose between a couple of different ones within phpMyAdmin. Some hosts also let you choose in cPanel.

The most common are MyISAM and InnoDB. InnoDB is better for transactions and low-level locking.

If you need something temporary, you can just do it in memory.

Federated tables don’t exist in your system. They are somewhere else. This is a bit above my head, but it’s a way to share data.

Plugins and your Database

Watch out for WordFence: not only does it create too many tables, but it uses camel case for table names. Capitals are not allowed in databases on Windows. It throws errors with things like duplicated. Just keep all your table names lower case.

Some plugins have too much logging, and people forget to turn it off when they go to production. Always turn off logging if you want performance.

LOOK AT YOUR DATABASE. Find out what tables are in there. Beware of duplicates caused by migrations.

Know when to use an abstraction layer. (WP’s functions.) Most of the time you SHOULD use WP’s functions. Use dbDelta (https://developer.wordpress.org/reference/functions/dbdelta/) to create tables.

Use Query Monitor to keep track of your queries.

Plan for the future.

For really high-end sites, consider HyperDB, which distributes your database to help with heavy transaction processing. (Hmm…meetup about HyperDB? Meetup about the GPL?)

Maintain your database. Clear out things like autosaves and revisions, transients, users who are no longer active, etc.

Test your database performance periodically. Just because it was good two years ago, doesn’t mean it’s good now. If your page speed is good, the DB is probably okay, but look at queries, the size of the DB, etc.

Caching

What the cache does is store things as HTML instead of going to the database every time.

Opcode (like APC) is for PHP

Memcached is for SQL

CDNs serve your site from multiple data centers, close to the people visiting. (Which reminds me…) Depending on your problems, a traditional CDN may not help.

Turn on browser caching via .htaccess.

Compression

Compress All the Things. Bake it into your development process. PrePros GUI for automation (instead of Gulp, if you don’t like the command line)

Choose your image format based on the type of image it is. Consider SVG for your logo.

You can also enable GZIP compression via .htaccess. Vary accept encoding. (Google that. It’s for compatibility with CDNs.) You can use it for the basics (text, html, CSS, JS, etc.), or you can apply it to All the Things

Operating System & Web Server

Linux and Apache are the most common, but Nginx is becoming increasingly popular. Sometimes they get combined in a reverse proxy. Nginx is faster.

Tools

• Monitor.us  and Uptime Robot are good tools to use. They can monitor from multiple locations at different times. Note that if you are on shared hosting and you monitor really often, the host might object.
• GTmetrix, ySlow, Google PageSpeed Insights, Pingdom
• Query Monitor and Debug Bar plugins for your dev server. (Take off production server)
• PingPlotter
• .htaccess Guide

Send your questions to sonja@zosi.me