客户端渲染 vs 服务端渲染

Scrapeless Agent Browser 运行可执行 JavaScript 的浏览器会话，并暴露生成的页面内容以供抽取。

页面内容在何处变成 HTML？

客户端渲染 vs 服务端渲染描述的是应用内容在何处被转换为用户看到的 HTML 或 DOM 结构。服务端渲染会在收到请求后在服务器端生成页面的 HTML。客户端渲染则在浏览器中使用 JavaScript 在资源到达后构建或更新页面。

在两种情况下，浏览器仍然要执行解析、布局和绘制。 HTML 解析模型 解释了一个响应如何变成文档树。说服务器渲染 HTML 并不意味着服务器直接在用户屏幕上绘制像素。

真实应用通常会组合多种方式。例如，商品标题可能在服务器生成的 HTML 中返回，而库存情况在客户端请求之后更新，评论面板只在被打开时才加载。将整个域名简单归类为 SSR 或 CSR，可能会掩盖你真正关心的那个具体字段的行为。

HTML 可用性与交互就绪

内容可用性与交互就绪是两个独立的里程碑。服务器返回的 HTML 可以在关联的应用代码加载完成之前就让文章可读。HTML 中可见的按钮在具备其预期功能之前，仍然可能需要 JavaScript 事件处理程序。

水合是客户端应用将其行为附着到服务器生成标记的过程。根据应用不同，这可能涉及大量执行，或对组件的选择性激活。不要因为看到文本就假定某个表单或导航控件已经就绪。

在客户端渲染中，所需内容可能依赖额外的数据请求和状态更新。文档加载事件可能早于某个列表被填充，而后台分析在列表可用后仍可长时间继续。就绪判断应当跟随你所需的具体内容或交互，而不是从不相关页面上照搬一个通用延迟。

Navigation Timing 模型 区分了导航过程中的各个里程碑。这些计时有助于诊断传输和文档生命周期，但仍然需要任务特定的条件来确认相关字段或控件已经出现。

性能不只取决于渲染标签

渲染架构只是分配服务器与浏览器之间的工作；它并不能决定绝对的性能赢家。服务端渲染可以在初始响应中提供内容，但后端计算和数据访问可能推迟该响应。客户端渲染可以支持丰富交互，却会增加脚本和执行工作量，使得有用内容出现之前的开销变大。

衡量对用户或消费者真正重要的内容。对于读者而言，有意义的内容展示可能比每个可选小部件是否启用更为重要。对于自动化任务而言，能够准备好执行某个被允许的交互可能才是所需的里程碑。单一的页面加载数值无法同时代表这两种结果。

缓存会改变比较结果。 HTTP 缓存规则 根据其语义和标题应用到响应上。动态生成的页面可以是可缓存的，而服务器渲染的个性化响应则可能需要限制。客户端渲染应用使用的静态资源同样可以被缓存，而不必将其实时数据变为静态。

在具有代表性的条件下比较完整的工作负载。包括服务器响应时间、传输的资源、浏览器执行、所需数据补全，以及在适用情况下的成功交互。避免在未对必须运行的应用进行测量的情况下断言 CSR 总是更慢或 SSR 总是更便宜。

爬虫和提取器接收的内容

普通的 HTTP 抽取器接收的是响应字节，而不是最终的浏览器 DOM。如果某个目标字段只在 JavaScript 修改文档之后才存在，那么仅解析原始响应无法获取之后的状态。仅仅更改选择器并不能解决源内容缺失的问题。

从最窄的问题开始：该字段是否在响应中？将收到的文档与浏览器检查器中相同 URL 和上下文下的内容进行比较。在将差异归因于 JavaScript 渲染之前，检查重定向、语言、同意状态以及权限要求。

当响应中存在内容时，解析可以避免浏览器会话的开销。 当内容依赖执行或交互时，浏览器可以提供所需的状态。 解析器与浏览器提取对比 解释了在 JavaScript 工作流中所做的这一选择。

Scrapeless 代理浏览器 提供了一个托管的浏览器执行层。你的工作流仍然必须决定何时检查页面、定义它所接受的字段，并区分缺失的内容和尚未达到所需状态的渲染结果。

SEO 和可发现性需要各自独立的检查

呈现策略会影响爬虫获取内容的难易程度，但索引还取决于可发现的 URL、访问规则、规范信号以及搜索引擎的处理方式。服务器端 HTML 并不能保证一定被索引，而使用 JavaScript 也并不会自动让页面对搜索引擎“隐形”。

保持主要内容和链接可检查。一个应用可以提供可阅读的 HTML，同时仅通过交互使重要的目标可访问。相反，一个最初内容稀少的页面可以包含可被发现的链接和数据，而功能强大的渲染爬虫可以在后续处理中处理这些内容。

使用平台提供的检查工具（如有）来查看目标抓取工具实际观察到的内容。确保状态代码和规范信息与页面状态保持一致。在 HTTP 成功响应中渲染的错误界面可能会干扰搜索诊断和内容提取流程。

为每个任务选择架构或抽取路径

当有意义的初始 HTML 能很好地支持产品的内容和交互需求时，选择服务端渲染的交付方式。当浏览器端的状态和交互能够证明所需执行是合理的时，选择客户端渲染。混合设计可以为核心页面使用服务端 HTML，并为需要的功能提供客户端行为。

对于抽取来说，与其编写整个域的通用规则，不如编写字段清单。记录每个字段在何处可用、观察它所需的状态，以及是否需要交互。一个页面大部分可以是服务器渲染的，但其最有价值的字段可能是客户端加载的。

1. 检查初始响应中的必需字段。
2. 在目标语言和地区中比较浏览器 DOM。
3. 识别会导致缺失内容出现的事件或状态。
4. 为该字段集选择解析或浏览器执行。
5. 验证最终记录并保留观察上下文。

根据需要浏览器的任务所占比例来分配浏览器使用预算，并进行比较。 无抓取定价 使用观察到的会话行为来工作，而不是假设每个页面都需要相同的路由。当内容无法访问时保留失败记录，而不是悄悄替换为其他页面。

一个实用的交接还应描述使用方可以接受的回退状态。如果文章正文可用但实时小组件不可用，文本归档可能仍然是完整的，而产品监控记录则是不完整的。在实施之前就定义这些结果，这样部分渲染的页面就不会变成一个看似成功却具有误导性的数据记录。

清单字段可以跨越渲染边界

产品页面可以在服务器生成的 HTML 中提供其标题和描述，同时在访客选择商店后再加载库存情况。文本归档可以在无需交互的情况下接收前两个字段，但门店库存报告则需要后续状态。将整个页面标记为 SSR 并不能回答库存字段是否是可观测的。

将门店选择和可用性条件写入集合需求中。保留带有数值的已选门店，这样使用方就不会将本地结果解释为全国库存。由于该字段具有状态依赖性，因此浏览器会话是合理的，而其他页面类型则可以保留更简单的响应解析路径。

结论

客户端渲染与服务端渲染决定了内容在何处被组装，以及哪些执行步骤会暴露这些内容。分别检查初始 HTML、hydration 过程以及之后的 DOM 状态。选择一条能够观察到所需字段的抽取路径，然后在任务的实际运行条件下验证其完整性。