Mobile site speed is how quickly your site becomes visible and usable on a phone. It is not just about "how many seconds it takes to load"; when the page content appears, whether it responds when you tap, and whether elements jump around while loading all shape the experience. In this article we describe a practical way to measure and improve mobile speed, one that will help when you talk to your technical team.
What do Core Web Vitals measure?
Google uses three metrics it calls Core Web Vitals to measure user experience. The "good" thresholds in Google's web.dev documentation are:
| Metric | What it tells you | Considered good |
|---|---|---|
| LCP (Largest Contentful Paint) | When the page's main content appeared | 2.5 seconds or less |
| INP (Interaction to Next Paint) | How quickly a tap or click got a response | 200 milliseconds or less |
| CLS (Cumulative Layout Shift) | How much elements moved while loading | 0.1 or less |
These values are assessed against the experience of 75 percent of real users. In other words, what matters is not a single test on your fast office connection, but the overall experience of visitors in the field.
How do you measure it?
- PageSpeed Insights: Enter a page URL and it shows both a lab test and, if there is enough traffic, real user data. Don't forget to check the mobile tab.
- Search Console "Core Web Vitals" report: Shows which groups of pages across the site are slow. We explain how to read this report in our article how to read Search Console.
- Your own phone: Turn off Wi-Fi and open your site on mobile data from a mid-range phone. This test tells you what the numbers don't.
Images are often the biggest load
Most mobile speed problems come from images. A large file from a camera or a designer goes onto the page without being resized, and megabytes of data are downloaded for an image that will be a few hundred pixels wide on a phone screen.
- Prepare images in different sizes based on where they will be shown; send phone-sized images to phones.
- Use modern formats such as WebP or AVIF; the same image comes in a much smaller file.
- Load images that are not on the first screen with "lazy loading," meaning they load as the user approaches that section.
- Do not lazy-load the main image on the first screen, though; it directly determines LCP.
- Give every image width and height values; the browser reserves space in advance and the page does not shift.
Fonts and layout shift
Custom fonts look great, but each one is a separate download. A site that uses four weights and two families may have to wait for all of them before showing text.
- Review the weights you use; most sites get by with two or three.
- Hosting fonts on your own server removes the time spent connecting to an external service.
- Make sure text is shown in a system font until the custom font loads, so users never see a blank screen.
- Tune the fallback font's metrics to match the main font closely, so lines don't jump when the font swaps.
Third-party scripts: the invisible weight
Chat bubbles, analytics tags, ad pixels, maps, embedded videos, cookie banners... Each looks harmless on its own, but together they keep the phone's processor busy and cause slow responses to taps, in other words poor INP.
- List every external script loaded on the site and ask of each one, "Who uses this, and why?"
- Remove unused tags; pixels left over from old campaigns are a common burden.
- Show heavy elements such as maps and videos as a small preview at first, and load the real content when the user taps.
- Load chat tools a few seconds after the page opens or on the first interaction.
The server and hosting side
No matter how light the front end is, if the server is slow to send its first response, everything is delayed. Page caching, compression, an up-to-date PHP version and geographically suitable hosting are the cornerstones here. We monitor this regularly as part of our hosting and maintenance service.
Mobile speed checklist
- Have you run PageSpeed Insights on mobile for the home page, one product or service page and one blog page?
- Is the main image on the first screen resized and in a modern format?
- Are image dimensions defined?
- Have you reduced font weights, and are fonts hosted locally?
- Have you listed external scripts and removed the unnecessary ones?
- Are server caching and compression turned on?
- Did you measure again after the changes?
How we do it at Globya
In new corporate website projects, we treat speed not as something to fix later but as a criterion considered from the very start of the design. On existing sites we first take measurements, then write down, in order of priority, the few steps that will deliver the biggest gains. Since speed also affects search visibility, we run this work together with our SEO and GEO service.
Frequently asked questions
Does our PageSpeed score have to be 100?
No. The lab score is a guide, but what really matters is that real users' Core Web Vitals values are in the "good" zone.
Can a site built with a ready-made theme and plugins be made faster?
Noticeable improvement is often possible. But if there are many plugins and a heavy theme, at some point rebuilding becomes more efficient; we will tell you that plainly after measuring.
Will speed work break the site?
Not when done correctly. We test changes in a staging environment first and publish them only after checking critical flows such as forms and payments.
The Globya assistant is online 24/7; it answers right away and passes your question to the team if needed.