网络请求链路：从DNS解析到HTTP/2多路复用的延迟削减
前端延迟首先体现在网络链路中。一次页面请求要经历DNS解析、TCP握手、TLS协商、HTTP请求响应等多个阶段。针对DNS解析，可以采用preconnect预连接技术，在浏览器尚未发起正式请求时提前完成域名解析与连接建立，例如``，这能将后续请求的握手时间缩短数百毫秒。其次，将静态资源升级至HTTP/2甚至HTTP/3，利用多路复用解决队头阻塞问题，在同一连接上并行传输多个资源。同时，开启TLS 1.3可以减少一次往返时间。对于高频小体积请求，可考虑使用CDN边缘节点缓存或服务端推送关键资源。此外，合并域名、减少重定向次数、启用Brotli压缩也能大幅削减传输体积。真正需要关注的是，将所有静态资源部署至靠近用户的边缘节点，通过Anycast技术降低物理距离带来的RTT延迟。在实战中，我们会先使用Performance API分析`redirectStart`到`responseEnd`各阶段耗时，确定瓶颈在DNS、TLS还是传输，再针对性优化。同时，合理设置`Cache-Control`与`ETag`，避免协商缓存带来的额外请求延迟，甚至可以使用Service Worker实现离线缓存，使重复访问时资源几乎零延迟。通过上述手段，网络链路延迟通常能降低40%以上。
资源加载策略：代码分割、预加载与关键路径渲染优化
页面延迟的另一大来源是资源加载顺序与体积。现代前端框架打包后往往形成数百KB甚至数MB的JavaScript包，若全部阻塞渲染，首屏自然变慢。首要策略是代码分割，按路由按需加载组件，将首屏不需要的逻辑拆分为异步chunk。其次，利用``提前加载首屏字体或关键图片，使用``预取用户即将点击的页面。对于CSS，需要将关键CSS内联到HTML中，非关键CSS延迟加载。图片方面采用懒加载与`srcset`响应式尺寸，并使用WebP格式减小体积。更核心的是优化关键渲染路径：压缩HTML并内联首屏所需的CSS；JavaScript使用`defer`或`async`避免阻塞解析；此外，可以通过`import()`动态导入不是首屏必需的库。对于首屏最大元素，可提前在HTML中输出其内容，减少客户端渲染等待。还需注意字体加载的FOIT现象，使用`font-display: swap`避免文字不可见。在真实项目中，我们常借助Lighthouse的“Eliminate render-blocking resources”建议，将各外部脚本与样式表改造为可并行下载且非阻塞的形式。一个有效实践是：将首屏可见区域拆分成独立组件，配合服务端渲染或静态生成，提前输出HTML骨架，再在hydration时同步事件与状态，从而将LCP时间从4.5秒压缩至2秒以内。资源的加载顺序也需根据优先级动态调整，确保用户眼前的内容最先到达。
运行时卡顿治理：长任务拆分、渲染帧预算与事件节流
即使网络和加载优化到位，复杂页面在交互时仍可能出现延迟，表现为点击无响应、滚动掉帧或输入卡顿。其根本原因是主线程被长任务占据，无法及时处理用户事件。为解决这个问题，我们需要将大于50ms的长任务拆分为多个小于50ms的微任务，使用`requestIdleCallback`或`setTimeout`分片执行。例如，大型列表渲染可采用`requestAnimationFrame`分批插入DOM节点，或借助虚拟滚动只渲染可视区域。同时，要想保证60fps的流畅体验，每帧的任务预算只有约16.7ms，因此需要在动画、布局、绘制之间精准分配。避免强制同步布局：随意读取`offsetHeight`再修改样式会导致浏览器反复计算布局，正确做法是使用`CSS.contain`隔离布局影响，或批量读写DOM。事件节流方面，对scroll、resize等高频事件使用`requestAnimationFrame`合并触发，对搜索输入使用防抖函数，避免无效计算。此外，复杂的计算逻辑应放到Web Worker中执行，比如图像处理、数据统计等，不占用主线程。我们还可以利用`PerformanceObserver`监听长任务，动态找出阻塞源。若使用React，可考虑`useTransition`与`useDeferredValue`将非紧急更新标记为可中断，确保输入框等高优先级交互即时响应。在构建层面，避免使用体积庞大的日期库或图表库，改用原生API或按需加载子模块。运行时卡顿的优化往往需要一个持续迭代的过程：先录制Performance面板，识别脚本执行、样式计算与绘制耗时的峰值，再针对性地分解任务、减少重排重绘。最终目标是让主线程始终留出空余时间，保证用户每个操作都在100ms内获得反馈。
性能监控闭环：用真实用户数据驱动持续延迟优化
前端延迟优化不是一次性的重构，而是一个需要数据支撑的持续闭环。首先要建立真实用户监控体系，通过Performance API收集`FP`、`FCP`、`LCP`、`TTI`、`TBT`、`CLS`等核心指标，并上传至分析平台。注意采样要保持轻量，避免监控代码自身影响性能。其次，要定义基准线与告警阈值，比如LCP大于2.5秒或FID大于100ms时触发告警，自动记录上传用户的浏览器、网络类型、地区等维度，帮助定位是某类问题还是全局问题。在分析阶段，将指标与代码版本关联，当发布新功能后指标回退，即可迅速锁定回归原因。更先进的做法是使用性能预算：为JS包体积、最大资源大小、请求个数设定上限，在CI阶段当超出预算时阻止合并，从源头防止性能劣化。同时结合Synthetic监控，在低端设备、慢速网络环境下定期跑Lighthouse或WebPageTest，模拟最恶劣的用户场景。反馈环节需要将监控数据转化为优化任务：例如当某个路由的JS chunk加载时间过长，就进一步拆分该chunk；当某个地区用户的DNS耗时偏高，就增加该地区的CDN节点。最终，将这些优化效果通过A/B测试验证，确保不牺牲功能与体验。整个闭环强化了团队的性能文化：性能不再是“事后补救”，而是与功能开发同步进行。定期复盘性能数据，建立性能属主机制，将延迟优化变成每日工作流的一部分。只有通过持续监控与反馈，才能保证在前端功能不断迭代的背景下，延迟始终保持在一个可接受的区间内，从而真正实现用户感知的稳定与快速。
