Many website owners feel they have optimized their site after installing a caching plugin or enabling a CDN. However, pages still feel slow, especially during login, when opening search pages, or accessing the dashboard. This is not unusual: cache only speeds up certain parts of the process, not the entire request path.
To find the cause, we need to view the website as a series of stages: the browser requests a page, DNS and connections are processed, the server runs PHP, the application reads the database, and then the results are sent and rendered by the browser. A slow stage can cause the entire experience to lag.
Cache does not always work on all pages
Page caching is most effective for public content that is the same for many visitors, such as articles, category pages, or landing pages. Conversely, checkout pages, user accounts, dashboards, and pages that use specific cookies usually need to go through the application to keep the data personal and up-to-date.
In Nginx, for example, fastcgi_cache can store responses from PHP-FPM. However, the cache configuration also determines when a request can take an old result, when it must bypass the cache, and how long the response is stored. Headers like Set-Cookie, Cache-Control, and Vary can also affect whether a response is considered cacheable.
This means that the statement “cache active” is not enough as a diagnosis. Check the actual response using browser DevTools or commands like:
curl -I https://example.com/pageLook for headers like Age, X-Cache, or custom headers from your CDN and server. Header names vary, but the goal is the same: to ensure whether the request actually received a cached result or is still calling PHP.
Differentiate between slowness before and after the server responds
One of the most useful checks is to look at the wait time before the first byte is received. This time is often referred to as Time to First Byte or TTFB. If TTFB is high, attention should be directed to the network, CDN, web server, PHP-FPM, application code, or database.
If the first byte arrives quickly but the page still takes a long time to finish loading, the issue is likely with the size of the HTML, images, JavaScript, fonts, or the rendering process in the browser. These two conditions require different approaches. Adding server RAM does not automatically fix heavy JavaScript, just as reducing image sizes does not resolve database queries that take several seconds.
PageSpeed Insights should also be read in context. The report combines field data from real users and lab data from Lighthouse. Lab data is useful for testing changes in a controlled manner, while field data shows user experience under various device and network conditions. The values can indeed differ.
Don't just chase scores: understand Core Web Vitals
Core Web Vitals currently include LCP, CLS, and INP. LCP measures when the main content is visible, CLS measures unexpected layout shifts, while INP assesses how quickly the page responds to user interactions like clicks, taps, or input.
For example, a page may have good LCP but poor INP. Visitors see the main page quickly, but the menu or filter buttons respond only after a long delay because JavaScript is handling too many tasks. In such cases, optimizing images alone will not solve the problem.
To find the source, open the Performance panel in Chrome DevTools and check for long tasks, which are JavaScript jobs that block the main thread for too long. Also, check the LCP elements and see if the cause is large images, fonts that load late, or HTML responses that are not ready.
PHP-FPM and OPcache: two often-overlooked layers
On PHP websites, each dynamic request can involve loading files, executing frameworks or CMS, calling plugins, and accessing the database. PHP-FPM helps manage PHP processes, but too few workers can cause requests to queue. Conversely, too many workers can consume RAM and trigger swapping or process termination by the operating system.
Check metrics such as the number of active processes, waiting requests, execution time, and memory usage. Do not increase the number of workers without looking at RAM capacity. Configurations that appear aggressive on large servers can make smaller servers even more unstable.
OPcache is also important because it stores the results of PHP bytecode compilation, so PHP files do not need to be recompiled on every request. Ensure OPcache is active for web processes, not just for PHP commands in the terminal. If its memory capacity is too small, the cache can fill up frequently, reducing its benefits.
Slow databases often appear as slow servers
Pages waiting for database queries will seem like a hosting issue, while the root cause may lie in SQL. Queries with filters, sorting, or joins without the appropriate indexes can force the database to check too many rows.
Use EXPLAIN on suspected queries:
EXPLAIN SELECT id, title
FROM posts
WHERE status = 'publish'
ORDER BY published_at DESC
LIMIT 20;Note whether the database is performing a full table scan, how many rows are estimated to be read, and which indexes are used. Indexes can speed up searches, but that does not mean every column should be indexed. Too many indexes increase space usage and make insert, update, and delete processes heavier.
In CMS applications, also check for queries that run repeatedly. Analytics plugins, search functions, related posts, and dynamic widgets often add load without being clearly visible from the front end.
What you can do now
- Test public and dynamic pages separately. Compare article pages, search pages, login pages, and dashboards.
- Check response headers. Ensure that pages that should be cached are actually generating cache hits.
- Note TTFB and total time. This helps distinguish backend issues from frontend asset issues.
- Audit PHP-FPM and OPcache. Look for worker queues, RAM usage, and full opcode caches.
- Capture slow queries. Use application logs or slow query logs, then analyze with
EXPLAIN. - Test one change at a time. Do not enable five optimization plugins at once, as you will find it difficult to determine which change actually helps.
What does this mean for us?
A fast website is not the result of one button, one plugin, or one server upgrade. Performance is the result of several interconnected layers. Cache helps, CDN helps, OPcache helps, and database indexes help—but their benefits are only felt when applied to the right issues.
Start with simple measurements: which pages are slow, when the slowness occurs, and which stages take the most time. After that, change one thing, measure again, and document the results. This approach is usually safer and more effective than randomly adding optimizations.
Sources & further reading
- Web Vitals — web.dev
- About PageSpeed Insights — Google for Developers
- Module ngx_http_fastcgi_module — Nginx
- PHP: OPcache Configuration — PHP Manual
- MySQL 8.4 Reference Manual: Optimization and Indexes
- Resource Timing — MDN Web Docs
– Rio Yotto @rioyotto