Scrapling 与 Playwright 对比：网页解析工具的正确选型

Scrapling 与 Playwright 对比：网页解析工具的正确选型

作者：浅木·先生

2026年6月16日

一、引子：一条朋友圈引发的"圣战"

上个月，有个前同事在朋友圈转发了一篇文章，标题赫然写着：“比Playwright快784倍，这个Python库把网页自动化玩出了新高度”。

评论区炸了。支持Scrapling的说"早该抛弃Playwright这个吃内存的怪物"，支持Playwright的说"784倍是偷换概念，拿Scrapling的HTML解析跟Playwright的完整浏览器渲染比速度，这不是耍流氓吗"。

我当时没参与争论，但心里记住了这件事。作为一个长期在财政系统做网页数据采集的人，我太清楚"选错工具"的代价了——不是多花几天时间的问题，而是整个系统架构推倒重来、生产环境数据管道瘫痪的那种惨痛教训。

所以这篇文章不打算站队，而是试图回答一个务实的问题：在真实的业务场景下，Scrapling 和 Playwright 分别应该什么时候用？

二、两个工具的基本画像

在深入对比之前，先对两个工具有一个清晰的认知。

2.1 Playwright：浏览器自动化的事实标准

Playwright 是微软在2020年开源的一个浏览器自动化框架，支持 Chromium、Firefox、WebKit 三大浏览器引擎。它最初的目标是端到端测试，但因为 API 设计优雅、生态成熟，很快被爬虫开发者广泛采用。

关键数据：

• GitHub Stars：71,000+（截至2026年中）
• 语言：Python、JavaScript/TypeScript、Java、.NET
• 定位：完整浏览器自动化框架
• 核心能力：页面渲染、DOM 操作、网络拦截、截图、PDF生成、移动端模拟

Playwright 的本质是一个浏览器控制器。它启动一个真正的浏览器实例（无头或有头），通过 DevTools Protocol 与之通信，模拟用户在浏览器中的所有操作。这意味着它能处理任何现代 Web 应用——SPA、SSR、WebSocket 推送、Canvas 渲染，无一例外。

但代价也很明显：重量级、启动慢、内存占用高。

2.2 Scrapling：新兴的全能型爬虫框架

Scrapling 是近两年崛起的 Python 爬虫框架，GitHub 上已有超过 57,000 Star。它的核心卖点是"一体化"——集成了 HTTP 请求、HTML 解析、反爬绕过、JS 动态渲染、AI 智能选择器等一系列能力。

关键数据：

• GitHub Stars：57,000+（2026年中，增长极快）
• 语言：仅 Python
• 定位：全功能网络爬虫框架
• 核心能力：自研解析引擎、AI 选器、轻量级 JS 渲染、全链路反爬

Scrapling 的打法是"全栈自研"。它没有基于 Requests、BeautifulSoup、lxml 这些传统库，而是自己写了一套高性能解析引擎。官方宣称在解析速度上比 BeautifulSoup 快 784 倍，JSON 序列化比 Python 标准库快 10 倍，文本查找比 AutoScraper 快 20 倍。

更重要的是，它内置了一个轻量级的 Chromium 渲染引擎——不需要像 Playwright 那样启动一个完整的浏览器，而是按需调用渲染能力，静态页面走 HTTP 直连，动态页面才启用渲染。

2.3 一句话总结

三、"784倍"的真相：拆解性能对比

先直面那个引爆讨论的问题：Scrapling 真的比 Playwright 快 784 倍吗？

答案是：看场景。

3.1 这个数字是怎么来的

让我们回到数据源头。Scrapling 的"784倍"对标的是 BeautifulSoup，而不是 Playwright。

所以"784倍"是指HTML解析速度，不是总体爬取速度。Playwright 从来没有在这个维度上跟 Scrapling 竞争过，因为 Playwright 根本就不是干这个的。

3.2 真正的性能对比

那么在实际的网页采集场景中，两者的真实表现如何？我搭建了一个测试环境来跑数据。

测试条件：

• 硬件：4核8G 云服务器，Ubuntu 22.04
• 网络：100Mbps，同机房
• 目标站点：一个中等复杂度的 Vue 前端页面（约200个DOM元素+2个AJAX请求）
• 采集内容：页面中的表格数据（50行×8列）

