DEV Community: Tyler Russo

Why Your WordPress Site Is Slow (It's Probably Not Your Host)

Tyler Russo — Mon, 05 Oct 2026 23:12:54 +0000

Everyone blames the host. "I need to upgrade my plan." Nine times out of ten, the host is fine — the site is just carrying dead weight. Here's how I find it.

Start with a real measurement

Don't guess. Run your URL through PageSpeed Insights and write down three numbers: LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and TTFB (Time to First Byte). These are your before numbers. Everything below is about moving them.

If TTFB is over 600ms on a cached page, then you can blame the host. Under that, keep reading.

The usual suspects, in order

1. No page caching. This is the big one. Every uncached WordPress request boots PHP, hits MySQL, renders the theme — hundreds of milliseconds you don't need to spend. A caching plugin serving static HTML cuts that to near zero. This alone fixes most "slow WordPress" complaints.

2. Unoptimized images. I still find 4MB PNGs as hero images. Convert to WebP, resize to the actual display size, and lazy-load everything below the fold. A single oversized image can blow your entire LCP budget.

3. Plugin bloat. Deactivate everything, then reactivate one at a time while watching TTFB. Page builders, slider plugins, and "all-in-one" packs are the usual offenders. If a plugin adds 200ms and you barely use it, it's gone.

4. No database cleanup. Years of post revisions, expired transients, and orphaned metadata slow down every query. Back up first, then clean house.

5. Old PHP. PHP 7.4 to 8.x is a free 20-30% performance gain. Most hosts let you switch in the control panel. Check plugin compatibility first, then flip it.

The order matters

Do caching first — it masks a multitude of sins and gives you the biggest immediate win. Then images, then plugins, then database, then PHP. Each step builds on the last, and you re-measure after each one so you know what actually moved the needle.

What "fast enough" looks like

LCP under 2.5 seconds
INP under 200ms
TTFB under 600ms (under 200ms cached)

Hit those and you're in Google's good graces for Core Web Vitals, which is a ranking factor.

The full process — 40 checkpoints covering caching, database cleanup, image optimization, CDN setup, and PHP tuning, in the exact order to do them — is in my WordPress Speed Checklist. Every step includes the before-and-after measurement so you can prove it worked.

The Pre-Migration Server Audit: What to Document Before You Touch Anything

Tyler Russo — Mon, 05 Oct 2026 15:43:04 +0000

Migrating a VPS goes sideways in the same places every time — and it's never the part you expect. It's the queue worker left on the old box. The certbot renewal in root's crontab. The rsync that died on permissions.

Before you move anything, audit the old server. Here's the checklist.

Running services

systemctl list-units --type=service --state=running
ss -tlnp

Write down everything. That random Python process on port 8000? That's serving something. Find out what before you migrate.

Cron jobs (all four places)

crontab -l                    # your user
sudo crontab -l               # root
ls /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/
systemctl list-timers         # systemd timers (the new cron)

Miss one and something silently stops working a week after migration.

Disk and databases

df -h
du -sh /var/www/* /home/*
mysql -e "SHOW DATABASES;"    # or psql -l for Postgres

Know what you're moving before you start moving it.

SSL certificates

certbot certificates
ls /etc/letsencrypt/live/

Note expiry dates and renewal method. If certbot auto-renewal is configured, that config needs to move too.

Config files

Document every customized config: nginx/apache vhosts, PHP settings, systemd units, environment files. diff against defaults if you're not sure what you changed.

This audit is Zone 1 of my VPS Migration Checklist & Runbook — 38 checkpoints across 8 zones, from this audit through cutover and the 24-hour watch afterward. The full runbook covers rsync flags, database moves, the hosts-file testing trick, and the rollback plan you write before you need it.

How to Test a WordPress Backup Restore (Before You Need It)

Tyler Russo — Mon, 05 Oct 2026 15:00:22 +0000

Untested backups aren't backups. They're hopes. Here's how to prove yours actually work — the full restore drill I run.

What you need

A scratch server or local environment (doesn't need to be powerful)
Your latest backup files (database dump + files archive)
About an hour

Step 1: Set up the scratch environment

Spin up a fresh Ubuntu box or Docker container. Install the same PHP version your production site runs — version mismatches cause the weirdest restore failures.

Step 2: Restore the database

mysql -u root -p new_database < backup.sql

Then verify: count the tables, check that wp_options has your site URL. If the dump is corrupted or incomplete, you want to know now.

Step 3: Restore the files

Extract your files archive to the web root. Check that wp-config.php is there (some backup tools exclude it — that's a nasty surprise at 2am).

Step 4: Point and test

Update wp-config.php with the new database credentials. Add this to your local /etc/hosts:

127.0.0.1 yoursite.com

Now browse the site. Click around. Log into wp-admin. Upload a test image. If everything works, your backup is real.

Step 5: Document what you learned

Write down every step you took, every gotcha you hit. That's your disaster runbook. Next time you're restoring at midnight with the site down, you'll thank past-you.

How often?

Quarterly at minimum. After every major change (host migration, PHP upgrade, big plugin update).

The full backup process — 40 checkpoints across 7 zones covering inventory, automation, encrypted offsite copies, and monitoring — is in my WordPress Backup & Disaster Recovery Checklist. The restore drill above is Zone 5.

Hardening SSH on Ubuntu 24.04: The 6 Things That Actually Matter

Tyler Russo — Mon, 05 Oct 2026 14:59:13 +0000

Most SSH hardening guides give you 30 config options and no sense of priority. Here's what actually matters, in the order I'd do them on a fresh Ubuntu 24.04 server.

1. Key-only auth (but test first)

Generate your key, copy it over, SSH in with the key to confirm it works — then disable passwords. The number of people who lock themselves out by doing this backwards is staggering.

PasswordAuthentication no
ChallengeResponseAuthentication no

2. The cloud-image gotcha

On Ubuntu cloud images (AWS, DigitalOcean, etc.), there's a file at /etc/ssh/sshd_config.d/60-cloudimg-settings.conf that overrides whatever you put in sshd_config. Drop-in files are read alphabetically, first value wins — so 60-cloudimg-settings.conf beats your settings.

The fix: put your hardening in /etc/ssh/sshd_config.d/10-hardening.conf. 10 beats 60. I wrote about this in detail here.

3. Disable root login

PermitRootLogin no

You have sudo. You don't need direct root SSH.

4. Change the port (yes, really)

Security through obscurity isn't security — but moving off port 22 eliminates 99% of automated brute-force noise, which makes your logs readable and fail2ban's job easier.

5. fail2ban with sane defaults

sudo apt install fail2ban

The default SSH jail is fine for most people. Check it's running: sudo fail2ban-client status sshd.

6. Automatic security updates

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

This is the 30-minute emergency version. The full process — 46 checkpoints covering users, firewall, kernel tweaks, file permissions, log monitoring, and more — is in my Linux Server Hardening Checklist. Every command tested on real Ubuntu 22.04 and 24.04 servers.

Or grab the free 7-step emergency lockdown checklist if you just need the essentials right now.

Your SSH hardening guide has a bug: on cloud servers, 60 beats 99

Tyler Russo — Sun, 04 Oct 2026 12:37:21 +0000

I sell a server hardening checklist, so last week I did something most checklist authors never do: I re-ran every single command against a real Ubuntu 24.04 box instead of trusting the docs.

Two of the commands were wrong. Not "suboptimal" — wrong. One of them fails silently, which is worse. Here's the interesting one.

The setup

Most SSH hardening guides tell you the same thing: don't edit /etc/ssh/sshd_config directly. Drop your settings into /etc/ssh/sshd_config.d/, conventionally in a file named something like 99-hardening.conf. High number, loads last, wins. Clean, package-manager-safe advice.

It's wrong on cloud images.

What actually happens

Ubuntu cloud images (AWS, DigitalOcean, Hetzner, all of them) ship a file at:

/etc/ssh/sshd_config.d/60-cloudimg-settings.conf

And here's the part the guides skip: sshd reads the drop-in directory with a glob, in alphabetical order — and for most keywords, sshd uses first-value-wins semantics. The first setting it encounters is the one that sticks.

60 sorts before 99. So your carefully written 99-hardening.conf loses to the cloud image's file for every keyword they both set — and it loses silently. No error, no warning. Your hardening setting just... doesn't apply.

I proved it the honest way: wrote a test value into 99-hardening.conf on a real 24.04 box and ran:

sudo sshd -T | grep -i <keyword>

The effective config showed the cloud image's value, not mine. My file might as well not have existed.

The fix (30 seconds)

Name your file so it sorts before the cloud image's file:

sudo mv /etc/ssh/sshd_config.d/99-hardening.conf \
        /etc/ssh/sshd_config.d/10-hardening.conf

Then verify — don't trust, verify:

sudo sshd -T | grep -i <keyword>

sshd -T prints the effective configuration after all includes are resolved. If your value shows up there, it won. If it doesn't, something earlier in the sort order is beating you, and now you know how to find it.

This also means the generic advice "put it in the main sshd_config" is doubly broken: the main file Includes the drop-in directory at the top, so drop-ins beat the main file too. The drop-in directory is the right place — you just have to win the sort order.

Bonus bug: `systemctl restart sshd` fails on Ubuntu

While I was at it: half the guides say systemctl restart sshd after editing. On Ubuntu there is no sshd.service — the unit is ssh. The command fails, and if you're following a guide at 2 AM you get to debug that instead of sleeping:

sudo systemctl restart ssh   # not sshd, on Ubuntu/Debian

(RHEL-family distros do use sshd. Know your box.)

The actual lesson

Doc-based audits miss ordering and naming subtleties. The only audit I trust anymore is running the real binary and reading what it says: sshd -T for SSH, nginx -t for nginx, and so on. If your hardening checklist wasn't verified against a live system, it's a wish list.

I turned the full verified checklist into a 46-checkpoint playbook (every command tested like this one), but the 7-step starter version is free — Emergency Server Lockdown Checklist. Lock down a VPS tonight with copy-paste commands.