All posts by Sallie Goetsch

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

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.


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 ( 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.


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.


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.


  •  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

July 2016 Handout: Accessibility Resources

The good news about web accessibility is that there are a lot of resources out there for developers who want to build accessible websites. Here are a few of the ones I’ve bookmarked.

These are not the result of a comprehensive search, which I’m sure would turn up many more resources, but rather articles I have come across in my regular WordPress and web development reading.

WordPress Accessibility Handbook

Rian Rietveld’s State of Accessibility Presentation from WordCamp Europe

Elise Roy’s TED Talk: When We Design for Accessibility, We All Benefit

Web Accessibility Basics from Marco Zehe

Free Web Accessibility Course from Udacity Accessibility Support Forum

WordPress > Support > Accessibility

The A11y Project


Tota11y Accessibility Visualization Kit

WAVE Web Accessibility Evaluation Tool

Enter your URL to check the accessibility of your website.

Yoast’s Must-Read Accessibility Posts (A11y and SEO)

Carrie Dils: An Intro to Accessible WordPress Themes

7 Things Every Designer Needs to Know about Accessibility

Article on Medium by Jesse Hausler from Salesforce. Doesn’t want to do the content card thing.

Color Safe WCAG Palette Generator

Presentation by Michael Beil: How do I know if my web project is accessible?

More WordCamp Accessibility Videos

tuts+ Accessibility Learning Guide

How to Make Your Website More Accessible (WPMU DEV)

PageGauge: Quickly Assess Your Website’s Usability

How to Create More Accessible Content

WP Accessibility Plugin

San Francisco WordPress Meetup to Host Joost deValk on July 27th

Beyond SEO: Copywriting for Professionals with Yoast

Wednesday, Jul 27, 2016, 7:00 PM

717 California Street San Francisco, CA

94 WordPress Enthusiasts Attending

SEO has gone from a technical trade to being more marketing focused. Joost & Marieke will talk about how to gain great rankings & satisfied visitors by writing good content. Focusing on SEO copywriting has a major pitfall. We give examples and tips on how to write a post that is both readable as well as SEO-friendly.Presenter: Joost de Valk Joo…

Check out this Meetup →

June 2016: Git Version Control for the Complete N00b

Adam LaBarge from Hyperarts introduced us to Git and GitHub: installing Git on Windows and Mac, cross-platform GUI clients for Git, repositories like GitHub, GitLab, and BitBucket, deploying from Git to WP Engine, and other useful tools for developers.

Notes from Adam’s Git Presentation

Git was invented by Linus Torvalds.

What’s different about Git? It takes snapshots of your data as your file changes. Git manages the version you see when you open the file.

Everything is local: all the changes and history are on your machine, so you can work without a network connection. If a teammate’s repo is destroyed, you’ll still have everything.

Git is an “add-only” program–it ‘s very hard to get it to delete anything.

WordPress updates are a key reason to use Git. You don’t want to overwrite working code.

You only want working code on stage and master.

Git is amazing for managing your team code efforts…though it IS possible to overwrite your co-workers’ code, so you have to do it right.

You will thank yourself for having a Git workflow and sticking to it.


Git is basically a command-line app. There is a terrible default GUI, and some other GUIs, but some things HAVE to be done on the command line.

There are install packages for Linux, Mac, and Windows. Be aware that you need to specify that you’re using Git for Windows when searching for help for Windows machines.


If you don’t want to use the command line, you can use something like SourceTree or GitHub Desktop.

The GitHub app gives you a good introduction, but it has some drawbacks, especially if you’re dealing with a huge number of files.


Repositories are a place to save your code but they also offer additional services.

You can belong to multiple repositories on GitHub, BitBucket, etc. You can scan your code for PHP errors in the process of pushing it to your repository.

Git by itself is just versioning, not user management. For user management you need a Git server, either one you create yourself or a hosted server like GitHub.



Fetch gets code from a remote repo, but without merging it into your local repo.

Branches: there should be at minimum master (production), stage (for the staging server, to test), and whatever working branches you want. When you’ve finished testing, merge locally, then push to repo.

Git does not have a pre-defined workflow, so you have to create one for yourself and your team. Don’t MAKE changes on the stage or master branch. Make them in a branch and merge.

SourceTree will let you know if someone else has made changes that you need to pull down. (A pull notification means there’s something you need to pull down.) Ideally, you won’t have two people working on the same branch at the same time, but let’s face it, it will happen. If you’re both working on the same branch and you get a pull notification, stop what you’re doing, merge your changes, fork the staging branch, pull down the changes. Merge his changes to your branch, and if they work, back to stage.

“If you’re not sure what’s going on, make a fork of what you’re working on.”

You can force push your changes and re-set the repository.

Whether you create a readme file and a .gitignore file on GitHub depends on whether you’ve already got them on your local.


WP Engine Git Deploy only goes one way, so you really want EVERYTHING in your local Git repo. (Or, well, the repo where you’re keeping stuff, which could be on GitHub or wherever.)

SiteGround’s Git Tutorials

It’s easier to use the HTTPS version than the SSH, because with SSH you have to generate keys. Alas, both WP Engine and SiteGround require SSH keys. There seems to be an assumption you’re going to be working from GitHub so you can generate keys there.

If your code is already on a host, you can push the code from your host to GitHub and then pull it to your local install. (Assuming you have SSH access, of course.)


Don’t be scared to delete Git and start again.

Revert is a pain. Switching branches is easier.

If you don’t commit a change, there won’t be any record of it, so if you want it saved for posterity, commit it!

Before you do anything else, “git status” to find out where you are and what’s pending

The head is the last point of the current branch.

If you find a conflict, humans have to intervene: contact your colleague and decide whose version to use. You have to tell Git you resolved the conflict by re-adding the files.

May 2016 Q & A: Content Audits, 301 Redirects, and Dev Tools

Here are some of the things that came up during our general discussion at the May 2016 Meetup.

What Is a Content Audit?

Sallie mentioned being in the middle of a content audit for a very long site, and someone asked what that was. A content audit is when you review every single piece of content in a site and rate it based on such criteria as

  • Is it current?
  • Is it relevant?
  • Is it on-message?
  • Are there any broken links?
  • What type of content is it? (For example, should this be a press release instead of a blog post?)
  • Does it have a featured image?
  • Does it have an SEO-friendly title?
  • Does it have an SEO-friendly meta description?

On a small site, this can be done in a few hours. You want to do a content audit before building a new site, in order to know what to keep, what to get rid of, how many custom post types you need to create, and what new assets the client needs to provide. You’ll also need that list of URLs so you can set up the redirects.

301 Redirects

When you build a new website for a client–especially one that already has a lot of inbound links and a good Google ranking–you need to set up 301 (moved permanently) redirects from the old URLs to the new URLs. You can also use redirects to make sure that everyone uses instead of (or the other way around), or https:// instead of http://

Redirects are normally set up in your .htaccess file, but there are also WordPress plugins like Redirection and Quick Page/Post Redirect.

If the old site has structured its content logically with pages and sub-pages, you can use regular expressions (regex) to map groups of URLS, e.g, everything with the structure should go under

In some cases that won’t be possible (because not everything that’s under /blog/ on the old site belongs under /blog/ on the new site, for instance), so you end up with a very long list of old and new URLs in that content audit spreadsheet.

In that case, you’re faced with translating your spreadsheet into the proper format to put in your .htaccess file, which could get ugly.

Fortunately, there’s a Batch Rewrite Rule Generator provided by Donat Studios. Paste your spreadsheet columns into the box and get 301s or Rewrite Rules.

Fixing Mixed Content

Once you’ve set up your Let’s Encrypt certificate, you’ll want to install the Really Simple SSL plugin to fixed mixed content issues. (Basically it puts a few lines in your wp-config.php file, which you can do yourself if you prefer.)

Browse with HTTPS

Install the HTTPS Everywhere browser extension from the Electronic Frontier Fonudation to ensure that you get the HTTPS version of every website you visit (if one is available). Works on Chrome, Firefox, and Opera.

Local Dev Environment: AMPPS

Ted was having problems with MAMP, so he switched to using AMPPS. It’s like MAMP with Python and Softaculous included. All those Softaculous apps seem like a lot to include in a package you’re only using for WordPress development, but if you work on multiple platforms, it could be happy.

Local Dev Environment: Vagrant

Daniel was also having trouble with MAMP, so he switched to using Vagrant, a tool for deploying local dev environments. Requires some use of the command line.

Workflow Tool: Yeoman

If you’re already a happy user of the command line, you can save yourself time with Yeoman, though you will have to take some time to use it. If you aren’t working with the command line, figuring this out will probably take you longer than doing things the way you normally do.

Database: MariaDB

Daniel has started using MariaDB combined with PHP 7 for faster, better-performing sites. MariaDB works fine with WordPress without a lot of tinkering. Of course, it’s easier to set up in a local environment or on a dedicated server. If you’re on shared hosting and your host doesn’t provide it, you’re out of luck.

So What’s Wrong with GoDaddy’s Managed WordPress Hosting?

On the plus side, GoDaddy’s Managed WordPress Hosting is a lot better for WordPress than their shared hosting, and it’s competitively priced.

On the minus side, it uses an old version of PHP and there’s no way to upgrade it. There have been issues with staging -> production migration. Some of us find that the WordPress admin is amazingly slow and generally under-resourced: simple things like plugin upgrades can time out, never mind BackupBuddy backups.

The few dollars you save versus SiteGround or A2 are probably not worth it. If you need inexpensive WP hosting you can try Tap, which is $5/month for the pro plan.