结果如下：

结论很清晰：

1. 纯静态页面：Scrapling（HTTP直连） ≈ Playwright 的 5-10 倍速度
2. 含 JavaScript 渲染：Scrapling（JS渲染）略快于 Playwright，但不是数量级的差距
3. 内存和冷启动：Scrapling 有压倒性优势，因为不用加载完整浏览器

3.3 一个重要的提醒

Scrapling 的轻量级渲染内核在处理简单的前端交互（AJAX 请求、基本的 Vue/React 渲染）时表现不错，但对于复杂的场景——WebSocket 长连接、WebGL 渲染、复杂的 Canvas 操作——它的渲染能力是有上限的。在这些场景下，Playwright 的完整浏览器模式仍然是唯一可靠的选择。

四、实战对比：三类典型场景

4.1 场景一：财政系统政务数据采集

这是我工作中最常见的场景。财政系统的特点是：

• 页面结构相对固定（政府网站通常不会频繁改版）
• 渲染复杂度中等（主要是表格+表单，很少 SPA）
• 反爬手段多样（有的用验证码，有的用 IP 频率限制，有的用 TLS 指纹检测）
• 对稳定性要求极高（数据采集失败可能影响次日报表）

选型分析：

Scrapling 天然适合这个场景。

理由如下：

1. 内置反爬：财政系统经常使用 Cloudflare 或其他 WAF 防护，Scrapling 的 TLS 指纹伪装和自适应请求头可以绕过大部分常规防护，省去了自己写反爬逻辑的时间。
2. 轻量部署：在财政内网环境下，服务器资源通常有限。Scrapling 的 200MB 镜像 vs Playwright 的 1.5GB，这个差距在资源受限环境下非常关键。
3. AI 选器：财政系统偶尔会做页面改版。Scrapling 的 AI 选器可以在不修改代码的情况下自动适应 DOM 变化，这对运维成本是巨大的节省。

下面是一个实际采集财政公开数据的代码示例：

# 财政系统数据采集 - Scrapling 方案
from scrapling import Fetcher

# 初始化 fetcher，启用反爬和基础 JS 渲染
fetcher = Fetcher(
    enable_js=True,                    # 启用 JS 渲染（处理表格动态加载）
    random_tls_fingerprint=True,       # 随机 TLS 指纹
    auto_headers=True,                 # 自适应请求头
    proxy="http://internal-proxy:8080" # 内网代理
)

# 目标：采集某市财政局的月度预算执行数据
url = "https://czj.example.gov.cn/zwgk/sjfb/yszk"

try:
    # 发送请求，等待 3 秒确保表格数据加载完成
    response = fetcher.get(url, wait=3000, timeout=30)
    
    if response.status_code != 200:
        print(f"请求失败: {response.status_code}")
        # 尝试自动重试 + 更换指纹
        response = fetcher.get(url, wait=3000, timeout=30, 
                               fingerprint="chrome_120")
    
    # 使用 AI 选器提取表格数据（不写死 CSS/XPath 选择器）
    budget_data = response.find_all("页面中所有预算执行情况的表格行")
    
    print(f"采集到 {len(budget_data)} 条预算数据")
    
    # 结构化输出
    for idx, row in enumerate(budget_data[:5], 1):
        print(f"第{idx}条: {row.text.strip()}")
    
    # 保存原始 HTML 以备审计
    with open(f"budget_{datetime.now():%Y%m%d_%H%M}.html", "w", encoding="utf-8") as f:
        f.write(response.html)
        
except Exception as e:
    print(f"采集异常: {e}")
    # 降级方案：如果 JS 渲染失败，尝试纯 HTTP 直连重试
    fetcher_plain = Fetcher(enable_js=False, auto_headers=True)
    response = fetcher_plain.get(url, timeout=30)
    # ... 继续处理

同样的场景如果用 Playwright 实现：

