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,提升离线能力。
资料来源: