WordPress Performance and Security Checklist for 2026

Most WordPress advice online is written for a version of WordPress that no longer exists. Between PHP version requirements, the block editor maturing, and Core Web Vitals becoming a real ranking factor, the boring stuff matters more than ever. Here’s what I actually do on client sites in 2026, in the order I do it.

Start with the host, not the plugins

No plugin will save a site running on a $3 shared plan with no object cache and a 300ms time-to-first-byte. If your host doesn’t offer PHP 8.3, HTTP/3, and some form of server-level caching, you’re fighting uphill. That’s the first conversation I have, and it’s usually the cheapest fix with the biggest payoff.

Things worth checking before you touch anything else:

• PHP 8.3 or newer (8.1 and 8.2 are on security-only support now)
• MySQL 8.0+ or MariaDB 10.6+
• Server-level page caching (LiteSpeed, NGINX FastCGI, or similar)
• Free or cheap automated offsite backups you can restore yourself

Core Web Vitals still drive rankings

LCP, INP, and CLS are what Google measures, and INP replaced FID back in 2024 so a lot of older advice is stale. INP punishes heavy JavaScript and slow event handlers, which means your page builder and your plugin count matter.

Quick wins that hold up:

• Convert images to WebP or AVIF and serve them at the right size. Don’t upload a 4000px photo and let CSS shrink it.
• Set explicit width and height on every image to kill layout shift.
• Defer non-critical JS and stop loading plugins on pages that don’t use them.
• Use system fonts or preload your webfont. A font swap delay hurts LCP.

Here’s a small functions.php snippet I use to disable a plugin on specific pages without a plugin manager:

add_filter( 'option_active_plugins', function( $plugins ) {
 if ( ! is_page( 'contact' ) ) {
 return $plugins;
 }
 $drop = array( 'some-heavy-plugin/some-heavy-plugin.php' );
 return array_values( array_diff( $plugins, $drop ) );
} );

It’s blunt, but it works and it’s easy to reason about.

Security is mostly about not being boring

Nobody gets hacked because they were interesting. They get hacked because they never updated, or they installed a nulled theme, or they left XML-RPC wide open with a weak admin password.

• Disable file editing in the dashboard: define( 'DISALLOW_FILE_EDIT', true ); in wp-config.php.
• Force strong passwords and enable two-factor auth for every admin account.
• Limit login attempts and block XML-RPC if you don’t use the app.
• Keep a staging site so you can test updates before they hit production.

That last one is the one people skip and regret. A broken update at 2am on a Friday is a much worse problem than a slightly slower deploy process.

Backups you can actually restore

A backup that has never been tested is a hope, not a backup. I keep daily offsite backups and I restore one to a staging environment once a quarter just to confirm it works. It takes twenty minutes and it has saved me twice.

Store them somewhere that isn’t your web host. If your host goes down, so does your backup. S3, Backblaze B2, or Google Drive all work fine.

Keep the plugin list short

Every plugin is code someone else maintains, and every one is a potential security hole or a performance tax. Before adding a plugin, ask if the theme or a few lines of code can do it. A lot of “essential” plugins are doing something you could write in ten lines and never worry about again.

If you’re not comfortable maintaining that side of things yourself, this is exactly the kind of work I do as a Long Island web design consultant, and honestly, most of it is just discipline more than talent.

FAQ

Do I need to be on PHP 8.3 in 2026?

Yes, or at least 8.2. Older versions are past end of life and no longer receive security patches, which is a real risk, not a theoretical one.

How many plugins is too many?

There’s no magic number. Ten lean, well-maintained plugins beat three bloated ones every time. Judge by what they load on each page, not by the count.

Is a page builder always bad for performance?

No. Modern builders output cleaner markup than they used to. The problem is usually the extra CSS and JS they enqueue site-wide, which you can trim with conditional loading.