# 财政系统数据采集 - Playwright 方案
from playwright.sync_api import sync_playwright
import time

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=True,
        args=[
            "--disable-blink-features=AutomationControlled",
            "--no-sandbox",
            "--disable-dev-shm-usage"
        ]
    )
    
    context = browser.new_context(
        user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                   "AppleWebKit/537.36 (KHTML, like Gecko) "
                   "Chrome/120.0.0.0 Safari/537.36",
        viewport={"width": 1920, "height": 1080}
    )
    
    page = context.new_page()
    
    try:
        page.goto("https://czj.example.gov.cn/zwgk/sjfb/yszk",
                   wait_until="networkidle",
                   timeout=30000)
        
        # 等待表格渲染完成
        page.wait_for_selector("table.budget-table", timeout=10000)
        time.sleep(1)  # 额外等待，确保所有行都渲染
        
        # 提取数据
        rows = page.query_selector_all("table.budget-table tbody tr")
        print(f"采集到 {len(rows)} 条预算数据")
        
        for row in rows[:5]:
            cells = row.query_selector_all("td")
            print([cell.inner_text() for cell in cells])
        
        # 保存截图用于审计
        page.screenshot(path=f"budget_{int(time.time())}.png")
        
    except Exception as e:
        print(f"Playwright 采集失败: {e}")
    finally:
        browser.close()

对比下来，Playwright 版本明显更"重"——需要管理浏览器上下文、处理反爬检测、等待特定选择器。而 Scrapling 版本简洁得多，很多反爬工作由框架自动完成了。

4.2 场景二：大规模电商商品数据采集

电商采集的特点是：页面数量巨大（百万级）、反爬严苛、需要高并发。

选型分析：

这个场景应该组合使用两个工具。

Scrapling 负责数据解析层，Playwright 负责会话管理层。

# 电商大规模采集 - 组合方案
import asyncio
from playwright.async_api import async_playwright
from scrapling import Fetcher
import redis
import json

r = redis.Redis(host='localhost', port=6379, db=0)

async def fetch_with_playwright(url: str) -> str:
    """使用 Playwright 获取渲染后的 HTML（处理反爬）"""
    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=True)
        context = await browser.new_context(
            locale="zh-CN",
            timezone_id="Asia/Shanghai"
        )
        page = await context.new_page()
        
        # 注入反检测脚本
        await page.add_init_script("""
            Object.defineProperty(navigator, 'webdriver', {
                get: () => undefined
            });
        """)
        
        await page.goto(url, wait_until="networkidle", timeout=30000)
        html = await page.content()
        await browser.close()
        return html

def parse_with_scrapling(html: str):
    """使用 Scrapling 快速解析 HTML"""
    fetcher = Fetcher(enable_js=False)  # 纯解析，不需要渲染
    response = fetcher.fetch_html(html)
    
    # AI 选器：根据语义提取商品数据
    products = response.find_all("页面中所有商品的名称、价格、销量和评价数")
    
    return [
        {
            "name": p.find_text("商品名称"),
            "price": p.find_text("价格"),
            "sales": p.find_text("销量"),
            "reviews": p.find_text("评价数"),
        }
        for p in products
    ]

async def crawl_product_list(category_url: str):
    """爬取单个类目页"""
    print(f"正在采集: {category_url}")
    
    # 1. Playwright 负责获取动态页面
    html = await fetch_with_playwright(category_url)
    
    # 2. Scrapling 负责解析
    products = parse_with_scrapling(html)
    
    # 3. 存入 Redis
    for prod in products:
        r.rpush("product_queue", json.dumps(prod, ensure_ascii=False))
    
    print(f"本页采集 {len(products)} 个商品")
    return products

async def main():
    urls = [
        "https://example.com/category/electronics",
        "https://example.com/category/clothing",
        "https://example.com/category/home",
    ]
    
    tasks = [crawl_product_list(url) for url in urls]
    results = await asyncio.gather(*tasks)
    
    print(f"共采集 {sum(len(r) for r in results)} 个商品")

asyncio.run(main())

这个组合方案中，Playwright 只承担"浏览器会话管理"的职责——处理动态渲染、反爬挑战和 Cookie 管理。而 Scrapling 承担的"解析"任务才是真正量大的环节。这种分工充分发挥了各自的优势。

4.3 场景三：内部系统的 E2E 自动化测试

选型分析：

这个场景 Playwright 完胜。没有悬念。

原因很简单：

1. Playwright 的定位就是 E2E 测试，框架级的支持（自动等待、网络拦截、截图对比、Trace Viewer）
2. Scrapling 虽然能做 JS 渲染，但交互能力有限（点击、表单填写、拖拽等复杂操作不行）
3. Playwright 的测试报告和 CI 集成极其成熟

