随着互联网应用竞争日益激烈，网站性能已成为影响用户体验、搜索引擎排名和广告投放效果的重要因素。Preply 是一家专注于在线辅导的 B2C 和 B2B 平台，面对激烈的市场与用户需求，其前端团队针对性能指标中的核心项目之一——交互到下一画面（INP），开展了深入的研发和优化。借助 Next.js 框架，该团队成功将两个最重要页面的 INP 值从“黄色区间”优化至“绿色区间”，并显著降低了整体成本，预计每年节省约20万美元。本文将分享 Preply 如何在未采用 React Server Components（RSC）和 Next.js 最新 App Router 的情况下，通过数据驱动的多重策略，实现这一性能突破，并探索未来持续优化的可能路径。 首先，要理解为什么 INP 作为页面性能的重要指标备受关注。作为谷歌核心 Web Vitals 的组成部分，INP 衡量用户在页面上的所有交互（点击、键盘事件、触摸等）的响应时长，代表了较长交互所经历的延迟，因此对用户实际体验影响巨大。
对于 Preply 这样以 SEO 和 SEM 为驱动的产品，页面速度不仅影响搜索引擎排名，从而决定自然流量，也直接关系到广告质量得分，进而影响每次点击费用和广告展示排名。更快的交互速度意味着更高的用户留存率和转化率，直接带来业务增长。 Preply 现有的技术架构基于 Next.js 13，使用 React 18，采用多页面应用（MPA）模式且通过 Pages Router 进行服务端渲染。尽管拥有丰富功能，应用程序的技术负债较重，且索引页面众多，但从 SEO 和 SEM 角度看，主页和搜索页尤为关键，二者特点迥异：主页代码量简洁，交互点有限，主要是滑块和隐私条；搜索页则庞大复杂，近90%为交互式元素，包括过滤器、预约模态框等。项目的核心目标是将两者在移动端的 INP 从大约250毫秒降低至绿色标准（主页降低至185毫秒，搜索页减少至175毫秒）。团队通过深入数据分析，验证并调整优化策略，发现性能提升潜力巨大，且能带来显著经济效益。
团队围绕两个核心假设展开工作：一是减少 React 水合（hydration）过程，缩短页面准备和响应时间，二是提升自有 JavaScript 和 React 代码的执行效率。React 水合是将服务器返回的静态 HTML 转换为完全可交互的客户端应用的过程，尽管 React 18 已对这一阶段进行优化，水合仍可能引入延迟，影响首批交互响应，尤其在低端设备上表现明显。通过性能分析和本地调试，Preply 发现水合平均耗时约120毫秒，虽非最大瓶颈，但会加重首轮交互的 INP 值。故部分尝试包括主页迁移至 Next.js App Router，尽管整体提升有限，但积累了开发经验，为未来计划打下基础。 在数据采集层面，Preply 倚重多个工具和平台，包括谷歌 Chrome 团队提供的 web-vitals 库、Next.js 自定义指标（尤其是水合和渲染时长）、Snowflake 数据仓库供全员查询，以及流行的用户行为分析工具 Hotjar。通过交叉分析，被标示为高 INP 罪魁祸首的 DOM 元素和具体交互得到了确认。
此外，借助 Chrome 开发者工具的性能记录功能，团队能够精准定位造成性能瓶颈的事件监听器或组件渲染。大量实时数据揭秘了用户设备普遍低性能的现状，尤其是移动端使用的老旧安卓手机，这对 INP 优化提出了更高要求。 具体的技术优化措施涵盖面广泛且精细。首先，React 18 升级带来的水合架构改进即为明显推动力，升级后搜索页面 INP 从约460毫秒骤降到330毫秒左右，说明底层框架优化助力巨大。但独立于框架升级，Preply 团队针对应用结构和代码细节展开多角度改良。长度达 300 个条目的“辅导员出生国家”列表通过引入 React Virtuoso 实现虚拟化，减少 DOM 承载压力和渲染负荷，降低了约40毫秒的 INP。
多输入框中引入防抖处理，尤其是主学习科目字段，极大缩短了用户输入时的响应迟滞，最高改善达600多毫秒。 针对页面上非静态组件过度重新渲染问题，团队对“两大重量级静态组件”应用了 memoization，有效避免无谓重绘，整体 INP 降低约30毫秒。而隐私条则通过调整状态管理，让复杂逻辑局部化，阻止页面层级不必要的重新渲染，带来约15毫秒优化。不仅如此，团队排查到首次互动性能异常的根因是非交互元素绑定了大量 touchstart 事件，进而触发额外渲染影响交互响应。对 Radix UI Tooltip 组件的状态逻辑进行了 TypeScript 类型优化，消除了布尔值可能为 undefined 导致的无效渲染，整体 INP 改善约10毫秒。 对于欧盟用户使用的 Usercentrics 隐私条，升级到第三版减少了额外运行的繁重 JavaScript，显著改善了主页（约40毫秒）、搜索页（约5毫秒）的交互响应速度。
项目后期甚至再次回访已经优化的环节，采取更仿真低端设备的 20 倍 CPU 降速环境进行测试，找出能进一步压榨性能瓶颈的细节，体现了团队对优化“极致”追求的专业态度。 另一值得关注的是，团队在多次尝试中发现某些流行技术并未带来预期收益，例如 React 的 useDeferredValue 在当前应用场景未能提升 INP，部分因其优化对象偏重 React 渲染阶段而非 DOM 更新阶段。设计系统组件的重构优化虽为工程质量兜底，但针对 INP 并未带来立竿见影效果。清理大规模遗留代码的行为同样未直接改善响应时间，但从长远和维护成本角度看仍十分必要。针对聊天模块的临时延迟执行尝试也未达到预期，印证了所有优化均需建立在充分数据分析和场景理解之上。 部分方案如使用 Partytown 将第三方脚本转移至 Web Worker，因现有大量通过 Google Tag Manager 加载的脚本相互依赖和添加动态执行代码，存在极高风险及复杂性，最终团队选择放弃该方向。
React 新编译器的使用虽然备受关注，但因项目周期限制未能纳入本次优化范围。项目组对于用 await-interaction-response 等“巧妙”手段延迟执行重业务代码持谨慎态度，强调不应取巧掩盖底层设计问题。 从用户体验角度来看，经过多次模拟低配设备环境的测试，优化后的交互明显流畅。INP 统计不仅验证了技术层面的改进，同时映射了真实用户感受，尤其中低端移动设备上的表现提升尤为重要。Preply 以数据驱动促成决策，建立了覆盖各产品线的 Web Vitals 监控体系，并将性能指标纳入实验和发布流程，逐步形成性能为先的开发文化。团队还计划持续开展技术分享和工作坊，普及 React 性能优化最佳实践，助力未来项目稳步推进。
该项目展示了大规模产品性能提升的挑战与对策。降低 React 水合开销、避免无效重渲染、合理虚拟化长列表、优化状态管理以及升级关键第三方组件都是关键手段。但最核心的成功要素是基于海量真实用户数据的深度分析和持续验证，避免盲目追随潮流框架与技术，精准锁定性能瓶颈。Preply 团队在此基础上进行反复实验、调整，在不到一个季度时间内达成了令人满意的成果。 展望未来，Preply 计划继续深化性能监控，将 Web Vitals 纳入更多产品指标体系，推动性能意识深入团队。同时探索 App Router 与 React Server Components 结合的新开发模式，虽然短期内迁移难度和资源投入较高，但潜力不容忽视。
整体上，持续的技术升级、代码精简和用户体验关怀将共同驱动平台性能不断提升，助力 Preply 保持行业竞争优势。 综上所述，Preply 在 Next.js 应用上的 INP 优化经验具有较高借鉴价值，尤其适用于拥有庞大代码基、复杂交互且尚未全面采用最新 React 特性的项目。通过科学的数据驱动方法，精准识别性能瓶颈，结合应用架构和代码层面的针对性优化，企业不仅能显著提升用户体验，还能带来切实的商业价值。随着 Web Vitals 指标体系的推广和移动设备性能的差异化，未来性能优化的任务与挑战将持续存在，唯有依赖切实有效的工程实践，方能实现用户、技术与业务的三赢。
