Website loading speed: how to find the cause and improve key pages

Website loading speed belongs to a page and a device

Website loading speed is not one number for a home page. A visitor may wait for a service page, a catalogue filter or a form, and each journey uses different images, scripts and server responses. Select three to five pages that can lead to a real business action, then record the device, network profile, location and date for every test.

Laboratory tests reproduce a page in controlled conditions; field data describes the experience of actual visitors. They answer different questions. A laboratory run is useful when accepting a defined change, but one favourable run does not prove the same experience for every visitor.

A delay usually has a chain of causes

Break a load into server response, HTML, critical styles, first-screen images, fonts and JavaScript. A slow largest element can come from the server, an oversized image, a blocking script or a component that appears only after code runs. Fixing every warning is wasteful; first identify the observable cause on the actual URL.

Check layout stability separately. A banner, font or image that changes size after appearing can move a button while a visitor is about to use it. Preserve the before state, resource size and browser-network path for each issue so a developer can reproduce the change.

Server response

The time before the browser receives the first byte of HTML.

First screen

The content visible before scrolling, which forms the first page impression.

Layout shift

A movement of already visible elements during loading.

Choose fixes by user impact

Start with repeated causes: images with no fixed dimensions, a heavy widget on every page, a font blocking the first screen, or a template making unnecessary requests. Then move to individual pages. Saving bytes on a page with no traffic can look good in a report without improving the route to an enquiry.

Do not replace useful content with an empty placeholder to make a score look better. A first screen still needs the offer, price or calculation method, proof and next step. Good optimisation removes waiting without making the page incomplete.

• Set real image dimensions and defer media below the first screen.
• Move scripts that are not needed for the visitor’s first action.
• Check caching, compression and stable server response.
• Compare the same URL before and after on a mobile profile.

Accept faster loading with the same test, not a promised score

Agree the method before work starts: for example, a service page on a mobile profile, no shift of the main action and a working form. After release, repeat that test, walk through the user journey and confirm that analytics, the form and essential content still work.

On eco-santeh.ru, KILENI’s mobile laboratory Performance on the home page changed from 36 to 57 and the desktop result reached 99. These numbers belong to one URL and test conditions, not a forecast for another domain. The useful standard is a result with a sample, method and limitation.

Keep the test link, date, device profile and the released change list. A score improvement is not accepted if form submission, pricing or navigation stops working. This record makes the follow-up check fast and gives the team a reliable explanation of what changed. Compare the request count, page weight and path to the intended action too, because they reveal a regression before the monthly report.