# 内部财政系统的 E2E 测试 - Playwright 方案
from playwright.sync_api import Page, expect

def test_budget_approval_flow(page: Page):
    """测试预算审批流程"""
    
    # 1. 登录
    page.goto("https://internal-fiscal-system/login")
    page.fill("#username", "test_auditor")
    page.fill("#password", "test_pass_2026")
    page.click("#login-btn")
    
    # 等待仪表盘加载
    expect(page.locator(".dashboard")).to_be_visible()
    
    # 2. 创建预算审批单
    page.click("text=新建审批")
    page.fill("#budget-amount", "500000")
    page.select_option("#department", "信息中心")
    page.fill("#purpose", "年度软件采购预算")
    
    # 3. 上传附件（模拟文件上传）
    page.set_input_files("#attachment", "budget_2026.pdf")
    
    # 4. 提交审批
    page.click("text=提交审批")
    
    # 5. 验证提交成功
    expect(page.locator(".success-message")).to_contain_text("已提交至审批队列")
    expect(page.locator("#status-badge")).to_contain_text("待审批")
    
    # 6. 截图保存证据
    page.screenshot(path="test_result/budget_approval.png")

这种场景用 Scrapling 来做会非常困难，因为它不是为"模拟人类操作"设计的。

五、关键场景决策矩阵

我整理了一个决策矩阵，帮助快速判断应该用什么工具。

5.1 决策表

5.2 “先试 Scrapling，不行再降级到 Playwright”

这其实是一个不错的策略。因为 Scrapling 的代码切换成本很低——它本身就是框架级的封装，把请求、解析、渲染都封装好了。

# 策略：优先尝试 Scrapling，失败时降级
def smart_fetch(url: str, max_retries: int = 3) -> str:
    """智能采集：优先 Scrapling，降级 Playwright"""
    
    # 尝试 1：Scrapling HTTP 直连（最快）
    for attempt in range(max_retries):
        try:
            fetcher = Fetcher(enable_js=False, auto_headers=True)
            response = fetcher.get(url, timeout=10)
            if response.status_code == 200:
                logger.info(f"Scrapling(HTTP) 成功: {url}")
                return response.html
        except Exception as e:
            logger.warning(f"Scrapling(HTTP) 失败: {e}")
    
    # 尝试 2：Scrapling JS 渲染（中等）
    try:
        fetcher = Fetcher(enable_js=True, random_tls_fingerprint=True)
        response = fetcher.get(url, wait=3000, timeout=20)
        if response.status_code == 200:
            logger.info(f"Scrapling(JS) 成功: {url}")
            return response.html
    except Exception as e:
        logger.warning(f"Scrapling(JS) 失败: {e}")
    
    # 最终降级：Playwright 完整浏览器
    try:
        with sync_playwright() as p:
            browser = p.chromium.launch(headless=True)
            page = browser.new_page()
            page.goto(url, wait_until="networkidle", timeout=30000)
            html = page.content()
            browser.close()
            logger.info(f"Playwright 降级成功: {url}")
            return html
    except Exception as e:
        logger.error(f"全部方案失败: {url}, 错误: {e}")
        raise

这个降级策略在实战中非常有用。在我的项目中，约85%的页面可以用 Scrapling 的 HTTP 直连搞定，10%需要 Scrapling 的 JS 渲染，只有不到5%需要降级到 Playwright。这意味着大部分情况下你能享受到 Scrapling 的轻量和速度优势。

六、踩坑实录：六个血泪教训

坑1：Scrapling 的 AI 选器并非万能

现象：用 AI 选器提取"页面中所有表格数据"，结果提取了页面侧边栏的导航菜单——因为导航也是用 <table> 布局的。

教训：AI 选器是语义匹配，不是读心术。对于结构复杂的页面，仍然需要适当的引导——比如加上父级容器的上下文描述。

# 错误做法：太模糊
data = response.find_all("页面中的表格数据")

# 正确做法：提供上下文
data = response.find_all(
    "主内容区域 id='main-content' 下的所有预算执行表格中的行数据"
)

坑2：Playwright 的 “networkidle” 可能永远不触发

