Many website owners immediately open Lighthouse when a page feels slow, then focus on reducing image sizes, removing plugins, or deferring JavaScript loading. These steps can help, but they do not always address the root cause of the problem.
If the server takes too long to prepare the first response, the browser hasn't even had a chance to display images or run JavaScript. In such cases, frontend optimization is like tidying up the living room while the front door is still locked.
Therefore, performance checks should start from the earliest point: how long does it take to process user requests before the first HTML is sent?
Identify the parts of the website that often become bottlenecks
When a user opens a page, the request typically goes through several stages: connecting to the server, web server processing, PHP or backend application, database queries, fetching data from cache, and then sending the response to the browser.
Issues at any of these stages can worsen metrics like Largest Contentful Paint or LCP. LCP measures when the largest visible content element on the screen is fully displayed. A common target is 2.5 seconds or faster for at least 75 percent of visits. However, LCP numbers are not only affected by large images. Server wait time or Time to First Byte also plays a role.
That's why a low PageSpeed score does not automatically mean all problems lie in CSS and JavaScript. Lab data helps identify patterns, but real user data can show different conditions because each visitor's device, network, location, and interaction patterns vary.
First step: distinguish between server issues and browser issues
Use a simple check before making major changes.
- Check TTFB. If the time to the first byte is already high, the initial focus should be on the server, backend, database, or HTML cache.
- Check asset size and load time. If TTFB is low but the page is still slow, images, fonts, CSS, or JavaScript are likely more dominant.
- Compare static and dynamic pages. Create a simple HTML file on the server. If that file is fast but the CMS page is slow, the problem likely lies in the application or database.
- Test the page in cached and non-cached conditions. A significant difference indicates that the cache is not working optimally or the backend process is too heavy.
This testing does not replace complete observability, but it is enough to prevent us from guessing. Good performance changes usually start from measurements, not from a random list of tips.
Cache is not just an “enable” button
Cache stores results of processes that can be reused so the server does not have to repeat the same work. For public pages, HTML cache can reduce PHP processing and database queries on each visit. For static assets like CSS, JavaScript, and images, both the browser and CDN can store them longer.
However, overly aggressive caching also risks displaying outdated content. Conversely, overly strict rules cause every request to return to the server, diminishing the benefits of caching.
Use different patterns according to the type of content:
- Assets with versioned file names, such as
app.abc123.js, are usually safe to have a long cache duration. - Public pages that rarely change can use CDN or reverse proxy caching with measurable TTL.
- Account pages, shopping carts, and dashboards should not be shared via public cache as they contain personal data.
- Responses that use cookies or load user data need to be carefully checked before being passed to the CDN.
The Cache-Control header helps clarify whether a response can be stored, how long it can be used, and when it should be revalidated. Do not rely solely on the default settings of the CDN provider; also check the headers that are actually sent by the server.
PHP-FPM: don’t just increase the number of workers
On PHP-based websites, PHP-FPM is responsible for managing processes that run PHP code. One common mistake is to immediately increase the pm.max_children value when the website starts to slow down.
Adding workers can help if the request queue is too long. However, each worker requires memory. If the number is too high, the server may run out of RAM and start using swap. The end result is actually slower, and it can even cause processes to be terminated by the system.
Check the following:
- Are PHP-FPM workers frequently reaching their maximum limit?
- Are there processes running too long?
- What is the average memory usage per worker?
- Do the logs show timeouts, database connection errors, or requests piling up?
The ideal configuration depends on RAM, application type, code size, and traffic patterns. So, do not copy configurations from other servers without first measuring memory consumption and queue lengths.
Slow databases often appear as slow websites
Pages that require data from MySQL can be held up even if the web server and network are functioning normally. Queries without indexes, fetching too many rows, sorting large data sets, or too many small queries on one page are common causes.
Start with the most frequently called or longest-running queries. Use EXPLAIN to see how MySQL plans to execute the query. Check if indexes are used, how many rows are scanned, and whether the database creates temporary tables for sorting or grouping.
Do not add indexes blindly. Indexes can speed up reads but also add costs when data is written or updated. Healthier improvements usually involve a combination of more specific queries, appropriate indexes, pagination, and caching for data that does not change often.
What can you do now?
For an initial audit, select one important page—such as the homepage, product page, or most popular article—and note three things: TTFB, page size, and the slowest queries or backend processes.
After that, make changes one by one. Enable caching for static assets, ensure cache headers are correct, measure PHP-FPM queues, and check for slow queries. Only after the server side is healthy enough, proceed to images, fonts, JavaScript, and layout.
This order is important because performance optimization is not a race for a perfect score. The goal is to ensure users receive content quickly, pages respond consistently to interactions, and the server remains stable when traffic increases.
In summary: before reducing image sizes or installing new optimization plugins, ensure the server is not holding up every request. Fast websites are usually not the result of a single trick, but rather from a measured and improved processing path from end to end.
Sources & further reading
- Web Vitals — web.dev
- Why lab and field data can be different — web.dev
- Origin Cache Control — Cloudflare Developers
- PHP-FPM Configuration — PHP Manual
- MySQL 8.4 Optimization Reference Manual
– Rio Yotto @rioyotto