2025年7月07日·2 分钟
网站速度入门：哪些改动真正能提升加载时间？
面向初学者的实用指南：真正能提升页面加载速度的要点——图片、缓存、主机、代码与 Core Web Vitals，并附快速可执行的优化步骤。
面向初学者的实用指南：真正能提升页面加载速度的要点——图片、缓存、主机、代码与 Core Web Vitals，并附快速可执行的优化步骤。
当人们说“我的网站很慢”时，通常是指两类感觉：
“加载时间”并不是一个单一的秒表数字。页面加载分阶段进行：浏览器请求文件（HTML、图片、字体、脚本），下载它们，然后把它们变成可用的页面。你可以把它想象为开店：开锁、开灯、摆货，上好架子才真正准备好接客。
速度会影响：
你不需要做 50 项微优化。对于大多数入门站点，最大的改进通常来自这几项：图片、过多的 JavaScript/CSS、第三方小部件，以及服务器/主机响应时间。
本指南侧重于实用、低风险的步骤，能提升真实世界的页面加载速度，尤其是移动端体验。它不会深入高级主题，比如重写应用架构、构建自定义缓存层，或为大型工程团队制定性能预算。目标是帮助你完成并验证可执行的改动，而不破坏站点。
当人们说“我的站点很慢”时，通常是指三类感受：主要内容出现得晚、页面交互迟缓，或布局不断跳动。Google 的 Core Web Vitals 很好地对应了这些抱怨。
LCP（Largest Contentful Paint）： 衡量最大“主要”内容（通常是英雄图或标题块）出现所需的时间。如果 LCP 高，用户就会看着一个基本为空的页面。\n\nINP（Interaction to Next Paint）： 用户交互（点击、触摸、输入）后页面做出响应的快慢。如果 INP 高，站点会感觉卡顿—按钮反应慢、菜单打开有延迟。\n\nCLS（Cumulative Layout Shift）： 页面在加载过程中跳动的程度。如果文字移动导致误触按钮，这就是 CLS 的问题。
TTFB（Time to First Byte） 是指服务器（以及中间环节）开始返回任何内容所需的时间。TTFB 慢会拖累后续所有步骤：图片无法开始下载、字体无法加载，LCP 通常会变差。TTFB 问题常指向主机、后端工作量大或缺失缓存。
实验室测试（如 Lighthouse）在固定条件下模拟页面加载。它们适合用于调试和前后比对。
真实用户数据（通常称为“field data”，例如 PageSpeed Insights 中的 CrUX）反映了真实访客在不同设备和网络下的体验。回答“真实用户感觉快吗？”时，这才是最重要的指标。
如果在没有基线的情况下开始“优化”，很容易浪费时间——甚至无意中让站点更慢。用 20 分钟先测量一次，这样你就知道哪些改动真正有效。
使用 PageSpeed Insights 做一个快速快照。它会报告 field data（真实用户体验，当可用时）和 lab data（模拟测试）。注意：
更深入的实验室测试可以在 Chrome 中运行 Lighthouse：
当你需要看清楚“是什么”在拖慢页面时，使用 /www.webpagetest.org/ 的瀑布图是最直观的工具之一。瀑布图显示每个文件的加载顺序——HTML、图片、字体、脚本和第三方标签——以及浏览器在何处等待。
从一个关键页面开始（首页或重要落地页），测试：
为每次测试记录：
做一个小日志（表格就行）：日期、工具、URL、结果以及变更内容。每次只改一到两项，然后在相同条件下复测。
如果你在维护一个可迭代的应用（而非静态站点），最好有一个安全的方式来发布并回滚性能实验。像 Koder.ai 这类平台（可以从聊天工作流生成并托管 React/Go 应用）有用之处，因为你能拍快照、测试改动并在需要时快速回滚，如果某个“提速优化”意外破坏了 UX，这会很重要。
慢页面通常不是某个神秘问题导致的，而是几个常见的“体量与延迟”问题叠加——在移动端尤其明显。
图片通常是页面中最“重”的部分。一个错误导出的英雄图可能增加数 MB 和数秒加载时间。
常见问题包括：
JavaScript 会延迟页面变得可用。即便页面“显示出来”了，脚本在后台加载解析执行也会让页面感觉迟钝。
第三方脚本是常见罪魁：聊天小部件、弹窗、热图、A/B 测试工具、广告标签和社交嵌入。每个脚本都可能增加网络请求并占用浏览器主线程时间。
有时浏览器在开始加载页面前一直在等你的服务器响应，这通常表现为慢的初始响应（TTFB）。原因可能是主机性能不足、数据库繁忙、未优化的主题/插件，或每次访问都动态构建页面。
如果你的网站让每次访问都从零开始，回访用户和缓存失效的访客会被惩罚。没有缓存意味着服务器不断重建页面，浏览器也重复下载不常变的文件。
此外，很多小文件（字体、脚本、样式、追踪脚本）会产生“请求开销”。即使每个文件很小，累计的等待时间也很多。
好消息是：这些原因都是可以修复的——通常按照上面顺序解决，会得到最大的收益。
如果只能做一项性能改进，请做图片优化。对很多入门站点来说，图片占了页面下载“重量”的大头，尤其在移动端。更好的是：图片优化通常安全、快速，而且不需改动设计。
常见错误是上传一张巨图（例如 4000px 宽）却在页面上以 800px 显示。浏览器仍需下载大文件。
尽量导出接近页面实际最大显示尺寸的图片。例如如果文章区域是 800px 宽，就没必要上传 3000–4000px 的图片。
JPEG 和 PNG 仍然可用，但现代格式在相同视觉质量下通常更小。
如果你的 CMS 或图片插件能自动提供 WebP/AVIF 并带回退格式，那是最理想的。
压缩往往带来最多的即时加载时间收益。一张“视觉上无差别”的图片常常能减少 30–70% 的体积。
同时删除拍摄相关的元数据（相机信息、位置数据），这些不会影响视觉但会增加字节数。
实用规则：压缩到能看到明显质量下降的那一层，然后回退一级。
srcset）区分移动与桌面移动端不应下载桌面尺寸的图片。响应式图片让浏览器根据屏幕宽度选择合适的尺寸。
如果你的站点能自动生成多个尺寸，请确保主题正确使用这些尺寸。你要在页面 HTML 中看到 srcset（多个版本），而不是只提供一个巨大的文件。
在进入更高级的调优（比如压缩代码）前，先对主要图片做审核：
持续做好这四点，你的网站速度和页面加载时间通常会立即改善——常常能把 Core Web Vitals 往好的方向推。
懒加载意味着页面会延迟下载一些图片（有时是 iframe），直到它们接近可视区域再加载。这样可以减少首屏的下载工作量，尤其适用于包含大量下方图片的长页。
懒加载最适合：
合理使用时，它能减少首屏的工作量，让页面感觉更快。
首屏最大的图片通常是英雄图。如果对它懒加载，浏览器可能很晚才请求它，导致 LCP 变差。
经验法则：绝不要懒加载主英雄图或首屏的关键内容（标题图片、主要商品图、顶部横幅）。
懒加载可能会在图片出现时造成布局跳动。为防止 CLS，务必保留空间：
width 和 height，或\n- 使用固定宽高比的 CSS这样页面在图片加载时布局保持稳定。
如果首屏的图片或字体对第一印象至关重要，可以考虑预加载，让浏览器尽早获取。但要节制——预加载过多会抢占带宽，适得其反。
如果你想按清单操作，把这一步和 /blog/how-to-measure-site-speed-before-you-change-anything 中的测量步骤配合起来做效果最好。
缓存是浏览器说“我已经下过这个文件了，可以复用吗？”的一种方式。若能在一段时间内复用本地副本，下次访问就不必再次下载同样的 logo、CSS 文件或 JavaScript 包，这会让回访显著更快并节省流量——移动端尤其明显。
当服务器发送文件（如 styles.css 或 app.js）时，可以同时发送该文件可复用的时间指示。如果浏览器被允许保留 30 天，那么用户下次访问时这些文件就直接从设备加载，而不是从服务器下载。
这对首次访问没有魔法般的提升，但能显著加快：
静态文件是指不会每分钟改变的东西：图片、CSS、JavaScript、字体。它们非常适合较长的缓存时间。
概念上你想要的是：
你的主机、CMS 或框架可能提供“静态资产缓存”开关。如果与开发者协作，要求他们为静态资源设置合适的 Cache-Control 头。
常见担忧是：“如果我们把文件缓存一个月，用户明天怎么能拿到更新？”解决方法是 版本化文件名。
不要一直复用 app.js，构建流程（或开发者）可以输出诸如：
app.3f2a1c.js\n- styles.a81b09.css当内容变化时文件名也变化，浏览器会把它当作新文件并立即下载——同时仍安全地缓存旧版本。
Service worker 能把缓存进一步推进，让站点控制哪些文件何时存储，有时还能实现离线功能。但如果实现不当，也会带来“陈旧内容”的困惑。对于初学者，把 service worker 视作高级选项——当你有明确目标并且有人维护时再使用它。
CDN（内容分发网络）是一组分布在不同地区的服务器，可以从离访客更近的节点交付文件。这样并非所有请求都要回到你单一的主机服务器，很多请求可以在“附近”被处理。
CDN 最擅长加速 静态资产——不会在每个请求变动的东西，如图片、CSS、JavaScript、字体和视频。这些文件可以被复制到 CDN 的服务器并被多个访客复用。
受益最多的场景：访客分布在多个城市/国家、媒体文件较多、或开展面向全球的付费推广时。
距离会增加延迟。如果服务器在一个国家而访客在另一个大洲，每个请求都更慢。CDN 通过从靠近访客的边缘节点提供缓存文件来减少这一延迟，通常能改善页面加载时间，并在移动网络上帮助提升 Core Web Vitals。
配置错误的缓存头可能导致完全不缓存（或缓存时间过短）。相反的问题是缓存过期：你更新了文件但访客仍拿到旧版本。为避免这种情况，使用带版本号的文件名（例如 app.1234.js）并学会使用 CDN 的清除（purge）功能。
CDN 不是替代修复大图、臃肿脚本或慢主机的办法——但在基础做好之后，它可以大幅提升效果。
CSS 和 JavaScript 常常是“看不见的重量”，会让页面变慢。与图片不同，这些问题不一定可见，但浏览器仍需下载、解析并执行这些文件，才能让页面变得可用。
压缩会移除空格、注释和格式化，通常能让文件更小、更快下载。
它改变的是文件大小；它不会改变浏览器解析和执行代码所需的工作量。如果脚本在加载时做了大量工作，压缩无法解决这一点——所以把压缩看作一个快速胜利，而不是终极解决方案。
许多站点加载“通用样式表”，其中包含当前页面不使用的规则。额外的 CSS 仍然会被下载并可能拖慢渲染。
实用方法：
目标很简单：主页不应承载整个站点的所有样式重量。
defer 或 async有些脚本会阻塞页面变得可交互，因为浏览器会等待它们运行完。
defer，让它们在 HTML 解析后运行。\n- 对彼此独立的脚本，使用 async。如果不确定，先把非首屏所需的脚本都设置为 defer（菜单、动画、滑块、额外的追踪脚本）。
大库会增加数百 KB 甚至更多。在添加插件或框架前问自己：
更少的脚本通常意味着更少的意外，尤其在移动端 CPU 时间和执行成本很重要时。
第三方脚本是指你从别家公司服务器加载的任何脚本。它们能快速增加功能，但也可能成为页面加载时间中最不可预测且最沉重的部分。
最常见的种类包括：
这些脚本常常下载额外文件、执行大量 JavaScript，并且有时会阻塞浏览器完成页面加载。
打开 Chrome DevTools → Performance，录制一次页面加载，留意：
也可以运行 Lighthouse 并查看“Reduce JavaScript execution time”（减少 JS 执行时间）和“Eliminate render-blocking resources”（消除渲染阻塞资源）等建议。
一些对初学者友好的做法：
不要在页面加载时直接插入完整的 YouTube/Facebook/地图嵌入，改为显示一个简易预览（缩略图 + 播放按钮）。只有用户点击时才加载真实嵌入。
这能保持页面对每个人都更快——尤其是移动端——同时不去掉功能。
TTFB（首字节时间）是浏览器请求页面后服务器开始响应所需的时间。把它想象成“厨房开始做饭前等待的时间”，不是上菜的总时长。
即使网站看起来优化得很好，如果 TTFB 高，页面仍会感觉慢——在移动网络上每一段延迟都更明显。
TTFB 主要与服务器端在发送任何内容前所做的工作有关：
即便你的图片和脚本都已优化，服务器响应慢仍会让浏览器空等。
如果你的站点由 CMS 构建或每次都动态生成页面，服务器端缓存通常能带来最大的 TTFB 改善。服务器可以存储准备就绪的页面副本，而不是为每个访客重新构建。
实用示例：
对 HTML、CSS、JavaScript 等文本类文件启用 Brotli（首选）或 Gzip 压缩，这能减少网络传输的数据量，改善感知速度——尤其对回访和移动端用户明显。
更好的主机确实能降低 TTFB，但最聪明的做法是先修复明显的前端问题（巨大的图片、臃肿的脚本、过多第三方脚本）。如果浏览器还在下载大量资源，更快的主机并不能让体验真正变快。
在把基础问题处理好后，升级主机（更多 CPU/RAM、调优的数据库、更好的运行时性能）通常是让站点在不同区域表现更流畅的最后一步。
如果你从一开始就希望主机变量少且默认配置合理，可以考虑使用托管平台。例如 Koder.ai 在全球的 AWS 上托管应用，支持部署、自定义域和环境回滚—当你跨区域测试性能或需要满足数据驻留时会很有用。
你不需要一个庞大的项目计划来提升网站速度。需要的是一个简单的执行顺序、验证改动没有带来回归的方法，以及偏向于那些可靠降低页面加载时间的修复。
第 1 天：测量（先测再动）。
选 2–3 个重要页面（首页、关键落地页、热度高的文章/商品页），运行：
记录移动端和桌面的基线。如果可以，在真实手机上用蜂窝网络测试——这通常会揭露实验室测试忽略的问题。
第 2–3 天：优化图片（最快且最可靠的改进）。
优先事项：
只更新几张图片后复测，观察影响。
第 4–5 天：启用缓存（让回访更快）。
开启基础的浏览器缓存和服务器/页面缓存。目标是不要在每次访问时都重新生成或重新下载相同的资源。启用后验证回访能明显更快。
第 6–7 天：剪裁 JavaScript（长期收益最大）。
查找：
这里的小改动能显著提升交互性和 Core Web Vitals，尤其在移动端。
在每次重大改动（图片、缓存、脚本）后做三项快速检查：
如果你已经优化了图片和缓存，但仍看到持续高的 TTFB，通常指向主机/服务器设置、慢数据库或后端负载过重。如果站点是复杂应用（会员、市场、大量个性化），“直接缓存”可能不够，这时考虑寻求专业支持。
如果你想看更深入的服务器响应时间指导，可以参考 /blog/ttfb-explained。
网站速度通常指两件事：
页面看起来“加载完”但如果 JavaScript 正在忙或布局不断移动，仍然会感觉慢。
Core Web Vitals 对应常见的用户抱怨：
改善这些指标通常会提升真实的感知速度，而不只是得分。
作为实用目标：
把它们看作方向性目标——优先改善最差的指标。
先做基线测试，别盲目优化：
记录设备、网络、位置和精确 URL，每次只改 1–2 项然后复测。
常见的主要原因是：
按这个顺序修复通常能最快取得效果。
因为图片常常是页面中体积最大的部分，并且直接影响下载时间和 LCP。重点在四个基础点：
srcset），让移动端下载更小的版本。这些改动风险低且通常能立刻看到效果。
Lazy loading 对首屏之外的大量内容非常有用，但要注意不要把关键首屏内容延迟加载。
实用规则：
width 和 height 或使用固定宽高比的 CSS）。如果某个资源对首屏至关重要，可考虑使用预加载，但不要过度预加载以免争占带宽。
缓存让浏览器在一段时间内重用已经下载的文件，从而让回访变得明显更快：
app.3f2a1c.js）以便长时间缓存时仍能快速发布更新。正确配置后，缓存能显著减少重复下载和服务器负担。
当你的访客分布在不同城市/国家，且你有大量静态文件时，CDN 的帮助最大。它擅长于：
注意事项：
CDN 不是替代优化图片或脚本的手段，但在基础打好之后，它能很好地放大收益。
一个可执行的简单顺序，能在一周内带来明显改进：
每步后按相同条件复测并在站点上手动操作以确保没有破坏可用性。