Picture a customer walking into a shop. They push the door, it sticks, and they stand on the footpath for three seconds waiting for it to open. Most people would not wait. They would walk to the shop next door. A slow website is that sticking door, except the shop next door is one tap away and the customer never tells you why they left.
Page speed is how quickly your website loads and becomes usable. Mobile optimisation is making sure the site works properly on a phone, not just a desktop screen. The two are tied together, and both decide whether a visitor becomes a customer or a bounce.
This explainer covers what slowness costs in real numbers, the three metrics Google uses to judge your pages, a five-minute test you can run on your own site today, and the short list of fixes that actually move the scores.
Slowness costs you customers, in numbers
The link between speed and sales is not a hunch. Google, working with Deloitte, studied 37 leading retail, travel, luxury and lead-generation brand sites across more than 30 million user sessions and found that a 0.1 second improvement in mobile site speed increased conversion rates by 8.4% for retail sites and 10.1% for travel sites. Shoppers on the faster sites also spent 9.2% more.
The size of that is easy to miss. One tenth of a second, not a redesign or a new product, and conversions move by roughly a tenth.
The mechanism is the bounce: someone arrives, waits, and leaves without doing anything. You paid for that click, through an ad or the time spent ranking the page, and got nothing back.
The three numbers Google judges your pages on
Google measures page experience directly, through a set of metrics called Core Web Vitals. These feed into search engine optimisation, the practice of getting your pages to rank in search results, so speed is now part of how high you appear on Google. There are three, and none needs a technical background to understand.
Largest Contentful Paint (LCP) measures loading. It is the moment the biggest element on the screen, usually your main image or headline, finishes appearing. Google's target is 2.5 seconds or less. Past that, the page feels sluggish before the visitor has read a word.
Interaction to Next Paint (INP) measures responsiveness: when someone taps a button or opens a menu, how long the page takes to visibly react. The target is 200 milliseconds or less, about a fifth of a second. A page that looks loaded but freezes when tapped fails this one. (INP replaced an older metric called First Input Delay, so if you have seen FID mentioned, this is its successor.)
Cumulative Layout Shift (CLS) measures visual stability. It is the jump that happens when you go to tap a link and an image loads above it, shoving everything down so you tap the wrong thing. The target is a score of 0.1 or less.
A detail most people miss: Google assesses all three at the 75th percentile of page loads, segmented across mobile and desktop. In plain terms, the experience has to be good for at least three quarters of your visitors, on their phones and their connections, not just for you on the office wifi.
Test your site now: a five-minute walkthrough
You do not need an agency to find out where you stand. Google's free PageSpeed Insights tool at pagespeed.web.dev takes about a minute per page. Run it like this.
- 1.Enter your homepage address and run the test. No account, no installation. The analysis runs on Google's servers, so any device gives the same result.
- 2.Read the Core Web Vitals assessment at the top first. If your site gets enough traffic, this section shows what real Chrome users experienced on your pages over the previous 28 days, as Google's documentation explains. It reads Passed only when all three vitals are Good at the 75th percentile. This is the data Google actually uses.
- 3.Stay on the mobile tab. The tool shows mobile results by default. Resist the urge to switch straight to desktop for the more flattering number.
- 4.Compare your vitals to the targets. LCP at 2.5 seconds or less, INP at 200 milliseconds or less, CLS at 0.1 or less. One poor metric fails the whole assessment.
- 5.Then scroll down to the performance score. This lower section is a lab simulation run with Lighthouse, useful for diagnosis. Google's documented bands: 90 or above is good, 50 to 89 needs improvement, below 50 is poor.
- 6.Read the diagnostics under the score. Each entry names a fix and estimates the saving. On the small-business sites we audit, image entries usually sit at or near the top of that list.
Expect a gap between desktop and mobile, with mobile worse. That gap is the next section's subject.
Two beliefs that keep sites slow
A good desktop score does not mean your site is fine
The same page routinely produces two very different results: comfortable on desktop, failing on mobile. Desktop hardware and fast broadband hide a page's weight. A mid-range phone on mobile data does not, and the mobile lab test deliberately simulates that slower device and connection. Because Google assesses mobile and desktop separately, a strong desktop score cannot rescue a weak mobile one. Checking only the desktop tab grades you on the visitors with the best hardware and the fastest connections, and ignores everyone else.
The culprit is usually your images, not your hosting
When a site is slow, most owners suspect the hosting and consider paying for a bigger server. Sometimes that is right. More often the page itself is simply heavy, and images are the heaviest part. The HTTP Archive's Web Almanac, which measures millions of real pages, put the median mobile page at 2,311 KB in October 2024, with the median mobile homepage carrying around 900 KB of images, the largest single slice of its weight. A photo exported straight from a modern phone can run to several megabytes, which means one unprocessed image can outweigh an entire typical page. Put three of them in a hero slider and no hosting upgrade will rescue that page on a phone connection.
Four in ten Australian visits arrive on a phone
Mobile is not a side consideration. Statcounter data for Australia puts mobile at 42.71% of web page views as of May 2026, against 54.67% for desktop and 2.62% for tablet. Roughly four in ten Australian visits arrive on a phone, and for a local trade, a cafe, or a service people search for while out and about, the share is often higher still. Speed is only half of it: buttons too small to tap and forms that fight the thumb turn away visitors a fast load had already won.
There is a newer reason to care, too. As people ask AI answer engines for recommendations rather than scrolling a results page, the same fast, well-structured sites tend to be the ones these systems can read and cite. We have written about this shift in how LLMs are changing search, and the foundations that help there, clean code and clear structure, are the same ones that lift your speed scores.
The levers that move the numbers, in order
Most slow small-business sites are slow for a handful of fixable reasons. Pull these in order of impact.
- Optimise your images. Compress them, size them to the dimensions they actually display at, and save them in a modern format like WebP or AVIF. Then apply lazy loading, which defers off-screen images until the visitor scrolls near them. As MDN explains, this shortens what loads upfront, which "translates into reduced page load times".
- Cache, and use a CDN. Caching stores a ready-made copy of your page so it is not rebuilt from scratch on every visit. A content delivery network (CDN) keeps copies of your site on servers around the world, so each visitor is served from one near them. For an Australian business with customers spread across the country, that cuts the physical distance your data travels.
- Choose hosting built for speed. Cheap shared hosting crams many sites onto one overworked server, and your response times suffer for it. This sits alongside getting your domain and DNS set up properly, the plumbing that points visitors to your site in the first place.
- Keep the code lean. Template and page-builder sites often carry bundles of scripts the page never uses, and that weight drags down both LCP and INP. A lean site loads only what it needs. Clean structure also makes it easier to add things like schema markup, the labels that help search and AI tools understand your content.
How we approach it at Enki
We build sites to be fast from the first line of code rather than bolting fixes on afterwards. That means lean custom code instead of bloated templates, images and caching handled properly, and Core Web Vitals treated as a target to hit, not a report to ignore. We bring the same discipline to the systems behind a site: our Lead Management System build saved a client over 1,500 hours a month by removing friction and measuring the result, and speed work follows the identical principle. If your site fails the test you just ran, that is a fixable problem, and fixing it usually pays for itself in conversions you were quietly losing.