1. 概要（Executive Summary）
如果网站在移动端打开缓慢或布局错乱，那么此刻仍在把访客挡在门外。只是因为办公室显示器上看起来正常，问题才不容易被发现。
本文回答三个问题：我的网站访客真的多数来自移动端吗？Google 如何评价速度？应该先修什么？从设计原则、速度优化实务到免费检测工具，都整理到项目负责人能够亲自验证的程度。
你不需要懂代码。只要能判断应该向制作公司提出哪些要求，以及按什么标准验收结果即可。
核心信息
Google 已于2023年完成移动优先索引迁移。决定搜索排名的基准页面是移动端，而不是桌面端。但很多企业仍只在办公室显示器上验收网站。
速度标准同样明确：LCP 2.5秒、INP 200毫秒、CLS 0.1。通过这三个门槛，才符合 Core Web Vitals 对良好网站的正式定义。
2. 移动端早已占据多数流量
根据 StatCounter 统计，全球约60%的网络流量来自移动设备。桌面端是默认、移动端是例外的时代，早在多年前就已结束。
不同业态的差距可能更大。餐厅、美容院、医院、培训机构等本地服务通常发生在用户移动途中和手机屏幕上。来自搜索、Instagram 主页链接或聊天中分享地址的访问几乎全是移动端。做过广告投放的负责人，很可能已经在流量报告中见过移动端占比超过70%的结果。
2.1 Google 使用哪个版本评价网站？
移动版。Google 在2016年宣布移动优先索引，并于2023年10月宣布迁移完成。如今进入 Google 搜索结果的是智能手机爬虫读取的移动版本。桌面版再精致，如果内容在移动端被裁切或隐藏，也可能不被纳入评价。
有些改版以简化移动界面为由，整段删除公司介绍和详细说明。视觉上也许更干净，但对搜索引擎来说，网站失去了内容。应该减少的是装饰，不是信息。
2.2 为什么不能只看桌面端验收？
这是制作过程中的常见陷阱。委托方和制作方通常都在办公室显示器上检查。27英寸屏幕上完美的网站，到了6英寸手机上可能文字细小、按钮重叠，拨号按钮还要滚动三次才能找到。
真正创造收入的顾客正是从这块6英寸屏幕进入。把验收问题从“在我的显示器上好看吗”改为“顾客在手机上好用吗”，移动优先就从这里开始。
一句话理解移动优先索引
Google 对网站排序时，以移动版的内容、结构和速度为标准。移动页面就是网站的正式成绩单。
如果网站刚上线或刚完成改版，应先检查索引提交和基础设置。具体顺序见新网站上线后90天 SEO 设置指南。
3. Core Web Vitals：Google 关注的速度指标
Google 不凭感觉判断“快”，而是使用三个数字：加载速度 LCP、交互响应 INP、视觉稳定性 CLS。三者合称Core Web Vitals（核心网页指标），也会用于搜索排名系统。
3.1 三项指标与通过标准
| 指标 | 测量内容 | 良好 | 需要改进 | 较差 |
|---|---|---|---|---|
| LCP （Largest Contentful Paint） | 页面中最大的可见内容，通常是主图，显示出来所需的时间 | 2.5秒以内 | 2.5～4.0秒 | 超过4.0秒 |
| INP （Interaction to Next Paint） | 点击按钮后到页面产生响应的时间 | 200毫秒以内 | 200～500毫秒 | 超过500毫秒 |
| CLS （Cumulative Layout Shift） | 加载过程中页面元素意外移动的程度 | 0.1以内 | 0.1～0.25 | 超过0.25 |
判定采用真实用户数据的第75百分位。100次访问中至少有75次达到标准，才算通过。在自己的手机上偶尔加载很快并不能证明合格。INP 于2024年3月取代了原来的 FID（First Input Delay）。
CLS 这个名字也许陌生，但体验并不陌生：正准备点击文章中的按钮，广告突然插入，结果误触了别处。没有预先声明图片尺寸的页面尤其容易出现这种情况。
3.2 速度对搜索排名有多大影响？
速度会影响排名，但不足以颠覆内容质量。Google 一直把页面体验描述为众多排名信号之一。更接近的情况是：质量相近的页面竞争时，更快的一方占优。
比排名更可怕的是跳出。Google 在2016年发布的研究显示，移动页面加载超过3秒时，53%的访问会被放弃。按点击付费带来的访客，可能还没看见首屏就离开。留住已经到达的人，比排名上升一位更直接影响收入。
30秒查看网站得分
在 PageSpeed Insights（pagespeed.web.dev）输入首页地址，即可看到移动端得分以及三项指标是否通过。
建议在读完本文前先测一次。这样更容易判断后面的优化项目中，哪些适用于你的网站。
4. 移动优先设计原则
移动优先不是“移动端也能看”，而是先设计小屏幕，再向大屏幕扩展的顺序问题。先完成桌面方案再压缩，迟早会有部分结构折断。从狭窄空间中仍然成立的结构开始扩展更安全。
4.1 触控目标：拇指能否准确点击？
鼠标指针可以精确到像素，拇指却不能。Google Material Design 建议触控区域至少48×48dp，Apple Human Interface Guidelines 建议至少44×44pt。按钮本身要够大，按钮之间也要留出间距。两个链接靠得太近，总会有人误触。
电话号码一定要设置为tel: 链接。仍有不少网站要求用户记住号码再输入拨号应用。一次点击即可打开通话界面，能直接增加电话咨询机会。
4.2 字号与行长
正文应以16px以上为基本标准。必须用手指放大才能阅读，字号就已经失败。行高建议为1.6～1.8倍，单行不要过长，同时确保足够的明暗对比。白底上的浅灰文字，在室外阳光下可能完全无法辨认。
4.3 汉堡菜单不总是答案
把所有菜单藏在三条横线后面已成为常见做法，但隐藏的项目点击率更低。只有四五个项目时，没有必要全部隐藏。可以直接显示在顶部，或把电话、路线、预约等常用操作放在底部固定栏。
当然，菜单超过十项的商城或内容网站仍适合汉堡菜单。判断标准只有一个：访客最常用的操作是否只需点击一次？
4.4 首屏应该展示什么？
移动端首屏只有掌心大小，没有空间堆放公司历史和 CEO 致辞。无需滚动，访客就应该知道公司做什么、如何联系、位于哪里。
确定优先级的方法很简单：写下顾客打电话时最常问的三个问题。如果答案没有出现在前两屏，内容顺序就需要调整。
4.5 响应式还是自适应？
先说结论：中小企业网站应选择响应式。
| 项目 | 响应式（Responsive） | 自适应（Adaptive） |
|---|---|---|
| 方式 | 同一页面根据屏幕宽度灵活重新排列 | 按设备提供独立页面或 m. 域名等独立 URL |
| 维护 | 一个 URL、一套内容统一管理 | 多版本重复维护，容易漏改 |
| SEO | Google 推荐的方式 | 备用 URL 设置错误可能导致索引问题 |
| 适用情况 | 大多数企业网站 | 移动端功能完全不同的大型服务 |
一些旧网站仍通过 m. 域名单独运营移动页面。这会让维护成本翻倍并分散 SEO 信号，因此改版时最好合并为一个响应式网站。如果正在考虑全面更新，可参考网站改版指南中的实施顺序和检查要点。
5. 速度优化实务
应该从哪里开始？图片。大多数可感知的速度提升都来自图片和脚本。考虑升级服务器或迁移主机前，先按顺序处理难度低、效果大的任务。
5.1 图片：最大也最容易解决的问题
打开一个缓慢的网站，原因通常是图片：把相机导出的4000px原图直接上传，浏览器完整下载后再缩小显示。单页达到几十MB的网站并不少见。
- 转换为 WebP：Google 开发文档显示，同等质量下 WebP 比 JPEG 小25～34%。免费工具很多，WordPress 插件也可自动处理。
- 按显示尺寸缩放：页面显示为400px的图片，即使考虑高清屏，800px通常已经足够。4000px原图不要直接用于页面传输。
- 延迟加载：添加
loading="lazy"后，视口外图片会等到滚动接近时再加载。但不要用于首屏主图，否则 LCP 可能更慢。 - 声明宽高：设置 width 和 height 后，浏览器会提前预留位置。这能解决最常见的 CLS 原因之一。
5.2 字体：韩文字体文件很重
韩文有11,172个可组合字符。如果用拉丁字体的思路加载完整韩文字体，一个文件就可能达到数MB。文字长时间不显示，随后突然出现并推动页面时，字体通常是原因。
- 字体子集：只包含 KS X 1001 中2,350个常用字符的子集能显著缩小体积，字体平台和 Google Fonts 都提供相应版本。
- WOFF2 格式：网页字体通常只需 WOFF2。直接发布 TTF 或 OTF，相当于传输未压缩文件。
- font-display: swap：网页字体加载期间先显示系统字体，比让文字完全不可见要好得多。
5.3 脚本：先删除不用的
聊天组件、旧追踪代码、无人使用的轮播库会不断累积，使页面无法及时响应点击并恶化 INP。应用复杂优化前，先列出脚本并删除不再需要的部分。
保留的脚本应添加defer 属性，避免阻塞页面显示。不参与首屏渲染的代码没有理由让页面等待。
5.4 服务器：压缩与缓存
有些改善只需几行配置。启用gzip 或 Brotli 压缩可大幅减少 HTML、CSS、JavaScript 的传输量；设置Cache-Control 浏览器缓存后，回访用户不必再次下载相同图片和样式。如果无法自行修改，可以直接请主机商或制作公司“启用 gzip 压缩和浏览器缓存”。
5.5 各项工作的效果
| 工作 | 难度 | 主要改善指标 |
|---|---|---|
| 图片转 WebP 并缩放 | 低 | LCP |
| 图片延迟加载 | 低 | LCP |
| 设置图片 width/height | 低 | CLS |
| 韩文字体子集 + WOFF2 | 中 | LCP、CLS |
| 清理脚本 + defer | 中 | INP |
| gzip/Brotli 压缩 + 缓存 | 中 | 整体 LCP |
如果使用 WordPress：先给插件减负
每个插件都会增加 CSS 和脚本。安装超过20个插件的网站中，往往有一半已经停用，或没人记得用途。
列出清单并逐项确认“删除后什么功能会失效？”，仅靠整理就可能提升得分。缓存插件功能相互重叠，只保留一个；多个同时运行反而容易冲突。
6. 检测工具与测试流程
三种工具足够：PageSpeed Insights、Lighthouse、Google Search Console。它们全部免费，无需账号或只需一个 Google 账号。
6.1 PageSpeed Insights：同时查看真实用户数据
输入 URL 后会得到两组结果。上方的真实用户体验评估使用 Chrome 用户过去28天的实测数据（CrUX），是 Core Web Vitals 是否通过的正式依据。下方诊断分数是模拟的实验室数据，附带的改进项目在实务中最有价值。务必先看移动端标签，桌面端分数通常更宽松。
6.2 Lighthouse：有 Chrome 即可
可在 Chrome 开发者工具（F12）的 Lighthouse 标签中本地运行相同诊断。适合检查尚未公开的开发站点，或直接比较修改前后的结果。也可要求制作公司提交报告作为验收材料。
6.3 Search Console：按真实访客判断是否合格
Search Console 的 Core Web Vitals 报告会基于真实用户数据，把站内 URL 分为“良好”“需要改进”“较差”，并区分移动端和桌面端。它能指出有问题的页面组，便于安排修复优先级。
过去的“移动设备易用性”报告已于2023年底停止。现在应使用 Lighthouse 和真机测试检查布局错乱及触控元素间距。
6.4 比工具更可靠：自己的手机
得分再好，真机上不好用也没有意义。关闭 Wi-Fi，用 LTE 访问。顾客的环境不是办公室千兆网络，而可能是地铁里的弱信号。
- 三秒内是否出现有意义的首屏内容
- 电话、预约、咨询按钮是否只需一次拇指点击
- 滚动时页面是否发生位移或跳动
- 无需放大是否能阅读正文
实验室数据与现场数据不一致时
Lighthouse 得分良好，但 Search Console 仍显示“需要改进”的情况并不少见。实验室数据是固定条件下的模拟；现场数据包含低速手机和地铁 LTE 等真实环境。
两者不一致时，应以现场数据为准。Google 用它评价页面，顾客也实际经历它。
7. 结论与检查清单
7.1 三句话总结
大多数访客来自移动端，Google 也用移动版评价网站。速度有清晰的通过线：LCP 2.5秒、INP 200毫秒、CLS 0.1，而图片、字体、脚本通常决定能否通过。最安全的设计顺序是从小屏开始，再向大屏扩展。
7.2 今天即可检查的六项内容
- 真机测试：关闭 Wi-Fi，用自己的手机访问，确认三秒内出现有意义的内容。
- 测量得分：在 PageSpeed Insights 移动端标签中检查 Core Web Vitals，并保存结果截图。
- 整理图片：转为 WebP、按显示尺寸缩放、适当延迟加载，并设置 width 和 height。
- 整理字体：确认使用韩文字体子集、WOFF2 和
font-display: swap。 - 检查触控：电话和咨询按钮保持一次点击可达，触控区域至少48px，正文至少16px。
- 建立测量流程：每月在相同条件下复测并记录。内容和插件增加后，速度一定会回退。
7.3 速度是一种习惯，不是永久状态
优化过的网站如果长期不管，仍会再次变慢。编辑上传原尺寸横幅，营销团队增加追踪代码，插件更新又带来更多脚本。因此，清单最后一项必须是定期测量。
记录积累后，“最近网站好像变慢了”会变成“从3月开始 LCP 增加了1秒”。有了事实，才能向制作公司或内部团队提出准确的修复要求。