Upgrade PHP on Your Store: Compatibility Checks, Extensions, and Speed Gains

Upgrade PHP on Your Store: Compatibility Checks, Extensions, and Speed Gains

1. Why your PHP version affects store performance

WordPress is written in PHP, so every page request first runs the PHP interpreter, which translates the code into instructions the machine can execute. The newer the PHP version, the faster that translation goes. PHP 8.x includes a long list of low-level optimizations over 7.4, including OPcache improvements, JIT compilation, and better memory management, so the same code runs about twice as fast on 8.2 as on 7.4.

You feel this speed gain directly on your store. A site with an LCP of 3.5 seconds on PHP 7.4 can drop to around 2 seconds after moving to 8.2 with OPcache enabled, turning its Core Web Vitals from red to green. No theme changes, no plugin swaps, no added caching. Just changing the PHP version gets you there. That’s why ops teams recommend upgrading PHP at least once every two years.

Many stores still run on PHP 7.4 or even 7.3 because “it’s always worked fine, so I’m afraid to touch it.” But 7.4 has had no security patches since November 2022, which means new vulnerabilities go unfixed. For stores selling overseas, running on a PHP version with no security updates means the risk of getting hacked grows over time. For what to do after a hack, see What to do after your site is hacked. For security hardening and backups, see Backup and recovery drills for your site.

2. Compatibility checks: three things to do before you upgrade

The biggest risk of a PHP upgrade isn’t performance, it’s compatibility. PHP 8.x made some breaking changes to the syntax, like deprecating old functions, tightening type strictness, and changing some long-standing behaviors. If your theme or plugins use any of those deprecated patterns, your site will go straight to a white screen after the upgrade, and you won’t even be able to get into the admin.

Do three things before you upgrade. First, update all plugins and themes to the latest versions. Old versions are often incompatible with new PHP, and newer versions have usually already fixed it. Second, use a plugin like PHP Compatibility Checker to scan your entire site’s code and see which files use incompatible patterns. Third, switch the PHP version in a staging environment and walk through every core function.

Example scenario: a B2B site uses an old form plugin from 2019 that throws errors on PHP 8.1. Before upgrading, you run Compatibility Checker and find the plugin uses mysql_* functions (deprecated back in PHP 7.0). Don’t force the PHP upgrade here. First find a replacement form plugin, such as WPForms or Fluent Forms, migrate the forms over, then upgrade PHP. See how crater handles plugin compatibility on overseas sites in crater’s tech stack and four in-house plugins.

Counterintuitive take: the PHP compatibility warnings in WordPress’s Site Health are often wrong. It only checks the plugin versions you currently have installed, so if you’re running the latest version of a plugin but the author hasn’t updated their compatibility testing, the admin will still say it’s compatible. The right approach is to run a scanning tool yourself, then actually test it in a staging environment. Don’t just trust what the admin tells you.

3. Choosing a PHP version: 8.1 or 8.2

Which version to upgrade to depends on two things: how long security support lasts, and how compatible your plugin ecosystem is. PHP 8.1 gets security support through the end of 2025, and PHP 8.2 through the end of 2026. For most standalone sites, 8.2 is the safer choice. It has the best performance and the longest security support. But if one of your key plugins explicitly says it only supports up to 8.1, upgrade to 8.1 first and move to 8.2 once the plugin updates.

Don’t skip versions. Going straight from 7.4 to 8.2 means jumping two major releases, and the deprecated functions and syntax changes pile up — the odds of something breaking are much higher than upgrading one version at a time. The right path is 7.4 → 8.0 → 8.1 → 8.2. Test each step on staging, and only move on once it’s clean.

Example: a content site runs just 5 plugins (Yoast, WP Rocket, WPForms, UpdraftPlus, Wordfence), and all of these mainstream plugins support PHP 8.2. In that case, upgrade to 8.2 on staging, test it, and push to production if it’s clean. But if the site runs WooCommerce plus a dozen ecommerce plugins, stay on 8.1 for now — when 8.2 first launched, plenty of payment and shipping plugins hadn’t caught up yet.

