Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The fastest way to speed up WordPress on Apache is to improve the stack in layers: run supported PHP and database versions, force correct HTTPS redirects, serve cached HTML, cache static files in browsers, enable PHP OPcache, and add a reverse proxy or CDN when traffic justifies it. Only after those layers are healthy should you tune plugins, queries, and database content.
Apache is not inherently slow. A cache hit can return a ready-made page without invoking PHP or MySQL/MariaDB at all. Slow sites usually suffer from uncached dynamic requests, outdated runtimes, overloaded workers, inefficient queries, or assets that are delivered without compression and long-lived cache headers.
What actually makes WordPress on Apache slow?
A normal uncached WordPress request can pass through Apache, PHP, WordPress bootstrap code, dozens of plugins, the theme, and the database before HTML is sent. If every visitor repeats that work, response time and server load rise together. A cached request follows a much shorter path: Apache, a reverse proxy, or a CDN can return an already generated response.
Apache itself is the web server, not the entire performance profile. The practical questions are whether the server can use current PHP, whether mod_rewrite and HTTPS are configured correctly, whether page and browser caches are active, and whether PHP workers and the database have enough capacity. WordPress’s official guidance describes caching as its fastest performance improvement and says static-file caching can improve fairly static pages “several hundred times over.” That is an upper-scale description, not a universal benchmark; your result depends on the page, traffic, plugins, and hardware.
Start with a supported platform
Optimization cannot compensate for an obsolete runtime. WordPress recommends the following baseline:
| Layer | Recommended baseline | Why it matters |
|---|---|---|
| PHP | PHP 8.3 or newer | Supported releases receive security fixes and generally execute modern WordPress code more efficiently. Older releases may still run but are end-of-life and create security risk. |
| Database | MariaDB 10.11 or newer, or MySQL 8.0 or newer | Current database engines provide supported security updates and compatibility with current WordPress releases. |
| Transport | HTTPS | Many modern efficiency features and secure administration practices require HTTPS. |
| Web server | Apache with mod_rewrite |
WordPress uses rewrite rules for clean URLs, front-controller routing, and common redirect patterns. |
Check the actual versions in your hosting control panel or with the command-line tools available to your account. If you cannot select a supported PHP or database release, moving to a host that exposes those settings is usually more effective than micro-tuning Apache.
Measure before changing configuration
Take a baseline so you can tell whether each change helped. Record representative URLs rather than testing only the home page: an article, an archive, a search result, and a page with a form or other dynamic component.
- Time to first byte (TTFB): measure an uncached response and a cache hit separately.
- Total load time and Core Web Vitals: test on both desktop and a mobile connection.
- Cache status: note whether the response came from a browser cache, CDN, reverse proxy, file cache, or PHP.
- PHP worker usage: look for saturated workers, queueing, or requests terminated by a process limit.
- Database latency: identify slow queries and connection waits.
- Variants: test logged-out, logged-in, personalized, and deliberately uncached pages.
Change one layer at a time, purge only the caches affected by the change, and repeat the same tests. A faster cached home page does not prove that a logged-in dashboard or checkout flow is faster.
Put the site on HTTPS and fix redirects
Use one canonical HTTPS origin. WordPress documents Apache mod_rewrite patterns for forcing secure administration and redirecting HTTP requests. A typical site should avoid chains such as HTTP to a www HTTP URL, then to HTTPS, then to a different canonical host. Each extra hop delays the first request and can create confusing cache keys.
Before enabling a redirect, confirm that the certificate covers every hostname you intend to serve and that the WordPress Address and Site Address use the final HTTPS URL. Then test:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #2
- Used Book in Good Condition
- Request the HTTP version of the home page and confirm there is one permanent redirect to the final HTTPS URL.
- Request both www and non-www variants if both exist and verify that only one is canonical.
- Open
/wp-admin/, the login form, media URLs, feeds, and XML sitemaps over HTTPS. - Check that images, style sheets, scripts, and fonts do not load over HTTP, which would create mixed-content warnings.
Do not apply a generic rewrite snippet without adapting its hostnames and existing rules. A redirect loop can make the entire site unavailable.
Enable full-page caching first
Full-page caching stores the generated HTML for a URL. On a cache hit, Apache can serve that file without starting WordPress, PHP, or a database query. WordPress calls caching “the fastest way to improve performance.” Common WordPress page-cache choices include W3 Total Cache, WP Super Cache, and Cache Enabler; the correct choice is the one that works with your host, HTTPS setup, and logged-in or personalized features.
How to configure a page cache safely
- Install one page-cache system, not several competing page caches.
- Enable disk or server-backed page caching for logged-out visitors.
- Confirm that the cache writes files or objects and that Apache can read them efficiently.
- Set automatic purging when posts, pages, comments, menus, widgets, or theme settings change.
- Exclude login, administration, preview, cart, account, and other personalized URLs from caching.
- Open a page in a private browser window twice. The first request should generate the page; the second should show a cache hit in the plugin or response headers.
Do not cache a response that contains another visitor’s name, shopping-cart contents, security nonce, or account data. If a page mixes public HTML with personalized fragments, cache the public shell and load the private fragment separately.
What page caching does not cache
Page caching stores HTML, not the files referenced by that HTML. CSS, JavaScript, images, fonts, video, API responses, and third-party resources need their own delivery and cache policy. A site can have excellent HTML TTFB and still feel slow because a hero image is huge or a font is requested from a distant server.
Recommended Free Tools
Set browser cache headers for static files
After the first visit, browsers should reuse versioned static assets instead of downloading them on every page. Apache can send Cache-Control, Expires, and ETag headers through modules such as mod_expires and mod_headers.
A representative configuration is:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
</IfModule>
<IfModule mod_headers.c>
<FilesMatch ".(css|js|jpg|jpeg|png|gif|webp|svg|woff2)$">
Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
</IfModule>Use long lifetimes only when filenames or URLs change whenever file contents change, such as app.abc123.css. If a theme or plugin keeps the same filename after an update, visitors can retain stale code for the entire lifetime. In that case, use shorter lifetimes or add reliable version query strings and purge rules.
Rank #3
- Used Book in Good Condition
ETags can support conditional requests, but inconsistent ETags across multiple servers can cause unnecessary revalidation. If a CDN or reverse proxy is your authoritative cache, make its validation policy consistent with Apache rather than enabling conflicting rules in several layers.
Enable and size PHP OPcache
OPcache stores compiled PHP bytecode in memory. Without it, PHP repeatedly parses and compiles the same WordPress core, theme, and plugin files. WordPress states that adding an opcode cache such as OPcache can improve PHP performance by many times.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Configuration checklist
- Confirm OPcache is enabled for web requests, not only for command-line PHP.
- Review
opcache.memory_consumptionand increase available memory when the cache fills or repeatedly restarts. - Review
opcache.interned_strings_buffer, especially on sites with many plugins or large frameworks. - Choose a file-validation policy that detects deployments promptly. If validation is disabled for performance, explicitly reset OPcache after every code update.
- Watch hit rate, wasted memory, restarts, and eviction messages in the PHP or hosting telemetry.
Do not flush OPcache on every request. A reset briefly removes compiled scripts and can create a burst of compilation work. Reset it once after a controlled deployment, then verify that the new code is being served.
Choose the right caching layer for traffic
WordPress describes a typical order as browser cache, CDN, reverse-proxy full-page cache, and finally a file-based page cache. Each layer can prevent work in the layer below it.
| Layer | Cache-hit path | Best use | Important limits |
|---|---|---|---|
| File-based WordPress page cache | Apache serves generated HTML from local storage. | Small and medium sites that need a straightforward improvement without separate infrastructure. | Still depends on the Apache server and local disk; purge rules must track content changes. |
| Reverse proxy | A proxy such as Varnish or NGINX returns HTML before Apache, PHP, and the database. | Busy public sites where avoiding application work is worth additional operations. | Cookie, query-string, purge, and HTTPS rules require careful configuration. |
| CDN | An edge location serves cached content near the visitor. | Geographically distributed audiences and traffic spikes. | Invalidation can be delayed or costly; dynamic and personalized responses need explicit bypass rules. |
Reverse proxy and CDN decision points
- Latency: an edge hit is usually closest to the visitor; a reverse-proxy hit is usually close to the origin; a file-cache hit still reaches Apache.
- Purge control: verify whether you can purge one URL, a tag, a path, or the entire cache after a post update.
- Personalization: confirm how cookies, authorization headers, query strings, and logged-in sessions affect cache keys.
- Failure behavior: determine whether a stale object can be served during an origin outage and how uncached requests fail.
- HTTPS: decide whether TLS terminates at the CDN or proxy and ensure Apache receives trustworthy forwarded-protocol information.
- Complexity: every additional layer adds configuration, monitoring, and another place where stale or private content can be exposed.
Start with one cache layer that you can observe and purge. Add a proxy or CDN when origin CPU, PHP workers, geographic distance, or traffic bursts justify it—not simply because another layer exists.
Compress responses and optimize assets
Enable server or plugin compression for text responses such as HTML, CSS, JavaScript, JSON, SVG, and XML. Apache commonly uses Brotli or gzip modules. Do not compress already compressed formats such as JPEG, PNG, WebP, WOFF2, or video; doing so consumes CPU without materially reducing size.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchMinify CSS and JavaScript when the build or plugin can do so safely. Test menus, forms, analytics, checkout scripts, and administrative screens after minification. Remove unused assets where practical, but do not blindly concatenate every file. HTTP/2 and HTTP/3 multiplex many requests over one connection, so old HTTP/1 pipelining, domain-sharding, and “combine everything” recipes are not automatically beneficial.
Compress and resize images before upload, use modern formats where browser support and image quality permit, and provide dimensions so the browser can reserve layout space. Image optimization often improves perceived speed more than another small Apache directive.
Tune WordPress after the delivery stack is healthy
Reduce expensive plugin and theme work
- Remove plugins that duplicate features or execute on every request without being needed.
- Inspect plugins that perform remote API calls, build large admin queries, or add scripts site-wide.
- Load a plugin’s assets only on the pages that use its feature.
- Keep the theme and plugins updated, and replace abandoned components that cannot run on supported PHP.
Control database overhead
Clean revisions, expired transients, orphaned metadata, and other clutter only after confirming what can safely be removed. Do not delete data blindly: backups, scheduled tasks, multilingual plugins, and ecommerce extensions may rely on records that look unused. Use query logging or a profiling tool to find slow queries instead of optimizing tables by guesswork.
Find cache bypasses
Look for cookies or query strings that force every request to miss the page cache. Search, previews, REST endpoints, feeds, comment submissions, and personalized widgets are often intentionally dynamic. Keep them dynamic where necessary, but prevent them from making unrelated public pages dynamic.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsEvaluate an Apache WordPress host
When comparing hosting plans, ask for technical details rather than a generic “optimized WordPress” label.
| Capability | Questions to ask |
|---|---|
| Runtime | Can you select PHP 8.3 or newer and the recommended MariaDB or MySQL version? |
| OPcache | Is OPcache enabled for web requests, and can its memory and interned-string settings be inspected or adjusted? |
| Apache access | Are mod_rewrite, compression modules, custom headers, and per-directory rules available? |
| Protocols | Does the plan support HTTPS, HTTP/2, and HTTP/3 where appropriate? |
| Resources | What CPU, memory, PHP-worker, entry-process, storage, and database limits apply? |
| Caching | Is page caching, a reverse proxy, or a CDN included, and can you purge individual URLs? |
| Operations | Are backups, staging, logs, cache diagnostics, and rollback procedures provided? |
A plan that includes a CDN but hides PHP-worker limits may perform poorly on cache misses. Conversely, a powerful origin without a usable purge mechanism can serve stale content. Match the infrastructure to your ratio of public cached traffic, logged-in traffic, geographic distribution, and deployment frequency.
Best Value
Implementation order and verification checklist
- Record baseline TTFB, load time, cache status, worker use, database latency, and Core Web Vitals.
- Upgrade PHP and the database to supported versions, then test the site and extensions.
- Enable HTTPS and simplify redirects to one canonical URL.
- Enable one full-page cache and configure safe exclusions and automatic purging.
- Enable browser cache headers for versioned static assets.
- Enable and size OPcache; reset it once after deployment when required.
- Add compression and image optimization, then test functionality after minification.
- Consider a reverse proxy or CDN if origin load or visitor geography warrants it.
- Profile plugins, queries, database clutter, and cache bypasses.
- Retest logged-out, logged-in, personalized, and uncached paths after every significant change.
Troubleshooting common failures
Visitors see old CSS or JavaScript
The asset likely has a long browser lifetime but an unchanged filename. Version the URL when the file changes, purge the page and edge caches, and test in a private window. Do not solve the problem by disabling all caching permanently.
Pages show another user’s data
Stop the affected cache immediately, purge exposed objects, and inspect cookies, authorization headers, and cache-key rules. Exclude the response from every page-cache layer until the personalized portion is separated from public HTML.
The cache never records a hit
Check whether cookies, query strings, redirect chains, response headers, or a cache-bypass rule are forcing misses. Verify that Apache can write and read the cache directory and that the application is not sending private or no-cache headers on public pages.
PHP is still slow after page caching
Measure a true cache miss and logged-in requests. Confirm OPcache is active for web PHP, inspect worker saturation, and profile slow plugins and database queries. A page cache cannot accelerate requests that must execute WordPress.
Enabling a proxy causes loops or broken HTTPS
Ensure the proxy forwards the original protocol correctly, Apache trusts only the intended proxy, and WordPress’s canonical URL matches HTTPS. Remove duplicate redirect rules and test direct-origin and proxied requests separately.
Does Apache make WordPress slow?
No. An Apache WordPress site can be fast when its runtime is supported, public pages are cached, static assets have sensible headers, PHP bytecode is cached, and dynamic work is measured and controlled. The durable approach is layered: make the common request cheap, keep private requests correct, and use measurements to decide which remaining bottleneck deserves attention.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
