How to check and improve website loading speed - Zephyra Studio

Site speed is checked in two layers: data from real visitors and a laboratory test. The first shows how the site behaves on phones under real conditions, and it is what Google uses for Core Web Vitals. The second is for diagnosis, because it shows what exactly is slowing the page down. Measurement happens on the same page and the same device before and after a change, because otherwise there is no telling what helped. Most of the gain usually comes from caching, images and the number of scripts, and the order of fixes follows whatever the data shows as the biggest problem rather than whatever is easiest to do.

Where to measure and what to look at

Field data comes from real visitors and is what Google uses. In PageSpeed Insights it appears at the top, and if a page has too little data for a conclusion, that means it gets too few visits to judge.

The laboratory test is a simulation on a fixed connection and exists for diagnosis. It shows the order in which resources load and what each one costs, but it does not tell you how the site behaves on someone else's phone on a weak connection.

For a deeper analysis, use a tool that can test from different locations and devices and shows a loading timeline. On sites with many pages, test three to five key ones: the home page, a service page, the page with the most images and, on stores, a product page and the cart.

Three numbers matter here: the largest content element, layout movement, and response to touch. The first says when the main content appears, the second how much the page shifts while loading, and the third how quickly it reacts to the first click.

How to read the report without technical knowledge

The largest content element is usually the main image or a big heading. If its time is high while server response is low, the problem is the resource: the image is too large, in a slow format, or loads too late. If server response is high too, the problem sits above all that, in hosting and the database.

Layout movement happens when content appears and pushes what was already on screen. The usual culprits are images without set dimensions, banners loading after the text, and fonts arriving later than the first paint.

Response to touch measures how quickly the page reacts when someone clicks or types. A high value usually means too many scripts run on every interaction, most often from plugins that are not needed on that page.

The laboratory score is not a ranking factor and should not be chased at the cost of functionality. It is more useful to read the list of suggestions and rank it by size of gain, then fix whatever carries the most seconds first.

Fixes in order of value for money

The order is not arbitrary. The first two items take a day and deliver the most, while the rest are done gradually with a check after each one.

• Full page caching, with caching switched off for the cart, checkout and admin screens
• Images scaled to the size actually displayed, compressed, and served in a format such as WebP or AVIF
• Deferred loading for images below the first screen, but not for the main image
• Removing plugins and scripts that load on every page while being used on one
• Fonts: fewer weights, self-hosted files, and a rule that allows text to show immediately
• Server-level caching and a newer PHP version, because that shortens the response before the page even starts to render
• Third-party scripts, such as chat widgets, maps and advertising pixels, loaded on interaction or after the content

How to measure whether the fix worked

The laboratory result shows immediately, while field data lags, because it is calculated over a twenty-eight-day window. That is why no conclusion is drawn from field data in the first week; instead the lab result is watched and the site is checked for anything that broke.

Measure the same page, the same device and the same kind of connection. If you test on a desktop before the change and on a phone afterwards, the difference gets attributed to speed when it actually comes from the device.

Track visitor behaviour alongside speed, because that confirms the fix did no harm. If more people leave immediately after optimisation, something that carried content was probably removed, or deferred loading was applied to the main image as well.

Keep a short log of changes with dates and descriptions. Without one, a month later nobody knows what caused the improvement, and the same mistake gets repeated at the next change.

When a bigger job is the right answer

If server response stays high and the host offers neither a newer PHP version nor server-level caching, tuning inside the site cannot achieve much. Then changing host is cheaper than stacking optimisation plugins, and the effect appears immediately.

On sites built with a page builder, the problem is often the builder itself, because its scripts load everywhere. It can be mitigated partly, and the full answer is leaving the builder at the first larger redesign, when speed is solved in the foundation.

Before any larger decision, check where you actually stand, because that avoids paying for something that is not the bottleneck. A free speed check and the basic score in Website Grader give a picture in minutes, we covered the measures Google uses in our article on Core Web Vitals optimisation, and our PageSpeed service covers the technical fixes from caching to images.

Source

Key takeaways

• Speed is measured in two layers: real visitor data for the verdict and a laboratory test for diagnosis.
• Field data lags by up to twenty-eight days, so no conclusion is drawn on the day after a change.
• Caching, images and the number of scripts deliver most of the gain and are fixed first.
• The laboratory score is not a ranking factor and should not be chased at the cost of functionality.
• When server response stays high, changing host helps more than collecting optimisation plugins.

Conclusion

Checking speed only makes sense if it is measured before and after, in the same place and on the same device, because the difference in numbers is the only proof. If you do not know where to start, start with server response, since it sets the limit for everything else, and only then move on to images and scripts. If the site is slow and dated at the same time, a redesign is the opportunity to solve speed in the foundation rather than layering plugins that interfere with each other.