4. Installing extensions: OPcache and other essentials

If you upgrade PHP but skip OPcache, you only get half the performance gain. OPcache stores compiled PHP bytecode in memory, so the next time the same code runs it’s read straight from memory instead of being recompiled. With OPcache on, PHP execution time can drop by more than 50% — a bigger gain than going from 7.4 to 8.0.

Beyond OPcache, a standalone site needs a few basic extensions: mysqli (database connection, required by WordPress), gd or imagick (image processing, needed by the media library), intl (multilingual and localization), and mbstring (multibyte string handling, needed for Chinese sites). Most hosts enable these by default, but on shared hosting you may need to turn them on manually.

Key OPcache settings: set opcache.memory_consumption to 256 (MB) and opcache.revalidate_freq to 60 (seconds), meaning code changes are rechecked after 60 seconds. On a development environment, set revalidate_freq to 0 so every request recompiles; on production, set it to 60 seconds to balance performance and freshness. Set the PHP memory limit (memory_limit) to at least 256M, and 512M for sites with lots of plugins.

OPcache and page caching are two separate layers, so don’t mix them up. Page caching stores HTML as files, while OPcache keeps PHP bytecode in memory. You need both working together to get LCP as low as possible. For layered cache configuration, see Three-Layer Caching Strategy for Your Own Site. For performance benchmark targets, see Core Web Vitals Optimization.

5. Upgrade Steps and Rollback Plan

When upgrading PHP in production, always pick an off-peak window (2 to 4 AM Beijing time) and have a rollback plan ready in advance. If something goes wrong during the upgrade, you need to be back on the old version within 5 minutes. Never upgrade during the day, or problems will hit visitor access and inquiries.

Example scenario: you switch PHP from 7.4 to 8.1 in the BT Panel or cPanel, refresh the homepage, and get a white screen. Don’t panic. The first thing to do is switch back to 7.4. On most hosting panels, switching PHP versions is just one click, so you’re back in 10 seconds. Then check the error log to find which plugin is throwing the error, fix it, and try again. Don’t keep retrying while the white screen is up, or visitors will keep seeing an error page.

After upgrading, watch it for a week. Check two things: whether PHP Fatal Error shows up in the error log, and whether your Lighthouse score improves. If the error log is clean and LCP drops from 3.5 seconds to under 2 seconds, the upgrade worked. If new PHP warnings appear, first check whether they’re deprecated notices from a plugin. These warnings don’t affect functionality, but log them and deal with them at the next plugin update. In routine maintenance, checking the PHP version is a fixed item, see Six Monthly Tasks for Site Maintenance. For monitoring and alerts, see Site monitoring and alerts.

FAQ

Final thoughts

The biggest obstacle to upgrading PHP isn’t technical — it’s the psychological “I don’t dare touch it.” Plenty of teams have had sites running on 7.4 for three years, and it’s been “running fine” the whole time, until a plugin update causes a blank screen or the site gets hacked and they finally think about upgrading PHP. In reality, a PHP upgrade is the lowest-effort, highest-return optimization there is — you don’t need to change any business code, just click to switch versions in your hosting panel and spend an hour testing your core features.

Three steps to roll it out. Step one: back up your entire site and database, then run Compatibility Checker to scan your plugins and theme for compatibility issues. Step two: upgrade version by version in staging (7.4 to 8.0 to 8.1 to 8.2), testing your core user paths after each one. Step three: push to production during off-peak hours, watch it for 30 minutes, and roll back immediately if anything breaks. Do all three and your site runs twice as fast, with security patches applied too.

One line worth remembering: upgrading PHP is the best value performance move for a standalone store. Going from 7.4 to 8.2 makes it twice as fast, but only if you test compatibility first. One outdated plugin is all it takes to white-screen your site.