All products 
What hosting WordPress needs: the specs worth checking
WordPress will install on almost any shared hosting with PHP and MySQL, but it won't run fast and reliably everywhere. The difference between plans doesn't show on installation day but six months later, when the site has twenty plugins, thousands of posts and a crawler visiting on a regular basis. Below is what to check in advance so you don't have to switch your WordPress hosting the first time traffic grows.
PHP and the database
- PHP version. Current WordPress releases are built for PHP 8.x, and the site runs noticeably faster on it than on 7.4. It helps if the panel lets you choose the version per site and roll back if an old plugin turns out to be incompatible with the new one.
- Extensions. At a minimum you need mysqli, curl, gd or imagick, mbstring, xml, zip and intl. Imagick handles images better, and without zip updates and many backup plugins don't work.
- MySQL or MariaDB. MySQL 8 and MariaDB 10.6 or newer are fine. Check the database size limit: options, revisions and plugin log tables grow faster than you'd expect.
- memory_limit. 128 MB is enough for a simple blog; for a site with a page builder, multilingual setup or a store, 256 MB or more is better. Make sure the PHP limit doesn't exceed the account's memory, otherwise the setting exists only on paper.
- max_execution_time and upload_max_filesize. These determine whether an import finishes in time and whether a theme or video file can be uploaded through the dashboard.
Caching: the main thing that speeds up WordPress
Every uncached WordPress page means starting PHP and running dozens of database queries. So a site's speed on shared hosting depends above all on which caching layers are available:
- OPcache keeps compiled PHP code in memory. It's usually on by default, but it's worth confirming via the Site Health screen or phpinfo.
- Page cache serves ready-made HTML without running PHP. On LiteSpeed servers the LiteSpeed Cache plugin does this at the web server level; on Apache and nginx, plugins save pages as files.
- Object cache (Redis or Memcached) stores the results of database queries. It's especially useful for the dashboard, sites with logged-in users and WooCommerce. Many shared plans don't offer it, so having it is a real plus.
A fast disk helps too, mainly in the dashboard and on heavy database queries — more on that on the NVMe hosting page.
Backups, SSL and a staging copy
The host makes backups, but you shouldn't rely on them alone. Find out how often they're created, how many days they're kept and whether you can restore files or the database separately without contacting support. Making your own weekly copy to external storage is worth it in any case.
A free Let's Encrypt certificate with auto-renewal is now standard. After enabling HTTPS, check that the site address in WordPress settings uses https and that old image links don't trigger mixed-content warnings.
Staging — a test copy of the site on a subdomain — lets you update the theme, core and major plugins without touching the live site. WordPress Toolkit in Plesk and cPanel, Softaculous and some hosts' own panels can create one. You can compare panels in the cPanel hosting selection.
Plugins and load
Most WordPress speed problems on shared hosting are caused not by the host or the disk but by plugins. Typical culprits:
- statistics and security plugins that write to the database on every visit;
- the built-in WP-Cron, which runs tasks on every page view — better to replace it with a system cron job in the panel;
- page builders with heavy scripts and dozens of stylesheets;
- frequent admin-ajax and Heartbeat API requests from open dashboard tabs;
- a bloated wp_options table full of autoloaded data from deleted plugins.
Look at the resource stats in your panel: if the site hits its CPU or process limit on an ordinary day without a traffic spike, sort out the plugins first and only then change plans.
When to move WordPress to a VPS
Shared hosting suits blogs, company sites and small catalogs. A move is justified if:
- after optimization and caching the site still regularly gets 503 or 508 errors;
- you need Redis, Elasticsearch, background queues or your own nginx configuration, and the host doesn't provide them;
- the site has many logged-in users, for whom page caching doesn't work;
- the top shared plan costs almost as much as a VPS with dedicated resources.
Server configurations for this CMS are collected in the VPS for WordPress selection.