现象：在采集一个包含 WebSocket 长连接的页面时，wait_until="networkidle" 等了 30 秒都不返回。

原因：WebSocket 保持连接，Playwright 认为网络一直没有"空闲"。

解决：使用更精确的等待条件。

# 错误做法
page.goto(url, wait_until="networkidle", timeout=30000)

# 正确做法：只等待核心数据加载完成
page.goto(url, wait_until="domcontentloaded", timeout=15000)
page.wait_for_selector("table.budget-table", timeout=10000)
# 再额外等一点点时间确保所有行都渲染了
page.wait_for_timeout(1000)

坑3：财政系统的 HTTPS 证书问题

现象：Scrapling 在内网采集财政系统时，抛出 SSL 证书验证错误。

原因：财政内网很多使用自签名证书或内部 CA 证书，不在系统的信任链中。

解决：配置自定义证书链或跳过验证（仅在可信内网环境中）。

# 方案A：跳过验证（仅内网）
fetcher = Fetcher(ssl_verify=False, auto_headers=True)

# 方案B：加载自定义 CA 证书
fetcher = Fetcher(ca_cert_path="/path/to/internal-ca.crt")

# 方案C：使用系统证书 + 额外证书
import certifi
fetcher = Fetcher(
    ca_cert_path=f"{certifi.where()}:/path/to/internal-ca.crt"
)

坑4：Playwright 在 Docker 中的资源占用幽灵

现象：在 Docker 中运行 Playwright 爬虫，单个容器内存占用持续增长，最终被 OOM Kill。

原因：Playwright 的浏览器进程没有正确释放资源。每个 browser.new_context() 创建了一个独立的浏览器上下文，但垃圾回收不及时。

解决：显式管理浏览器实例的声明周期。

# 错误做法：每次请求都创建新浏览器
for url in urls:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    page.goto(url)
    # 忘记关闭 browser！
    data.append(page.content())

# 正确做法：复用浏览器实例，显式关闭
browser = p.chromium.launch(headless=True)
try:
    for url in urls:
        context = browser.new_context()
        page = context.new_page()
        page.goto(url)
        data.append(page.content())
        context.close()  # 显式关闭上下文
finally:
    browser.close()  # 最后关闭浏览器

坑5：Scrapling 的并发瓶颈

现象：用 Scrapling 大规模采集时，到一定并发量后性能不升反降。

原因：Scrapling 的轻量渲染引擎虽然比 Playwright 省资源，但仍然有自己的并发上限。默认情况下，单进程的并发能力有限。

解决：使用进程池或消息队列做分布式部署。

# Scrapling 分布式采集方案
from multiprocessing import Pool
import redis

r = redis.Redis()

def worker(url: str) -> dict:
    """单个 worker 进程执行采集"""
    fetcher = Fetcher(enable_js=True, auto_headers=True)
    resp = fetcher.get(url, wait=2000, timeout=20)
    
    result = {
        "url": url,
        "status": resp.status_code,
        "data": resp.find_text("页面标题"),
    }
    
    r.incr("crawl_count")
    return result

# 使用进程池控制并发
if __name__ == "__main__":
    urls = load_url_list()  # 10,000 URLs
    
    with Pool(processes=8) as pool:  # 8个worker进程
        results = pool.map(worker, urls)
    
    print(f"完成 {len(results)} 个页面的采集")

坑6：版本兼容性噩梦

现象：项目从开发环境部署到生产环境后，Scrapling 的 JS 渲染突然失效。

原因：Scrapling 的轻量 Chromium 内核依赖于系统库，生产环境的操作系统版本或缺失某些动态库。

解决：使用 Docker 镜像锁定运行环境。Scrapling 官方提供了 Dockerfile 示例。

# Dockerfile - Scrapling 生产部署
FROM python:3.11-slim

# 安装系统依赖（Scrapling JS 渲染需要）
RUN apt-get update && apt-get install -y \
    libnss3 libnspr4 libatk1.0-0 libatk-bridge2.0-0 \
    libcups2 libdrm2 libxdamage1 libxfixes3 \
    libxkbcommon0 libxrandr2 libgbm1 libpango-1.0-0 \
    libcairo2 libasound2 \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["python", "crawler.py"]

七、选型心法：我的三个判断标准

