Wikimedia Foundation 近日完成了一项重大基础设施优化：将所有维基项目的移动子域（如 en.m.wikipedia.org）迁移至主域（如 en.wikipedia.org）。这一变革源于 Google 移动优先索引的演进，以及长期存在的重定向开销问题。通过在 CDN 层实现设备感知变体响应（variant response），Wikimedia 消除了移动用户访问时的 HTTP 301/302 重定向，直接从主域返回移动优化 HTML，从而显著提升性能、一致性和运维效率。
变革背景与痛点
历史上，Wikimedia 自 2011 年部署 MobileFrontend 扩展以来，使用 m. 子域为移动设备提供优化视图。桌面用户访问 wiki.org 时正常响应，而移动设备（如 Android/iOS）则被重定向至 m.wiki.org。该机制虽在 2008 年低风险实验时实用，但 17 年后已成瓶颈：
- 性能拖累：重定向引入 100-700ms 延迟（视地区而定）。2024 年 5 月 Google 停止直接链接移动域，导致 Google 引流（占 60% 页面浏览）的移动用户额外承受重定向，全球 p50 响应时间恶化 22%（0.27s → 0.33s）。
- SEO 风险：Google 新爬虫（mobile-first）跟随重定向后读取 canonical 元数据（指向主域），形成循环，导致页面脱索引。Commons 项目中，1400 万页中 2000 万页被 delist，每月增长 100 万。
- 运维负担：MediaWiki 编辑后 purge 缓存时，MobileFrontend 双倍生成 purge 请求（主域 + 移动域），峰值达 30 万/秒，占 CDN purge 总量的 50%。
- 用户体验不一致：移动分享链接强制 m. 域，桌面用户需手动切换；跨设备 Cookie 受跨域限制，无法无缝同步登录/偏好。
这些痛点通过 RFC（T360000）讨论确认，推动统一域迁移。
技术实现要点
核心是 Wikimedia CDN（基于 Fastly）的设备感知响应，无需修改 MediaWiki 核心或前端代码。关键参数与清单如下：
-
CDN VCL 配置（Variant Response）：
- 使用
user-agent 头检测移动设备（匹配 MobileFrontend 的 regex，如 Android/iOS/Opera Mini）。
- 设置
beresp.via = "wikimedia-cdn-variant"，缓存键包含变体标识：cache_key = hash(req.url.path + req.http.user-agent + "-mobile")。
- 响应头注入：
X-Amp-Url（可选 AMP 回退）、Link: <主域>; rel="canonical"。
- TLS：主域通配证书（*.wikipedia.org）覆盖 m. 子域，无需额外 cert；启用 HTTP/2 + OCSP stapling，阈值：证书有效期 < 30 天告警。
-
重定向策略：
- 移动访问主域：直接变体响应（无 3xx）。
- 遗留 m. 域访问：全域 301 永久重定向至主域（.htaccess 或 VCL：
if (req.http.host ~ "^(.*)\.m\.(.*)$") { return(synth(301, "https://" + re.group.1 + "." + re.group.2)); }）。
- 桌面访问 m. 域：同上，确保一致。
- 超时参数：重定向 TTL 1 年，监控 5xx 率 < 0.01%。
-
Cookie 与会话统一：
- Cookie 域从
.m.wikipedia.org 扩展至 .wikipedia.org，支持跨设备共享（登录、watchlist）。
- 参数：
Set-Cookie: mwuser-session=...; Domain=.wikipedia.org; Secure; HttpOnly; SameSite=Lax; Max-Age=2592000（30 天）。
- 迁移：渐进 rollout，先 opt-out 重定向（User-Agent 白名单），后全量。
-
监控与回滚阈值：
- 指标：responseStart（Navigation Timing API）、TTFB、Core Web Vitals（LCP/CLS/FID）。
- 警报：p75 responseStart > 0.5s（全球）、>1s（新兴市场）。
- Perf 仪表盘：Grafana + Phab T405429，A/B 测试前后对比。
- SEO：Google Search Console 索引页数、点击量；爬虫预算监控（crawl-stats）。
- 基础设施：purge 率降 50%（4B/日），峰值 < 20K/s。
- 回滚：VCL 版本回退 < 5 分钟，影子流量测试（5% 用户）。
rollout 分阶段：2025 年 8 月 Commons 测试（Google 引流 +100%），9 月小维基，10 月 8 日 enwiki 全量。无重大中断，移动 p80 响应降 18%（0.73s → 0.60s）。
可落地参数与清单
为类似项目落地，提供工程化 checklist：
| 阶段 |
行动项 |
参数/阈值 |
工具 |
| 准备 |
CDN 支持变体 |
UA 检测准确率 >99% |
Fastly/Cloudflare VCL 测试 |
|
Sitemap 启用 |
每日生成，<1GB/域 |
MediaWiki Sitemap API (T396684) |
| 测试 |
影子流量 |
1-5% 移动 UA |
Phab A/B，Grafana |
|
SEO 验证 |
索引恢复 >90% |
GSC，sitemap.xml 提交 |
| 部署 |
渐进 rollout |
10% /维基/周 |
wgMobileUrlTemplate 弃用 |
| 监控 |
性能 |
TTFB <200ms p95 |
web-vitals.js，NavTiming |
|
Infra |
Purge < baseline 40% |
CDN 日志，Prometheus |
| 优化 |
Cookie 迁移 |
SameSite=Lax，30 天 TTL |
Fiddler/浏览器 DevTools |
风险控制：预热缓存（pre-warm top 1M 页）、爬虫 UA 白名单（Googlebot-Mobile 无重定向）。
收益量化
- 性能：全球移动响应 +20%，Persian wiki 0.25s 降幅。
- SEO：Commons Google 引流翻倍（3M →6M 周 PV），视频页索引恢复。
- Infra：purge 减 4B/日，负载降 20-40%。
- UX：统一分享链接，跨设备无缝（Cookie 共享）。
此统一不仅是技术升级，更是适应现代 CDN/搜索引擎范式的典范。未来，考虑 AMP 集成或 PWA，提升离线能力。
资料来源：