“The site is slow” can mean a long wait for the first response, a late hero image, a delayed button or slow search. These problems need different fixes. Start with a repeatable scenario and separate server work from browser work. This guide helps you collect baseline measurements, choose the next diagnostic step and accept a performance improvement by its outcome rather than a claim that “caching was added”.
Describe the delay so someone can reproduce it
Choose one page and one action. Record the URL, device, browser, connection type, login state and test time. Be specific: does the page stay white, does text appear without the image, does the menu fail to respond or do search results arrive late? A short scenario recording can be more useful than a screenshot of a performance score.
For a catalogue, include the home page, a typical category, a product with variants and search. For a service site, include the home page, a service, an article and an enquiry form. Do not test only the lightest page. If a wholesale customer has the problem, testing the guest view does not replace testing their scenario, although both matter.
Repeat each selected scenario several times under identical conditions. Mark first and repeat visits, and cold and warm caches, separately. Do not average them into one number without explanation. One fast run does not disprove a problem; one slow run does not prove a persistent fault.
Step 1. Separate server waiting from rendering
Open Network in the browser’s developer tools and inspect the main HTML document request. How long did connection, response waiting and download take? Then inspect images, fonts and scripts needed for the first screen. Handle exported network logs carefully: they may contain cookies, tokens, parameters and personal data.
TTFB is the time to the first response byte. It includes network components as well as PHP execution; a high value alone does not prove a slow database. The official web.dev TTFB guide explains its effect on subsequent loading. If HTML arrives quickly but a large element appears late, buying a new server before examining resources is premature.
| Observation | First area to investigate | Does not prove |
|---|---|---|
| Long wait for HTML | Network, server, application | That PHP alone is responsible |
| Fast HTML, late first screen | Images, CSS, fonts | That new hosting is needed |
| Delayed button response | Scripts and event handlers | That HTML caching will help |
If only a particular action is slow, find its request separately. Search may contact the server after typing, a filter may rebuild the catalogue and a basket may recalculate prices. Main-document speed does not describe these operations. Record both response time and when the interface actually becomes ready for the next action.
Step 2. Understand the metrics you measure
The current Core Web Vitals are LCP, INP and CLS. According to web.dev documentation, good values are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1; assessment uses the 75th percentile of visits, separately for mobile and desktop. Criteria checked on 22 October 2026.
- LCP measures when the largest visible element appears. It is not always an image: it may be a text block.
- INP describes interaction responsiveness. A page may load quickly and then take too long to react to its menu or filter.
- CLS describes unexpected layout shifts. A fast site is still awkward if a button moves while a banner loads.
Distinguish laboratory tests from real-user data. A laboratory run is useful for reproducing and comparing changes under specified conditions. Field data describes your audience’s experience but need not update immediately after a fix is published. A low-traffic page may have no separate data: that is neither zero nor proof of perfect speed.
Do not replace performance with one coloured score. Record the metric itself, page, device and measurement source. A better score with a still-slow form does not finish the task. Good metrics do not guarantee rankings or sales growth either: they are one aspect of user experience.
Step 3. If the delay precedes the first response
Ask a developer or administrator to correlate the slow request with server load: CPU, memory, disk operations, database connections and background jobs. Values from the same moment matter, rather than a quiet-server screenshot an hour later. Establish whether the whole site or only one component is slow.
Check import, backup and indexing schedules. Heavy jobs overlapping with busy periods or each other may indicate a load-management problem. Do not cancel backups for speed: move them to an agreed window and check resources. Every background process should have a clear purpose.
The next level is database-query duration and component execution. Use monitoring available in that installation and limited profiling. An unplanned heavy load test against a live store can itself create an incident. Begin with observation, reproduction on a copy and measurement of the bottleneck.
Caching must account for dependencies and user context. Recalculating an identical list may be unnecessary; serving a personal price from a shared cached page is unsafe. Check correctness as well as speed for guests and different test users.
Step 4. If the response is fast but the first screen is slow
Identify the actual LCP element in the measurement. If it is an image, compare its pixel dimensions with its displayed size and file weight. Mobile pages often load the same large file as wide screens. Prepare suitable variants and check which resource the browser chooses; do not judge by the filename alone.
Compress images while visually checking text, faces and product details. Set dimensions or an aspect ratio to reserve space before loading. Do not defer the main visible image in the same way as images far below the first screen. Loading policy depends on the element’s position and role, not just its file format.
Check fonts and styles: how many weights are actually used, and are there unnecessary external dependency chains? For scripts, establish what is needed immediately and what can load later. Removing code without checking can break consent, forms, analytics or payment. First list dependencies and the people responsible for each function.
Measure external widgets separately: chat, maps, video, reviews and analytics can affect loading and interactions. Compare with a temporarily disabled widget on a test copy or in a controlled experiment. This establishes its contribution; it is not a recommendation to permanently remove a useful business tool.
Training example: more server power does not fix a late image
Suppose five identical mobile laboratory runs receive the main HTML in roughly 0.4 seconds, while the large first-screen image appears after about 5 seconds. The network log shows a heavy original file and a late download start. These are invented training values, not SignM or client audit results.
Hypothesis: image delivery contributes most of the delay, rather than HTML generation. On a copy, change only the image variants and their loading order, then repeat the same measurements. Compare the median of several runs, their spread and visual quality. If LCP improves, also check mobile and desktop versions, then real visits after publication.
If the image becomes fast but the menu still freezes, responsiveness is a separate task. Do not declare the entire site accelerated from one metric. Record the remaining issue and next test. The report then shows a causal connection rather than a list of actions with unclear effects.
What composite mode does and what it cannot replace
Bitrix composite technology separates a cached static part of the page from dynamic areas. It can reduce waiting for suitable public pages but needs correct configuration. A mode appearing in the administration panel does not prove that a particular URL is served in the intended way.
After enabling it, check repeated guest requests, the first request after a change and content freshness. Test the basket, login, personal prices, forms and user messages separately. Shared caching must not expose one visitor’s data to another. A dynamic area must refresh correctly and have defined failure behaviour.
Composite mode does not automatically shrink photographs, fix heavy JavaScript or accelerate every dynamic operation. If an exchange locks the database or search performs an expensive query, investigate those causes separately. Do not promise a multiple-fold speed gain without measuring specific pages under stated conditions.
Implement changes and accept the result
- Record baseline scenarios, metrics, conditions and versions.
- Choose one testable hypothesis and its expected effect.
- Save previous files and settings; define how to restore them.
- Change one limited area on a copy and repeat the measurement.
- Check forms, navigation, prices, permissions and mobile display.
- Deploy the verified change and measure the live site under comparable conditions.
- Monitor errors, data freshness and available field metrics.
Do not clear all caches before every control measurement without noting it: you would be comparing different operating states. Do not publish a “before” on a slow mobile network and an “after” on a fast desktop connection. If you need to understand each contribution, do not combine a server move, template rewrite and replacement of every image in one step.
Rollback usually requires the previous versions of changed files and settings. Data-structure or infrastructure changes need a broader agreed plan. Repeat functional checks after restoration: recovering the previous speed at the cost of a broken form is not successful recovery.
When you do not need a new server or acceleration module
Do not buy capacity before confirming a resource shortage. Do not add a second caching module before understanding the existing cache and its exclusions. Do not rewrite the entire site for one heavy block. Sometimes an image size, repeated component query or job schedule is enough; sometimes measurements genuinely justify an infrastructure change.
A cold cache has not yet stored the required result; a warm cache has. A request waterfall shows the resource-loading sequence; a bottleneck limits the whole scenario. Keep the baseline, hypothesis, change and retest result in your worksheet. That document helps assess a Bitrix performance proposal and accept the work without relying on a promised score.
Apply this to your own project
Collect reproducible measurements, separate server waiting from browser problems, test one hypothesis and accept the speed gain alongside preserved functionality.
Website performance diagnosis and acceptance log: open the worksheet · Download the CSV to complete. Free access, no registration. Use it independently or pass it to your contractor.