A mobile friendly website is a site that is genuinely pleasant to use on a phone screen: the text is readable without pinching, the buttons are easy to hit with one thumb, and, the part most people forget, the page appears quickly even on two bars of signal. That last point is usually the problem. Plenty of business owners already have a site that neatly shrinks to fit a phone, yet their prospects still leave before they see a price.
Before going further, one thing needs clearing up because it often gets mixed together. There are two different kinds of "speed" when it comes to websites. The first is how fast you can build one, meaning how long it takes from idea to live site. The second is how fast that site opens on a visitor's phone. What decides how many people stay and eventually contact you is the second, and that is what this page is about.
This is also not a general SEO guide. If that is what you need, we cover it separately in website SEO basics and how to get your website on Google. The focus here is single: why speed and the mobile experience determine how many prospects stay, how to measure it yourself without paying anyone, and which parts are genuinely worth fixing.
What a mobile friendly website is, and why "fits a phone screen" is not enough
Most people think mobile friendly means the layout does not fall apart on a phone. That is the entry requirement, not the finish line.
A more honest standard has four parts:
- Readable. Body text at least the equivalent of 16 pixels. If visitors have to zoom to read the price, you have already lost some of them.
- Tappable. Buttons and links are big enough and spaced enough that a thumb does not hit the wrong one. An order button squeezed into a tiny navigation bar is an expensive mistake.
- No overflow. No table, image, or box forces the page to scroll sideways. Horizontal scrolling on a phone feels like a broken site.
- Fast to appear. The main content of the page, usually the headline and the large photo at the top, shows up before the visitor runs out of patience.
The first three are layout matters and are usually handled by any modern platform. The fourth is what makes the big difference, and it is the one most often missed, because site owners check from an office laptop on fast wifi.
Google itself uses the mobile version as its main reference. In its official documentation, Search Central states that Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking. This is called mobile-first indexing. In other words, the phone version of your site is not a backup, it is the version Google sees.
In mobile-first markets, the stakes are even higher
In many markets, mobile is only part of the traffic. In some it is far more extreme. Indonesia, where Forgelo is built, is a useful example.
According to DataReportal's Digital 2025: Indonesia report, there were 356 million active mobile connections in Indonesia in early 2025, equal to 125 percent of the total population. That does not mean everyone has a phone, because one person can hold several numbers. But the direction is clear: the internet there lives in people's hands, not on desks.
Three practical consequences for a business owner, wherever your customers are:
Network quality is uneven. Not all your visitors are sitting in a cafe on wifi. Some open your link on a bus, in a warehouse, or somewhere with a signal that comes and goes. A site that needs to load 4 MB of assets will feel dead in those conditions.
Data still costs money. A heavy page is not only slow, it also eats into the visitor's data allowance. A visitor who was disappointed once rarely tries twice.
Budget and midrange phones dominate. The processor in an inexpensive phone is much weaker than your work laptop. A script that feels light on your device can freeze the page for a few seconds on theirs.
The combined effect is simple. Buyers facing a slow site usually do not switch to a competitor, because they do not know one exists yet. They go back to Instagram or WhatsApp, wherever they came from, and the buying moment passes.
The three numbers Google uses to judge visitor experience
Google sums up this experience in three metrics called Core Web Vitals. You do not need to be a programmer to understand them, just to know what each one measures.
| Metric | What it measures | "Good" threshold |
|---|---|---|
| LCP (Largest Contentful Paint) | When the page's main content finishes appearing | 2.5 seconds or less |
| INP (Interaction to Next Paint) | How quickly the page responds to a tap | 200 milliseconds or less |
| CLS (Cumulative Layout Shift) | How stable the layout stays while the page loads | 0.1 or less |
All three thresholds are on Google's Core Web Vitals page on web.dev. One important detail that often gets skipped: these numbers are measured at the 75th percentile of all visits, split between mobile and desktop. So it is not an average. Three out of four of your visitors must get that experience, including the ones with a bad signal.
In everyday terms:
LCP answers the question "how long until I see something useful?" If a visitor stares at a blank screen for three seconds, some of them have already pressed back. According to web.dev's LCP optimization guide, that time breaks into four parts: waiting for the server's response, the delay before the main asset starts loading, how long that asset takes to load, and the delay until the element is actually painted. For most small business sites, the culprit is the third part: a large photo that was never compressed.
INP is that "stuck" feeling when you tap a button and nothing happens. web.dev's INP documentation says a value above 200 milliseconds up to 500 milliseconds already falls into needs improvement. On midrange phones, the most common cause is a pile of tracking scripts and chat widgets installed together.
CLS is the annoying moment when you are about to tap "Order now" and a promo banner suddenly appears, so your finger lands somewhere else. web.dev's CLS guide sets anything above 0.25 as poor. It is the cheapest metric to fix and the most often ignored.
How to check your mobile friendliness and speed yourself, for free
You do not need to hire anyone to know where you stand. Do these three steps, in order.
Step 1: run PageSpeed Insights. Go to pagespeed.web.dev, paste the address of your most important page (usually the home page and one product or service page), and press Analyze. When the results appear, make sure you are on the Mobile tab, not Desktop. This is the most common mistake: people read the desktop number and feel safe.
Step 2: read the top section first, not the score. If your site has enough visitors, a block titled "Discover what your real users are experiencing" appears at the top. That is field data from the Chrome User Experience Report, a dataset of real Chrome users over the last 28 days. This is the number that represents your buyers' experience. If all three metrics are green, your site is healthy, whatever the big score below says.
If that block does not appear, your traffic is not yet high enough to be included in the dataset. That is normal for a new site and not a bad sign. In that case, use the lower section as a rough estimate.
Step 3: test manually on someone else's phone. Borrow a phone from an employee or a family member, switch off wifi, open your site on mobile data, and count silently until the content appears. Also try tapping every order button. This five-minute test often finds things no report shows: a wrong WhatsApp number, a button covered by another element, or a form that will not scroll. If you manage your site from your phone, the guide to building a website on your phone covers that flow in more detail.
Which scores are worth chasing, and which only cause anxiety
This is the part people rarely say, and it may differ from the advice you usually hear: do not chase a score of 100.
The big colored number in PageSpeed Insights is the result of a lab simulation, run on a simulated device and network. It is useful as a diagnostic tool, but it is not a report card from your real visitors. A site scoring 72 that passes all three field data thresholds is healthier than a site scoring 96 that fails field data.
Worth chasing:
- All three metrics in the real user data block are green, especially on the Mobile tab.
- LCP under 2.5 seconds on the pages that most often serve as visitors' entry point.
- CLS close to zero, because it is cheap to fix and immediately noticeable.
Not worth worrying about:
- A few points of difference in the lab score between one test and the next. That number naturally fluctuates.
- Technical warnings that save 0.05 seconds but take two days of work.
- Scores for pages almost nobody visits.
It also helps to keep the impact in perspective. Google calls Core Web Vitals one aspect of page experience that its ranking systems consider, and encourages site owners not to focus on just one or two aspects. Content that genuinely answers the searcher's need is still the biggest factor. The real value of speed is felt more in conversion. Case studies published by Google give a sense of scale: Vodafone recorded a 31 percent LCP improvement followed by an 8 percent rise in sales, while Rakuten 24 reported a 53.37 percent increase in revenue per visitor and a 33.13 percent increase in conversion rate after fixing its Core Web Vitals. The scale is obviously different from a home bakery, but the direction of the relationship is the same: a fast page gets more people to the order button.
Seven reasons small business sites are slow on mobile, ordered by impact
From recurring patterns, this is the order that usually pays off most when fixed.
- Raw photos from a phone camera. A single 4 MB product photo uploaded as is can wreck LCP on its own. Compress to under 200 KB and use a modern format such as WebP. This is the fix with the best ratio of result to effort.
- Images without dimensions. web.dev's CLS guide names images without dimensions as the most common cause of layout jumps. The fix is trivial: set width and height attributes.
- Ads, embeds, and iframes without dimensions. Google Maps, videos, and widgets inserted without reserved space push the content below them down once they finish loading.
- Content injected late. Promo banners, shipping notices, and pop-ups that appear after the page has painted are among the CLS causes named explicitly in the same documentation.
- Too many third-party scripts. Ad pixels, two analytics tools, a chat widget, and a newsletter pop-up installed together are a recipe for poor INP. Remove the ones whose data you never read.
- A slow server response. The wait for the first response is the opening component of LCP. Cheap hosting shared among too many users often shows up here.
- Heavy web fonts. Loading four weights from two font families for aesthetics is rarely worth it. Web fonts are also among the CLS causes web.dev lists.
Notice that five of the seven causes above are not coding problems. They are content discipline: compressed images, selective widgets, and pages that are not overloaded.
Fix it or rebuild it?
The answer depends on where your site came from.
If your site is fairly simple and only needs its assets cleaned up, just fix it. Compress every image, set their dimensions, remove unused scripts, then test again. Those three steps are often enough to move a site from red to green, and they cost nothing.
If your site was built years ago on a theme with a stack of plugins overriding each other, the math changes. Every fix triggers a new problem, and you end up paying someone to patch something whose foundation is simply heavy. In that situation, rebuilding the core pages usually saves more time than patching forever.
This is where the way a website is built shapes the result. Sites built with Forgelo are responsive by default and include built-in SEO from the first page, so you do not start from a technical hole. You describe your business in one sentence, and within a few minutes a draft site is ready, complete with page structure and copy. To be clear, so it does not get confused with this article's topic: what finishes in minutes is the building process, not a promise about your site's future Core Web Vitals numbers. Those are still shaped by your own decisions, especially how heavy the photos you upload are and how many widgets you add.
Tidying the details does not need a team either. You type the change you want, for example "replace the hero photo with a lighter version" or "remove the promo banner under the headline", and only that section is rebuilt. This section-by-section editing flow keeps small fixes from feeling like a project. The free plan covers one site if you want to try it first, and the paid options are on the pricing page.
Finally, do not stop at the numbers. A fast website without a clear ordering path is still quiet. Once your site is light, make sure visitors know where to go: a WhatsApp button visible without much scrolling, prices that are not hidden, and pages that answer the questions that usually arrive in chat. We cover how to set that up in turning visitors into WhatsApp leads and how to build a website that sells. If you are at the very beginning and do not have a site at all, start with the guide to building a website for your business.
Speed is not the end goal. It only makes sure your buyers stay long enough to see what you sell.
