TranslateHub·性能优化·
翻译 API 性能优化：缓存、批量请求与 Core Web Vitals
通过缓存键、批量请求和 SEO 友好的渲染策略，降低翻译延迟与基础设施成本。
翻译速度为什么会影响 SEO？
如果页面必须等浏览器调用翻译 API 才能显示正文，网络延迟会推迟最大内容绘制，还可能在文字返回后改变布局。更稳妥的方案是对可索引页面采用构建时或服务端翻译，直接向搜索引擎与用户返回完整 HTML；实时翻译则用于聊天、用户输入等无需索引的场景。
先把翻译结果缓存成内容资产
稳定缓存键应包含源文本哈希、源语言、目标语言、引擎、模型版本和术语表版本。只使用文本与目标语言容易在切换引擎或更新术语后返回旧结果。成功结果可以设置较长 TTL，失败和限流响应不应进入正常缓存；源内容或术语变化时主动失效。
translation:{source_hash}:{source_lang}:{target_lang}:{engine}:{glossary_version}
批量请求与并发控制要同时设计
批量合并短文本可以减少连接与协议开销，但批次过大会放大超时后的重试成本。按字符数和段落边界组成中等批次，并为每个上游设置独立并发限制。遇到 429 或临时 5xx 时使用带抖动的指数退避，同时记录 request_id，避免无上限重试造成雪崩。
围绕 Core Web Vitals 选择渲染策略
Google 建议关注 LCP、INP 和 CLS。对于翻译页面，最有效的优化通常不是压缩一次 API 请求，而是让首屏内容不依赖这次请求：预生成热门语言页面、在 CDN 缓存完整 HTML、预留文本区域尺寸，并避免加载后替换导航和标题。
- LCP：服务端返回首屏译文，优先加载主图与关键字体。
- INP：不要在主线程串行处理大量翻译结果或 HTML。
- CLS：为标题、按钮和异步模块预留稳定空间。
用数据验证优化是否有效
同时记录缓存命中率、翻译 P50/P95 延迟、上游错误率、单次请求字符数和页面真实用户指标。缓存命中率上升却没有改善 LCP，说明翻译调用可能仍在关键渲染路径上；延迟下降但错误率上升，则要重新评估批次大小与并发限制。
更多缓存键与失效细节可阅读 翻译结果缓存策略。
