为了让Gemini、GPT、Claude、Perplexity等AI爬虫更高效地解析网站内容，Markdown格式比HTML更受欢迎。Markdown能提供更清晰的上下文，减少不必要的token，从而降低推理成本。如果内容本身就是Markdown格式（来自CMS、Git或数据库），可以直接通过Accept: text/markdown进行协商。但如果内容是HTML——例如代理第三方页面、镜像文档、构建阅读模式端点，或为LLM摘要器提供数据——就需要在Cloudflare Worker中进行HTML到Markdown的转换。对于免费计划，这意味着严格的10毫秒CPU时间和1MB压缩包大小限制。那么，哪种策略能够在这种约束下生存下来呢？
首先需要澄清的是，Cloudflare的“付费”方案可能指两种不同的产品：
- Workers付费计划（每月5美元+使用费）：这是Worker运行时的升级，CPU时间从10毫秒跃升至30秒，包大小从1MB增至10MB。这个计划彻底改变了HTML到Markdown的转换计算方式。
- Cloudflare Pro（每域名每月20美元）：这是一个域名服务计划，增加了WAF、图像优化、页面规则等功能，但不改变任何Worker限制。
本文中，“付费”特指Workers付费计划。
免费计划的资源预算非常紧张：每请求CPU时间为10毫秒，压缩Worker包为1MB。对于路由或JSON处理任务，10毫秒通常足够。但HTML到Markdown的转换不同——它涉及到解析DOM，遍历每个节点，然后输出转换后的字符串。这是一个CPU密集型任务，并且任何引入自身DOM实现的策略都可能轻易超出包大小预算。
核心解决方案是：HTMLRewriter。
HTMLRewriter内置于workerd中，这是Cloudflare在边缘执行Worker的开源JavaScript/Wasm运行时（也是wrangler dev在本地运行的基础）。它无需任何npm依赖，Cloudflare自身也用它进行响应转换。
HTMLRewriter在架构上是流式且SAX风格的：它在字节到达时触发<h1>/文本/</h1>等事件，从不在内存中构建完整的DOM树。而turndown、Readability、cheerio等库则采取相反做法——它们会缓冲整个文档，构建一个包含所有节点和父指针的DOM，然后遍历它。这个构建过程不仅消耗CPU（在输出任何Markdown字符之前），也是这些库需要引入自身DOM实现（导致数百KB的包大小）的原因。
以一个34KB的HTML文章为例，使用HTMLRewriter的数据表现如下：
- 包大小：未压缩10.52 KiB / gzip压缩后3.74 KiB（仅占1MB预算的0.4%）
- CPU：50次运行中位数为2毫秒（最小2，最大8），仅占10毫秒预算的20%
- 输出：24.9 KB Markdown
这意味着在免费计划下，HTMLRewriter提供了5倍的CPU余量和250倍的包大小余量。所有其他测量过的方案都无法与之匹敌。