页面加载慢主因是资源加载和渲染阻塞。应内联压缩关键CSS/JS、图片启用loading="lazy"并设宽高、第三方脚本用defer/async或按需加载。
页面加载慢，八成出在资源加载和渲染阻塞上，而不是代码逻辑本身。
压缩并内联关键 CSS 和 JavaScript
浏览器遇到 或 就会暂停 HTML 解析，尤其当这些资源体积大、路径远时，首屏渲染被严重拖慢。不是所有 CSS/JS 都需要外链——首屏必需的样式（如导航栏、标题、按钮基础样式）和逻辑（如用户登录态判断）应提取出来，压缩后内联到 中。
- 用
cssnano或esbuild --minify压缩内容，再手动或通过构建脚本注入 HTML - 内联 JS 要控制体积，超过 2KB 就该考虑异步加载；避免在
中执行耗时操作 - 内联后记得移除对应外链标签，否则资源仍会被重复请求
图片懒加载 + 正确使用 loading="lazy"
页面里大量 loading="lazy" 是最轻量的解法，但只对非首屏图片生效，且不兼容 IE 和旧版 Safari。
- 必须配合
width和height属性，防止懒加载触发时发生布局偏移（CLS） - 首屏图片（如 banner、logo）禁用
loading="lazy"，否则可能被延迟加载，影响 LCP - 若需兼容老浏览器，可用
IntersectionObserver手动实现，但别在DOMContentLoaded前就初始化观察器
避免 render-blocking 的第三方脚本
很多初级项目直接在 里插入统计、客服、埋点 SDK，比如 ，这类脚本一旦加载或执行慢，整个页面渲染就会卡住。
- 把非关键第三方脚本移到
底部，并加上defer（不阻塞解析，按顺序执行）或async（不阻塞，不保证顺序） - 对必须同步使用的脚本（如某些 A/B 测试工具），检查是否提供「按需加载」API，而非一上来就全量载入
- 用 Chrome DevTools 的 Network → Waterfall 查看哪些第三方请求耗时长、是否重定向多、有没有 404，优先剔除或替换掉问题源
真正卡顿的地方往往藏在「看起来无害」的细节里：一个没设尺寸的图片、一段没加 defer 的统计代码、一份没拆分的全局 CSS 文件——它们单个影响微弱，叠加起来就让 FCP 推迟 1.5 秒以上。
