直接结论：用 selenium 或 playwright 获取 performance.timing 指标最可靠，requests 只能测到 ttfb，无法反映真实用户看到的“页面加载完成”时间。因为 requests 不执行 js、不解析 html、不加载资源，仅测服务器响应与传输耗时，而浏览器实际加载需经历 dom 构建、资源加载、渲染等完整流程；selenium 和 playwright 可通过执行 js 读取 performance.timing 精确指标，并支持模拟网络条件、控制缓存、监听加载事件，真正贴近用户视角。
直接结论：用 Selenium 或 Playwright 获取 performance.timing 指标最可靠，requests 只能测到 TTFB，无法反映真实用户看到的“页面加载完成”时间。
为什么不能只用 requests.get() 测网页加载速度
很多人一上来就写 time.time() 包住 requests.get(url)，结果发现数值很小（比如 0.2 秒），但用户反馈“白屏好几秒”。这是因为：
-
requests只发 HTTP 请求、收响应头+响应体，不执行 HTML 解析、不加载 JS/CSS/图片、不触发 DOM 构建 - 它测的是服务器响应时间（TTFB + 内容传输），不是浏览器渲染完成时间
- 完全忽略前端资源加载、执行、重排重绘等关键耗时环节
除非你只关心后端接口性能，否则这个数字对“网页加载速度”没有参考价值。
Selenium 中正确读取 performance.timing 的要点
浏览器原生的 window.performance.timing 提供了 20+ 个精确时间戳，但直接读取容易出错。关键点：
- 必须等页面真正加载完成后再执行脚本，否则
loadEventEnd等字段可能为 0 —— 建议用driver.execute_script("return window.performance.timing.loadEventEnd")配合显式等待 -
fetchStart是导航起点，比navigationStart更准确（后者在某些重定向场景下会重置） - DOM 就绪时间建议用
domContentLoadedEventEnd - fetchStart，而非domComplete（后者包含子资源加载） - 返回值是毫秒级整数，Python 接收后需转成
int，否则后续统计（如取平均）会报类型错误
示例片段：
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
dom_ready_ms = driver.execute_script("""
const t = window.performance.timing;
return t.domContentLoadedEventEnd - t.fetchStart;
""")
Playwright 禁用缓存并获取完整加载指标更简单
相比 Selenium，Playwright 在控制缓存和捕获加载事件上更干净：
- 新建
context时直接加ignore_https_errors=True和bypass_csp=True，避免因证书或 CSP 导致 JS 执行失败 - 用
extra_http_headers={'Cache-Control': 'no-store'}强制绕过所有缓存，不用手动清空或开新窗口 - 支持原生监听
page.on('load')和page.on('domcontentloaded')，比轮询 JS 更稳定 - 可直接用
page.evaluate()读取performance.getEntriesByType('navigation')[0]，拿到loadEventEnd、domComplete等字段
注意：如果测试环境有代理或中间件拦截请求头，Cache-Control 可能被删掉，此时得配合服务端日志确认是否真没走缓存。
真实用户视角下最容易被忽略的三个细节
很多脚本跑出来数据“看起来正常”，但和真实监控（如 RUM）对不上，问题常出在这三处：
- 没模拟真实网络条件 ——
Chrome DevTools的 “Slow 3G” 或 Playwright 的set_network_conditions()必须启用，否则本地千兆网测出的 1.2s 对弱网用户毫无意义 - 没处理重定向链 —— 如果 URL 302 跳转了两次，
navigationStart是第一次跳转前的时间，但用户感知是从输入地址开始，应以performance.getEntries()[0].startTime（首个资源）为基准 - 没区分首次访问 vs 重复访问 —— 缓存行为差异极大，必须明确标注测试是
no-cache还是with-cache，且两者不能混在同一组报告里
最终生成的报告里，至少要带这三项：网络条件标识、缓存策略说明、时间基准定义（比如“从 fetchStart 到 loadEventEnd”）。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
