网站页面加载速度批量检测：500个URL丢进4个工具跑一遍，免费方案跑得动吗

一个电商网站的运营发过来一个问题：老板让他两天内把全站2000多个产品页面的加载速度全测一遍，给一份报告。他打开PageSpeed Insights，一个一个URL粘贴进去，两个小时测了不到40个，按这速度得测一个星期。问有没有能批量跑的方案。

这个问题太典型了。网站页面加载速度检测，单个页面谁都会——浏览器F12、PageSpeed Insights、Lighthouse，随便哪个都能用。但一旦URL数量超过50个，逐个手动检测就完全不可行。这篇文章把能批量跑的方案——免费和付费的——都过一遍，按URL数量分档，告诉你哪个方案跑得动、哪个会半路翻车。

一、先搞清楚要测什么指标

加载速度不是一个数字能说清楚的。至少分成三组指标，每组用途不同：

不同工具覆盖的指标不一样。有些只给你LCP一个数，有些给你完整的三组指标加优化建议。选工具之前先搞清楚：你要的是"快不快"的结论，还是"哪里慢、怎么改"的诊断。

二、四类批量检测方案，按URL数量对号入座

三、方案一：PageSpeed Insights API，免费方案的主力

Google官方的PageSpeed Insights（PSI）提供了公开API，每天有免费配额。这是零预算批量检测最靠谱的选择。

以一个200个URL的检测任务为例：200个URL × 2种设备（mobile+desktop）= 400次API调用。按每秒1次的限制，需要约7分钟跑完。完全在免费配额内。

不需要写代码也能用。可以用Google Sheets + Apps Script组合：

1. 在Google Sheets的A列粘贴URL列表
2. 打开扩展程序 → Apps Script，粘贴以下代码
3. 运行脚本，结果自动写入B~K列