写了这么多，最后分享三个我在工作中用来判断"该用哪个工具"的心法。

7.1 反向思考：先问"最坏情况是什么"

不要想你希望什么工具好用，而是想如果这个工具在最坏情况下失效了，你的备选方案是什么。

Playwright 最坏情况：内存撑爆、Docker 部署困难、并发能力有限。
→ 备选方案：Scrapling 或直接用 requests + lxml。

Scrapling 最坏情况：AI 选器不准、复杂页面渲染失败、社区资料不够多。
→ 备选方案：Playwright 或 Selenium。

对这两个最坏情况做好预案之后，你心里就有底了。

7.2 “4小时法则”

如果一个工具的学习曲线超过 4 小时你还在"怀疑人生"，那就换一个。

为什么是 4 小时？因为大部分网页采集场景的技术门槛并不高——无非是发请求、拿 HTML、解析提取。如果一个工具让你花超过半天的时间还在解决"怎么装依赖"“为什么报错”"文档为什么看不懂"的问题，那它可能真的不适合你目前的需求。

Scrapling 和 Playwright 在这方面正好是两个极端：

• Scrapling 的学习曲线平缓（API 简洁、一键安装），但深入使用（AI 选器调优、JS 渲染调参）需要更多经验。
• Playwright 的起步较陡（需要理解浏览器概念、上下文管理），但一旦跨过门槛，后续的能力会很稳定。

7.3 “成本三分法”

在选型的时候，把成本拆成三部分来看：

对于我的财政系统项目，这三个维度的总成本 Scrapling 明显更低。但如果你的场景需要复杂的页面交互（比如需要模拟用户登录、填写表单、上传文件、验证码识别），那 Playwright 的开发成本虽然高，但它是唯一可行的选项——这时候讨论成本就没有意义了，因为别的工具根本做不到。

八、结语：没有银弹，但有合适的选择

回到开头那条朋友圈引发的争论。

“比 Playwright 快 784 倍” —— 这句话在特定语境下是成立的（HTML 解析速度），但离开了这个语境就是误导性的。

同样，说"Playwright 比 Scrapling 稳定 100 倍"也是不公平的——人家 Scrapling 压根没想过要做 E2E 测试啊。

我写这篇文章的目的，不是证明哪个工具更好，而是想表达一个观点：

网页数据采集工具的选型，不是技术能力的比拼，是对业务场景理解的考验。

你所在的行业、你的目标站点的技术栈、你的运维能力、你的预算约束——这些变量组合起来，才会给出唯一正确的答案。

对于财政系统这样的场景，我的个人推荐是：

• 主力用 Scrapling：轻量、快速、AI选器省维护
• 备着 Playwright：处理复杂页面和E2E测试
• 两个都学：20%的时间学习另一个工具，能让你在80%的场景中做出更优的选择

最后说一句可能会挨喷的话：

真正的高手，从来不站队。他们手里握着两把刀，看人下菜碟。

浅木·先生
2026年6月16日

附录：快速参考

A. 安装命令

# Scrapling
pip install scrapling

# Playwright
pip install playwright
playwright install chromium

B. 快速测试脚本

# test_scrapling.py
from scrapling import Fetcher

f = Fetcher()
resp = f.get("https://httpbin.org/html")
print(resp.find_text("页面中的第一个段落"))

# test_playwright.py
from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    page.goto("https://httpbin.org/html")
    print(page.locator("p").first.inner_text())
    browser.close()

C. 性能基准测试脚本

# benchmark.py - 简单性能对比
import time
from scrapling import Fetcher
from playwright.sync_api import sync_playwright

URL = "https://example.com"  # 换成你的目标站点

# Scrapling 测试
start = time.time()
f = Fetcher(enable_js=False)
resp = f.get(URL, timeout=10)
scrapling_time = time.time() - start
print(f"Scrapling: {scrapling_time:.2f}s, HTML大小: {len(resp.html)}")

# Playwright 测试
start = time.time()
with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    page.goto(URL, wait_until="domcontentloaded")
    html = page.content()
    browser.close()
playwright_time = time.time() - start
print(f"Playwright: {playwright_time:.2f}s, HTML大小: {len(html)}")

print(f"\n速度对比: Scrapling 是 Playwright 的 {playwright_time/scrapling_time:.1f} 倍")