解读

面试官抛出此题，表面问“技术动作”，实则考察三层能力：

1. 是否能把“速度”拆成可量化的指标（FCP、LCP、TTFB、CLS）；
2. 是否知道国内特有的网络与搜索引擎环境（百度蜘蛛对WebP的识别、备案对CDN节点的影响、工信部对JS外链的合规要求）；
3. 能否把技术动作与SEO收益挂钩——速度提升→抓取配额↑→排名↑→免费流量↑。
   回答时要“先指标、后手段、再验证”，用数据闭环体现SEO思维，而不是单纯罗列前端优化清单。

知识点

1. 图片优化

   • 选格式：国内70%流量仍在移动端，WebP节省30%–70%体积，但需同步提供JPEG兜底并写picture/source标签，保证百度蜘蛛识别；
   • 尺寸响应式：srcset+sizes按屏幕密度（1x/2x/3x）输出，避免统一加载750px图；
   • 压缩工具：国内常用tinify.cn、智图、Squoosh-CLI，目标把单图压到100 KB以内；
   • 懒加载：IntersectionObserver + loading="lazy"，首屏外图片延迟1.5 s加载，降低FCP 0.8–1.2 s；
   • 预加载关键图：preload hero banner，把LCP节点从<img>转成背景图并上CDN，可让LCP缩短20%。

2. CDN

   • 节点备案：国内必须选有“ICP备案节点”的厂商（阿里云DCDN、腾讯云ECDN、百度云加速），否则蜘蛛回源超时导致抓取失败；
   • 智能压缩：开启Brotli（gzip升级）+HTML/JS/CSS一键压缩，可减少25%传输体积；
   • 缓存策略：静态图片缓存1年（hash命名），JS/CSS缓存30天，带版本号即时刷新；
   • HTTP/2+TLS1.3：多路复用+0-RTT，首包时间降低15%–25%；
   • 蜘蛛回源白名单：在CDN控制台加百度、搜狗、360、神马UA，防止“缓存+跳转”双响应造成301链。

3. 代码压缩

   • Tree-Shaking：Webpack 5 sideEffects:false，剔除未调用的npm模块，减少15%–30%包体积；
   • 分包：路由级动态import，首屏JS≤200 KB；
   • 删除console & dead code：terser-webpack-plugin+drop_console:true，百度“清风算法”已把异常console报错当低质信号；
   • 内联关键CSS：把首屏200行以内样式直接写入<style>，减少一次HTTP往返，TTFB缩短100 ms；
   • 服务端渲染（SSR）+同构脱水：让HTML直出带内容，避免蜘蛛看到“白屏”，同时JS包仍可缓存。

4. 监控与验证

   • 用百度统计“速度诊断”+Search Console抓取异常，对比优化前后抓取耗时；
   • 建立Lighthouse CI流水线，MR合并前LCP>2.5 s直接打回；
   • 每周拉取CDN日志，统计状态码200:304比例，确保蜘蛛拿到的90%以上是304缓存命中。

答案

“我会把页面速度拆成三大核心指标：LCP<2.5 s、FCP<1.8 s、CLS<0.1。针对图片，先用WebP+响应式尺寸把体积降60%，首屏外图片统一懒加载，hero图用preload提前加载；CDN层面，选择已备案的阿里云DCDN，开Brotli和HTTP/2，静态资源缓存一年，蜘蛛回源单独白名单，避免抓取超时；代码侧，Webpack 5做Tree-Shaking+分包，首屏JS压到200 KB以内，关键CSS内联，服务端直出HTML。上线后，用百度统计‘速度诊断’对比，LCP从4.1 s降到2.2 s，抓取耗时下降35%，两周后索引量上涨18%，核心关键词排名平均提升6位，带来日均额外1.2万免费UV。”

拓展思考

1. 图片AVIF与WebP取舍：国内部分低端安卓机型不支持AVIF，如何写降级策略并同步到SEO测试环境？
2. CDN与边缘计算结合：用ER（EdgeRoutine）在节点层做SSR，能否进一步把TTFB压到100 ms以内？对蜘蛛抓取预算的影响如何量化？
3. 代码压缩与缓存悖论：文件hash更新导致CDN缓存失效，如何在版本迭代中平衡“即时生效”与“长缓存”？
4. 核心算法更新：百度“劲风算法”已把体验分纳入排名，若速度指标达标但广告占位导致CLS超标，排名仍可能下降，如何统筹“速度-广告-收入”三角关系？