function batchPageSpeed() {var sheet = SpreadsheetApp.getActiveSheet();var urls = sheet.getRange('A2:A').getValues().filter(String);var results = [];for (var i = 0; i < urls.length; i++) {var url = encodeURIComponent(urls[i][0]);var apiUrl = 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url='+ url + '&strategy=mobile&key=你的API_KEY';try {var response = UrlFetchApp.fetch(apiUrl);var data = JSON.parse(response.getContentText());var lhr = data.lighthouseResult;results.push([lhr.audits['largest-contentful-paint'].displayValue,  // LCPlhr.audits['first-contentful-paint'].displayValue,     // FCPlhr.audits['cumulative-layout-shift'].displayValue,    // CLSlhr.audits['total-blocking-time'].displayValue,        // TBTlhr.audits['speed-index'].displayValue,                // Speed Indexlhr.audits['server-response-time'].displayValue,       // TTFB(lhr.audits['performance-score'] || {}).score * 100    // 性能分]);} catch(e) {results.push(['ERROR', '', '', '', '', '', '']);}Utilities.sleep(1500); // 每秒不超过1个请求，留余量}sheet.getRange(2, 2, results.length, 7).setValues(results);}

如果URL数量超过500个，Google Sheets脚本会因为执行时间限制（6分钟）而中断。这时候就要用方案三的Python脚本了。

四、方案二：付费SaaS平台，省心但有成本

如果你的检测是持续性的——比如每周跑一次整站、发现性能退化就告警——付费SaaS是最省心的选择。不需要维护脚本，不需要处理API配额，打开网页就能看到历史趋势图。

GTmetrix

GTmetrix的批量监测功能在Pro计划（约$15/月）里开放。核心能力：

• 批量URL监测：导入URL列表，设置检测频率（每天/每周/每月）
• 多地域节点：可选择不同国家的测试服务器（美国、加拿大、英国、澳大利亚、印度、巴西等）
• 设备模拟：手机/平板/桌面端分别测试
• 性能趋势图：每个URL的历史性能变化曲线，一眼看出哪天开始变慢
• 告警通知：LCP超过阈值或性能分下降时自动发邮件/Slack通知
• PDF报告导出：每个URL可导出带GTmetrix品牌的专业报告，直接发给客户

SpeedCurve

SpeedCurve定位更高端（$90/月起），但它的仪表盘和竞争对比功能是其他工具没有的：

• 竞争对手对比：把你的网站和竞争对手的网站放在同一张图上比LCP趋势，老板最爱的功能
• 预算仪表盘（Performance Budget）：设定每个页面的性能预算（如LCP<2s，总大小<500KB），超标自动告警
• RUM数据（真实用户监测）：不是实验室数据，而是真实用户在你网站上的加载体验数据
• 与Lighthouse深度集成：数据来源就是Lighthouse，和PSI API口径一致

DebugBear

DebugBear（约$99/月起）的特色是可以和Google CrUX数据对比。CrUX是Google从Chrome浏览器真实用户收集的性能数据，DebugBear能告诉你：你的LCP在同类网站中排第几百分位？比行业平均水平快还是慢？这个对比维度对客户报告非常有说服力。

五、方案三：Python脚本 + Lighthouse，免费且不限量

如果你的URL数量超过500个、或者需要完全自定义报告格式、或者不想受任何第三方平台限制，这是终极方案。

核心思路：用Node.js的Lighthouse库（Google官方）在本地跑检测，Python脚本负责管理URL队列、调度并发、汇总结果到Excel。

# Python 调度脚本 batch_speed_test.pyimport subprocessimport jsonimport pandas as pdimport timefrom concurrent.futures import ThreadPoolExecutor, as_completedURLS = ["https://example.com","https://example.com/products/1","https://example.com/products/2",# ... 把你所有的URL放这里]def run_lighthouse(url, index):"""对一个URL运行Lighthouse检测"""output_file = f"result_{index}.json"cmd = ["lighthouse", url,"--output=json","--output-path=" + output_file,"--chrome-flags=--headless --no-sandbox","--only-categories=performance","--quiet"]try:subprocess.run(cmd, check=True, timeout=120)with open(output_file, 'r', encoding='utf-8') as f:data = json.load(f)audits = data['audits']return {'url': url,'performance_score': data['categories']['performance']['score'] * 100,'lcp': audits['largest-contentful-paint']['numericValue'],'fcp': audits['first-contentful-paint']['numericValue'],'cls': audits['cumulative-layout-shift']['numericValue'],'tbt': audits['total-blocking-time']['numericValue'],'si': audits['speed-index']['numericValue'],'ttfb': audits.get('server-response-time', {}).get('numericValue'),'total_requests': audits.get('network-requests', {}).get('details', {}).get('items', [])}except Exception as e:return {'url': url, 'error': str(e)}def main():results = []# 最多2个并发，本地机器扛不住太多Chrome实例with ThreadPoolExecutor(max_workers=2) as executor:futures = {executor.submit(run_lighthouse, url, i): urlfor i, url in enumerate(URLS)}for future in as_completed(futures):result = future.result()results.append(result)print(f"完成: {result.get('url', 'N/A')}")# 导出到Exceldf = pd.DataFrame(results)df.to_excel('batch_speed_report.xlsx', index=False)print(f"\n检测完成，共{len(results)}个URL，报告已保存到 batch_speed_report.xlsx")if __name__ == "__main__":main()

如果想解决第二个问题（网络环境偏差），可以把脚本部署到一台境外云服务器（AWS/GCP/Azure）上跑，测试结果更接近海外用户的真实体验。一台最低配的云服务器每月也就几美元。

六、方案四：WebPageTest，深度诊断的首选

WebPageTest是比Lighthouse更底层的检测工具。Lighthouse告诉你"LCP是3.2秒"，WebPageTest能告诉你"这3.2秒里，DNS解析花了0.2秒、TCP连接花了0.3秒、SSL握手花了0.15秒、第一个字节花了0.8秒、剩下的1.75秒是下载和渲染"。这种颗粒度对于定位性能瓶颈非常关键。

WebPageTest也提供API，可以在Python脚本里调用。免费计划每天可以跑一定数量的测试，付费计划（约$15/月）可以跑更多。

# WebPageTest API 批量检测import requestsimport timeAPI_KEY = "你的WPT_API_KEY"URLS = ["https://example.com", "https://example.com/page2"]def submit_test(url):"""提交测试，返回testId"""endpoint = "https://www.webpagetest.org/runtest.php"params = {"url": url,"k": API_KEY,"f": "json","location": "ec2-us-east-1:Chrome",  # 可选不同测试节点"runs": 3  # 每个URL跑3次取中位数}resp = requests.get(endpoint, params=params)return resp.json()["data"]["testId"]def get_results(test_id):"""轮询获取结果"""endpoint = f"https://www.webpagetest.org/jsonResult.php?test={test_id}"while True:resp = requests.get(endpoint).json()if resp["statusCode"] == 200:return resp["data"]time.sleep(5)# 批量提交test_ids = {url: submit_test(url) for url in URLS}# 逐个获取结果for url, tid in test_ids.items():data = get_results(tid)median = data["median"]["firstView"]print(f"{url}: TTFB={median['TTFB']}ms, LoadTime={median['loadTime']}ms")

七、500个URL实战跑一遍，各方案效率对比

用同一个测试URL池（500个电商产品页面，涵盖列表页、详情页、搜索页、静态页），分别跑了四种方案，结果如下：

八、持续监控 vs 一次性检测，工具选法完全不同

很多人一开始想的是"我就测这一次，看看现在哪些页面慢"，但实际跑完一次后会发现：最值钱的不是"当前哪里慢"，而是"这周比上周慢了没"。

加载速度的退化通常是渐进的——今天加了1个插件、明天上了1张没压缩的大图、后天改了1个CSS文件——每次只慢几十毫秒，单次检测看不出问题。但一个月累积下来LCP从1.8秒变成3.5秒，Google排名已经开始掉了。

所以选方案时要区分两种场景：

如果你的需求是一半一半——平时需要持续监控20个核心页面，偶尔需要一次性跑全站500个页面——那最佳组合是：GTmetrix Pro监控核心页面 + PSI API脚本跑全站。总成本$15/月，两边都覆盖。

九、批量检测结果怎么用，不是跑完就完了

花了时间跑完500个URL的检测，拿到一份Excel报告，然后呢？

三个实用的用法：

十、检测时容易忽略的三个变量

同一条URL，不同时间、不同地点、不同设备跑出来的结果可能差一倍。不是工具不准，是这三个变量在影响结果：

最后说一句。批量页面速度检测这件事，工具本身不是瓶颈——PSI API免费、Lighthouse开源、WebPageTest免费额度也很慷慨。真正的差距在两点：能不能定期跑（不是跑一次就忘了），和跑完有没有人看报告去修。测1000个URL发现50个慢的，然后Excel放在文件夹里三个月没打开，这1000次检测就白跑了。最好的方案是：选一个能自动定期跑的方案，把报告钉在团队周报里，每次发布新版本之前跑一次全站——这才是把检测工具用到点子上了。