Host the website as close as practical to its main audience. Lower network latency reduces the time required for requests to travel between visitors and the origin server.

• Aim for latency below roughly 100 ms where practical.
• For local businesses, a nearby regional data center is usually preferable.
• A CDN helps static delivery but does not completely compensate for a distant origin server.
• Consider provider support hours and timezone as well as physical location.

Select a hosting model that matches the website’s traffic, workload, and administration requirements.

• Shared hosting — suitable for small, low-traffic websites but offers limited server control and shared resources.
• VPS / cloud hosting — provides more dedicated resources, flexibility, and configuration control.
• Dedicated server — appropriate for very large or consistently high-traffic workloads.

Moving from an overloaded shared environment to a properly sized VPS or managed cloud environment can improve speed without changing the WordPress application itself.

Use a modern, high-performance web server and keep it updated.

• NGINX — efficient for many standard WordPress workloads.
• LiteSpeed — provides WordPress-focused features and integrates with LiteSpeed Cache.
• OpenLiteSpeed — community alternative for users who want LiteSpeed-style functionality.
• Apache — can perform well when carefully optimized, but may require more tuning.

Default settings are usually safe for smaller sites, but high-traffic or demanding applications can benefit from workload-specific tuning.

• Keep request timeouts reasonably low unless long imports, exports, or backups require more time.
• Adjust child-process limits according to available CPU and memory.
• Set concurrent-connection limits based on real traffic rather than assuming a higher number is always better.
• Monitor the server after every configuration change.

Remove unnecessary background services so they do not consume memory, CPU, network resources, or increase the server’s attack surface.

• Disable local DNS if an external DNS provider is used.
• Disable local email services when mail is handled by a third-party provider.
• Disable FTP/SFTP services that are not required.
• Disable Redis, Memcached, Varnish, search services, or other components that are installed but unused.

Advanced users can also disable web-server or operating-system modules that are not needed. Document every change and verify dependencies before removing a module, because disabling the wrong component can break the application or reduce performance.

Newer supported PHP releases generally provide better performance and security than obsolete versions. Use the newest PHP version that is compatible with the active WordPress version, theme, and plugins.

Always test compatibility before upgrading production websites.

• max_execution_time — keep reasonably low for normal requests and raise only when long-running operations require it.
• max_input_time — keep conservative unless large imports need additional processing time.
• max_input_vars — increase only when themes or plugins genuinely require more variables.
• memory_limit — allocate enough memory for the application while still allowing resource problems to be detected.
• zlib.output_compression — review in relation to the compression already handled by the web server or CDN.

Use a maintained MySQL, MariaDB, or compatible database release rather than an obsolete version. Keep backups before changing or upgrading the database engine.

For most modern WordPress workloads, use InnoDB tables. It generally provides better reliability, transaction support, concurrency, and overall suitability for dynamic applications.

Large, busy sites may benefit from tuning buffers, cache settings, connection limits, packet sizes, and other database parameters.

Server-level full-page caching can serve previously generated pages without repeatedly executing the entire PHP and database request path.

• LiteSpeed can use LiteSpeed Cache.
• NGINX can use FastCGI caching.
• Exclude dynamic pages such as carts, checkouts, forms, and other user-specific content unless private caching is configured correctly.

Object caching stores database-query results rather than complete pages. It is especially useful for dynamic pages, logged-in users, and administration screens that cannot always use full-page caching.

• Redis is commonly used for persistent object caching.
• Choose cache expiration periods according to how frequently the data changes.
• Unix sockets can reduce local communication overhead in suitable single-user server configurations.

Use HTTP/2 or HTTP/3 rather than older HTTP/1.x configurations. Modern protocols improve how browsers transfer multiple page resources and normally operate together with HTTPS.

Compress HTML, CSS, JavaScript, and other compressible assets before sending them to visitors.

• Prefer Brotli when supported by the server and clients.
• GZIP remains a compatible fallback.
• If a CDN is used, verify that compression is enabled there as well.

A control panel should simplify administration without forcing an inefficient server stack. Prefer one that supports the required web server, redirects, caching rules, security controls, user isolation, and straightforward day-to-day management.

A dedicated DNS provider can reduce lookup latency in some environments and, more importantly, make DNS changes, failover, migrations, and integration with external services easier to manage.

WordPress normally checks scheduled tasks when visitors load pages. On high-traffic websites this can create unnecessary repeated cron checks. Disable the default visitor-triggered WP-Cron behavior and use a real server cron job or external scheduler at a suitable interval.

On servers hosting multiple WordPress sites, one account or process can affect every other website. Use resource limits and monitoring to identify and isolate problematic workloads.

• Limit CPU and memory for individual users or tenants where supported.
• Restrict known resource-intensive background processes when necessary.
• Review server access and error logs for excessive or malicious requests.
• Monitor CPU, memory, bandwidth, and process usage.
• Use WordPress error logs and query-analysis tools after identifying the affected website.
• Check recently updated or custom-developed plugins and themes when slowdowns begin unexpectedly.