1. Executive Summary
If your website loads slowly or its layout breaks on mobile, it is turning visitors away at the door right now. The problem is easy to miss because everything looks fine on an office monitor.
This article answers three questions: Are most of my visitors really on mobile? How does Google evaluate speed? What should I fix first? It explains design principles, practical speed optimization, and free testing tools at a level that a project owner can verify directly.
You do not need to know how to code. It is enough to understand what to request from an agency and which standards to use when reviewing the finished work.
Key message
Google completed its transition to mobile-first indexing in 2023. The screen used to determine search rankings is mobile, not desktop. Yet many organizations still review websites only on office monitors.
The speed thresholds are equally clear: LCP of 2.5 seconds, INP of 200 ms, and CLS of 0.1. Passing all three is the official definition of a site with good Core Web Vitals.
2. Most Web Traffic Is Already Mobile
According to StatCounter, roughly 60% of global web traffic comes from mobile devices. The era when desktop was the default and mobile was the exception ended years ago.
The difference is even greater in some industries. Customers search for restaurants, salons, clinics, and academies while moving around, with a phone in hand. Visits from Naver searches, Instagram profile links, and addresses shared through KakaoTalk are almost entirely mobile. Anyone who has run advertising has probably already seen acquisition reports where mobile exceeds 70%.
2.1 Which version of my site does Google evaluate?
The mobile version. Google announced mobile-first indexing in 2016 and declared the transition complete in October 2023. What now enters Google search results is the mobile version read by its smartphone crawler. No matter how polished the desktop site is, content that is clipped or hidden on mobile can be left out of the evaluation.
Some redesigns remove introductions and detailed explanations in the name of simplifying mobile screens. The result may look cleaner, but to a search engine it is a site that has lost content. Reduce decoration, not information.
2.2 Why is desktop-only review not enough?
This is a common trap during production. Both the client and the agency usually review the site on office monitors. A site that looked perfect at 27 inches may have tiny text on a 6-inch screen, overlapping buttons, and a call button that requires three long scrolls to reach.
The customers who generate revenue are arriving on that 6-inch screen. Mobile-first begins by changing the review question from “Does it look good on my monitor?” to “Can a customer use it comfortably on a phone?”
Mobile-first indexing in one sentence
Google ranks a site using the content, structure, and speed of its mobile version. The mobile screen is the site’s official report card.
If you have just launched or redesigned a site, begin by checking indexing and the basic search setup. The sequence is explained in our 90-Day SEO Setup Guide for a New Website.
3. Core Web Vitals: The Speed Metrics Google Uses
Google defines “fast” with three numbers rather than a feeling: loading speed (LCP), responsiveness (INP), and visual stability (CLS). Together they are called Core Web Vitals, and they are included in search ranking systems.
3.1 The three metrics and their thresholds
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Time until the largest visible content element, usually the hero image, appears | 2.5 s or less | 2.5–4.0 s | More than 4.0 s |
| INP (Interaction to Next Paint) | Time from tapping a control until the screen responds | 200 ms or less | 200–500 ms | More than 500 ms |
| CLS (Cumulative Layout Shift) | How much page elements unexpectedly move while loading | 0.1 or less | 0.1–0.25 | More than 0.25 |
The assessment uses the 75th percentile of real-user data. At least 75 out of 100 visits must fall within the threshold to pass. One fast load on your own phone proves nothing. INP replaced the former FID (First Input Delay) metric in March 2024.
The name CLS may be unfamiliar, but the experience is not: you try to tap a button while reading an article, an ad suddenly appears, and you hit the wrong thing. This often happens on pages where image dimensions were not reserved in advance.
3.2 How much does speed affect search rankings?
Speed matters, but not enough to overturn content quality. Google has consistently described page experience as one of many ranking signals. In practice, the faster document is more likely to win when two documents have similar quality.
Abandonment is more dangerous than a ranking change. A Google study published in 2016 found that 53% of mobile visits were abandoned when a page took longer than three seconds to load. Visitors acquired at a cost of several dollars per click can leave before seeing the first screen. Keeping the people who already arrived has a much more direct effect on revenue than moving up one ranking position.
Check your site score in 30 seconds
Enter your homepage address at PageSpeed Insights (pagespeed.web.dev). It immediately shows the mobile score and whether each of the three metrics passes.
Measure before finishing this article. The result will make it easier to identify which optimization steps below apply to your site.
4. Mobile-First Design Principles
Mobile-first does not merely mean “also visible on mobile.” It means designing for the smallest screen first and then expanding toward larger screens. If you design a desktop composition first and squeeze it down, something will eventually break. Expanding a structure that already works in limited space is safer.
4.1 Touch targets: can a thumb tap accurately?
A mouse pointer is accurate to the pixel; a thumb is not. Google Material Design recommends touch areas of at least 48×48 dp, while Apple’s Human Interface Guidelines recommend 44×44 pt. Buttons need sufficient size and spacing. Put two links too close together and one of them will be tapped by mistake.
Always make phone numbers tel: links. Too many sites still make visitors memorize a number and retype it in the phone app. Opening the call screen with one tap directly increases the chance of an inquiry.
4.2 Font size and line length
Body copy should start at 16 px or larger. If a visitor must pinch to zoom before reading, the type has already failed. Use line height around 1.6–1.8, avoid excessively long lines, and maintain sufficient contrast. The fashion for light gray text on white creates a screen that becomes unreadable outdoors in direct sunlight.
4.3 A hamburger menu is not always the answer
Hiding every menu item behind a three-line icon has become a default pattern, but hidden navigation receives fewer taps. If there are only four or five items, there may be no reason to hide them. Keep them visible at the top, or move frequent actions—call, directions, reservation—to a fixed bar at the bottom.
Some sites do need a hamburger menu, including shops and content platforms with more than ten sections. The decision comes down to one question: Is the action visitors use most available within one tap?
4.4 What belongs on the first screen?
A mobile first screen is only a small patch in the palm of a hand. It has no room for a company history and a CEO greeting. Without scrolling, visitors should understand why they came: what the company does, how to contact it, and where it is located.
A simple way to set priorities is to write down the three questions customers ask most often by phone. If the answers are not present within the first two screens, the content order is wrong.
4.5 Responsive or adaptive: which should you choose?
The short answer: a small or mid-sized company website should be responsive.
| Category | Responsive | Adaptive |
|---|---|---|
| Method | One page rearranges fluidly according to screen width | Separate screens or URLs, such as an m. domain, are served by device |
| Maintenance | One URL and one content source | Duplicate maintenance with a risk of missed updates |
| SEO | Google’s recommended approach | Incorrect alternate-URL settings can create indexing problems |
| Best fit | Most corporate websites | Large services whose mobile functionality is fundamentally different |
Some older sites still operate a separate mobile page on an m. domain. That doubles maintenance and splits SEO signals, so a redesign is a good time to consolidate everything into one responsive site. If you are considering a complete overhaul, see our Website Redesign Guide for the process and review checkpoints.
5. Practical Speed Optimization
Where should you start? Images. Most perceptible speed improvements come from images and scripts. Before upgrading servers or moving hosting providers, work through the low-effort, high-impact tasks in order.
5.1 Images: the largest and easiest problem
Open a slow website and the cause is usually imagery: a 4,000-pixel original straight from a camera is uploaded as-is, then downloaded in full before the browser shrinks it for display. Websites with pages weighing tens of megabytes are not rare.
- Convert to WebP: Google’s developer documentation reports that WebP is 25–34% smaller than JPEG at equivalent quality. Free converters are widely available, and WordPress plugins can automate the process.
- Resize to the displayed dimensions: an image shown at 400 px only needs to be about 800 px wide for high-density screens. Keep the 4,000 px original off the delivered page.
- Lazy-load below-the-fold images: a single
loading="lazy"attribute delays images outside the viewport until the user scrolls near them. Do not apply it to the main image above the fold; that can make LCP worse. - Declare width and height: dimensions let the browser reserve space before the image arrives. This solves one of the most common causes of CLS.
5.2 Fonts: Korean webfonts are heavy
Korean has 11,172 possible composed characters. Loading an entire Korean font with the assumptions used for Latin fonts can make one font several megabytes. When text remains invisible and then appears late while the screen shifts, the font is often responsible.
- Subset fonts: a subset containing the 2,350 most frequently used KS X 1001 characters cuts file size significantly. Korean font libraries and Google Fonts offer subset versions.
- Use WOFF2: one WOFF2 file is usually enough for a webfont. Serving TTF or OTF directly is like distributing an uncompressed file.
- Use font-display: swap: show text in a system font while the webfont loads. That is much better than presenting an empty screen with invisible text.
5.3 Scripts: remove unused code first
Chat widgets, outdated tracking tags, and slider libraries no one uses accumulate over time. They keep pages from responding quickly to taps and make INP worse. Before applying advanced optimization, inventory the scripts and remove what is no longer needed.
Add the defer attribute to scripts that remain so they do not block page display. Code that is not required for the initial rendering should not make the screen wait.
5.4 Server settings: compression and caching
Some improvements take only a few server directives. Enabling gzip or Brotli compression greatly reduces transfer sizes for HTML, CSS, and JavaScript. Setting browser caching with Cache-Control prevents returning visitors from downloading the same images and styles again. If you cannot change the server yourself, ask your host or agency to “enable gzip compression and browser caching.”
5.5 Impact by task
| Task | Difficulty | Main metric improved |
|---|---|---|
| Convert and resize images to WebP | Low | LCP |
| Lazy-load images | Low | LCP |
| Set image width and height | Low | CLS |
| Korean font subset + WOFF2 | Medium | LCP, CLS |
| Remove scripts + defer | Medium | INP |
| gzip/Brotli compression + caching | Medium | Overall LCP |
For WordPress: begin with a plugin diet
Every plugin adds CSS and JavaScript. On a site with more than twenty plugins, half are often inactive or have a purpose nobody remembers.
Simply making a list and checking “What stops working if we remove this?” one item at a time can raise the score. Keep only one cache plugin because overlapping cache plugins often conflict.
6. Testing Tools and a Repeatable Routine
Three tools are enough: PageSpeed Insights, Lighthouse, and Google Search Console. All are free and require either no account or a single Google account.
6.1 PageSpeed Insights: real-user data in one place
Enter a URL and you receive two sets of results. The real-user assessment at the top uses the last 28 days of Chrome User Experience Report (CrUX) data and is the official basis for the Core Web Vitals result. The diagnostic score below is simulated lab data; its list of improvement opportunities is especially useful in practice. Always check the mobile tab first. Desktop scores are usually more generous.
6.2 Lighthouse: all you need is Chrome
Run the same diagnostics locally from the Lighthouse tab in Chrome DevTools (F12). It is useful for testing an unpublished development site and comparing results before and after a change. You can also request the report from an agency as part of acceptance review.
6.3 Search Console: pass or fail based on actual visitors
The Core Web Vitals report in Search Console divides your URL groups into Good, Needs improvement, and Poor for both mobile and desktop, based on real-user data. It identifies which page groups have problems, making it useful for prioritizing repairs.
The former Mobile Usability report was retired at the end of 2023. Use Lighthouse and real-device testing to check broken layouts and touch-target spacing.
6.4 More reliable than any tool: your own phone
A good score is meaningless if the site is awkward on a real phone. Turn off Wi-Fi and test over LTE. Your customer’s environment is a signal on the subway, not the office’s gigabit connection.
- Does meaningful content appear within three seconds?
- Are call, booking, and inquiry actions within one thumb tap?
- Does the screen shift or jerk while scrolling?
- Can you read body text without zooming?
When lab and field data disagree
Lighthouse may show a strong score while Search Console says “Needs improvement.” Lab data is a simulation under fixed conditions; field data includes slower phones and subway LTE connections.
When they disagree, field data is the standard. It is what Google uses for its assessment and what customers actually experience.
7. Conclusion and Checklist
7.1 Summary in three sentences
Most visitors arrive on mobile, and Google evaluates the mobile version of a site. Speed has clear thresholds—LCP 2.5 seconds, INP 200 ms, and CLS 0.1—and images, fonts, and scripts usually determine whether a site passes. The safest design process starts on a small screen and expands toward larger ones.
7.2 Six checks you can run today
- Test a real device: turn off Wi-Fi, open the site on your phone, and check whether meaningful content appears within three seconds.
- Measure the score: check Core Web Vitals in the mobile tab of PageSpeed Insights and save a screenshot of the result.
- Fix images: convert to WebP, resize to displayed dimensions, add lazy loading where appropriate, and set width and height.
- Fix fonts: confirm that Korean font subsets, WOFF2, and
font-display: swapare used. - Review touch usability: keep call and inquiry buttons one tap away, touch targets at least 48 px, and body text at least 16 px.
- Create a measurement routine: repeat the same test monthly and keep records. Speed inevitably regresses as content and plugins accumulate.
7.3 Speed is a habit, not a permanent state
Even a well-optimized site becomes slow again when neglected. An editor uploads an original-size banner, marketing adds another tracking tag, and plugin updates introduce more scripts. That is why the final checklist item is a recurring measurement routine.
Once records accumulate, “the site seems slower lately” becomes “LCP increased by one second in March.” Facts make it possible to request a precise repair from an agency or an internal team.