图片与静态资源优化
很多网站“看起来不复杂却很慢”，根因不是框架，而是静态资源管理太粗糙。
最常见的问题
- 图片原图直接上站
- 首页放了太多大图
- 同一资源存在多个重复版本
- 字体体积过大
- 缓存策略不统一
先把资源分成几类
图片
最常见、也最容易失控。
字体
常常被忽略，但体积不小。
CSS / JavaScript
主要影响请求数量和首屏加载。
下载资源
如 PDF、压缩包等，通常适合单独考虑缓存和存储路径。
图片优化最值得先做什么
1. 先降尺寸，而不是只降质量
很多图片之所以大，不是格式问题，而是像素尺寸远超展示尺寸。
2. 按场景准备不同版本
- 封面图
- 文章插图
- 缩略图
- 作品展示图
不要一张原图包打天下。
3. 格式尽量适配网页
对于普通网页展示，优先考虑更适合 Web 的格式和压缩方式。
静态资源管理要尽量统一
建议至少做到：
- 命名规则清楚
- 存放目录清楚
- 公共资源和页面专属资源区分清楚
- 大文件不要混在页面源码里随意散放
为什么资源优化和缓存绑定在一起
因为资源一旦适合长期缓存，你就应该考虑：
- 是否有版本号或内容哈希
- 更新后旧缓存怎么失效
- CDN 是否会继续回旧版本
ESA 预热清单
本站使用 ESA 时，图片、音频、PDF 和构建产物都可以提前预热。预热文件统一生成到 cache-preheat/，这个目录已经加入 .gitignore，只作为本地上传 ESA 控制台的临时产物，不进入 Git 提交。
OSS 资源使用下面的命令生成：
npm run generate:oss-preload
脚本会扫描 docusaurus.config.js、sidebars.js、blog/、docs/、i18n/、src/ 和 static/ 中出现的 https://oss.nevergpdzy.com/ 资源链接，并额外处理旅游板块 createTravelPhotos 里的相对图片路径。生成结果写入：
cache-preheat/oss-preload-urls.txt
这个清单面向 OSS 域名本身，覆盖站点引用到的图片、音频和 PDF。脚本会跳过示例占位符，去重，并保证每行都是一个可提交给 ESA 的完整 URL。
构建产物使用下面的命令生成：
npm run generate:build-preload:zh
npm run generate:build-preload:en
构建产物清单面向最终访问域名，分别生成 https://nevergpdzy.com/ 和 https://en.nevergpdzy.com/ 下的 HTML、CSS、JS、JSON、XML 等文件 URL。脚本会同时加入干净页面路由和对应的 index.html 文件 URL，避免用户访问 /docs/intro 时只预热到了 /docs/intro/index.html。
上传 ESA 时保持一行一个 URL。数量较多时优先使用上传 TXT 或定时预热，不要在业务高峰一次性手动提交过大的即时预热任务。
这个仓库里可以复用的专项经验
如果你有 iPhone / HEIF 图片上站需求，可以继续参考这篇专项笔记：
它更偏具体图片处理命令，而这篇更偏“为什么要这样处理”。
最容易踩的坑
1. 首页图一张几 MB
这会直接伤首屏体验。
2. 图片已经压缩，但展示尺寸还是不合理
体积和像素尺寸要一起看。
3. 文件名和目录毫无规则
后期维护、缓存刷新和内容迁移都会变得困难。
一个务实顺序
- 先处理首页和高频页面图片
- 再处理全站公共资源
- 再统一缓存和命名策略
适合接着读什么
- 想看性能总览：看 Web 性能基础：从首屏到缓存策略
- 想发布前检查：看 网站上线检查清单