npx skills add https://github.com/wondelai/skills --skill high-perf-browser一种基于浏览器、协议和网络实际工作原理的系统化 Web 性能优化方法。在构建前端应用、审查性能预算、配置服务器或诊断页面加载缓慢时,应用这些原则。
延迟,而非带宽,是瓶颈。 大多数 Web 性能问题源于过多的往返次数,而非吞吐量不足。带宽增加 5 倍带来的收益递减;而延迟减少 5 倍则能彻底改变用户体验。
基础: 每个网络请求在第一个字节内容到达之前,都要经过 DNS 解析、TCP 握手、TLS 协商和 HTTP 交换。每一步都增加了往返延迟。高性能应用会最小化往返次数、并行化请求并消除不必要的网络跳转。理解协议栈不是可选的——它是进行有意义优化的先决条件。
目标:10/10。 在审查或构建 Web 应用时,根据对以下原则的遵循程度,将性能评为 0-10 分。10/10 表示完全符合所有指导原则;较低的分数表示有待解决的差距。始终提供当前分数以及达到 10/10 所需的具体改进措施。
构建快速、弹性的 Web 应用的六个领域:
核心理念: 每个 HTTP 请求都要支付延迟代价:DNS 查找、TCP 三次握手和 TLS 协商——所有这些都在任何应用数据流动之前发生。减少或消除这些往返是最高杠杆的优化。
其原理: 光以有限的速度传播。从纽约到伦敦的数据包单程大约需要 28 毫秒,无论带宽如何。TCP 慢启动意味着新连接开始传输时速度很慢。TLS 增加了 1-2 次往返。这些物理层面的限制无法通过更大的管道来解决——只能通过减少往返次数来解决。
关键见解:
dns-prefetch 进行预解析代码应用:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 上下文 | 模式 | 示例 |
|---|
| 连接预热 | 预建立到关键源的连接 | <link rel="preconnect" href="https://cdn.example.com"> |
| DNS 预取 | 提前解析第三方域名 | <link rel="dns-prefetch" href="https://analytics.example.com"> |
| TLS 优化 | 启用 TLS 1.3 和会话恢复 | 服务器配置:ssl_protocols TLSv1.3; 并启用会话票据 |
| 初始负载 | 将关键 HTML 保持在压缩后 14KB 以下 | 内联关键 CSS,延迟非必要脚本 |
| 连接复用 | 保持连接活跃以避免重复握手 | Connection: keep-alive(HTTP/1.1+ 默认启用) |
参见:references/network-fundamentals.md 了解 TCP 拥塞控制、带宽延迟积和 TLS 握手细节。
核心理念: HTTP 已从一个简单的请求-响应协议演变为一个支持多路复用、二进制、服务器推送的系统。选择正确的协议版本并正确配置可以消除整类性能问题。
其原理: HTTP/1.1 迫使浏览器采用诸如域名分片和精灵图之类的变通方法,因为它无法多路复用请求。HTTP/2 解决了多路复用问题,但继承了 TCP 队头阻塞。HTTP/3(QUIC)转向 UDP,消除了队头阻塞并支持连接迁移。每一代都消除一个瓶颈。
关键见解:
103 Early Hints代码应用:
| 上下文 | 模式 | 示例 |
|---|---|---|
| HTTP/2 迁移 | 移除 HTTP/1.1 的变通方法 | 撤销域名分片,移除精灵图,停止文件合并 |
| 流优先级 | 向服务器发送资源重要性信号 | CSS 和字体设为最高优先级;图像设为较低优先级 |
| 103 Early Hints | 在完整响应之前发送预加载提示 | 服务器发送带有 Link: </style.css>; rel=preload 的 103 响应 |
| QUIC/HTTP/3 | 在 CDN 或源站启用 HTTP/3 | 添加 Alt-Svc: h3=":443" 头部以通告 HTTP/3 支持 |
| 头部优化 | 最小化自定义头部以减少开销 | 审计 Cookie 和自定义头部;移除不必要的部分 |
参见:references/http-protocols.md 了解协议比较、迁移策略以及服务器推送与 Early Hints 的对比。
核心理念: 浏览器必须在绘制像素之前构建 DOM、CSSOM 和渲染树。任何阻塞此管道的资源都会延迟首次绘制。优化关键渲染路径意味着识别并消除这些瓶颈。
其原理: CSS 是渲染阻塞的:浏览器在解析完所有 CSS 之前不会进行绘制。JavaScript 默认是解析器阻塞的:<script> 会暂停 DOM 构建,直到脚本下载并执行完毕。字体最多可以阻塞文本渲染 3 秒。每个阻塞资源都会直接增加首次绘制的时间延迟。
关键见解:
async 并行下载脚本并立即执行;defer 并行下载但在 DOM 解析后执行<link rel="preload"> 以高优先级获取关键资源而不阻塞渲染<link rel="prefetch"> 以低优先级为可能的后续导航预取资源font-display: swap 避免字体加载期间的不可见文本代码应用:
| 上下文 | 模式 | 示例 |
|---|---|---|
| 关键 CSS | 在 <head> 中内联首屏样式 | <style>/* 关键样式 */</style> + 异步加载完整 CSS |
| 脚本加载 | 对大多数脚本使用 defer;对独立脚本使用 async | <script src="app.js" defer></script> |
| 资源提示 | 预加载关键字体、英雄图像、首屏资源 | <link rel="preload" href="font.woff2" as="font" crossorigin> |
| 图像优化 | 延迟加载首屏以下的图像;使用现代格式 | <img loading="lazy" src="photo.avif" srcset="..."> |
| 字体加载 | 使用 font-display 防止不可见文本 | @font-face { font-display: swap; } |
参见:references/resource-loading.md 了解 async/defer 行为、资源提示策略和图像优化。
核心理念: 最快的网络请求是根本不发生的请求。分层缓存策略——浏览器内存、磁盘缓存、Service Worker、CDN 和源站——可以显著减少重复访问者和后续导航的加载时间。
其原理: Cache-Control 头部明确告诉浏览器和中间代理响应在多长时间内有效。内容哈希的 URL 支持积极的不可变缓存。Service Worker 提供了一个可编程的缓存层,可以在离线状态下工作。每次缓存命中都消除了一次完整的网络往返。
关键见解:
Cache-Control: max-age=31536000, immutableCache-Control: no-cache 仍然缓存但每次都会重新验证——用于 HTML 文档ETag 和 Last-Modified 支持条件请求(304 Not Modified),节省带宽stale-while-revalidate 立即提供缓存内容,同时在后台获取新副本Vary 头部以避免缓存污染代码应用:
| 上下文 | 模式 | 示例 |
|---|---|---|
| 静态资源 | 使用哈希破坏实现长期不可变缓存 | style.a1b2c3.css 配合 Cache-Control: max-age=31536000, immutable |
| HTML 文档 | 每次请求时重新验证 | Cache-Control: no-cache 配合 ETag 进行条件请求 |
| API 响应 | 短 TTL 配合 stale-while-revalidate | Cache-Control: max-age=60, stale-while-revalidate=3600 |
| 离线支持 | Service Worker 缓存优先策略 | 缓存静态外壳;动态内容采用网络优先 |
| CDN 配置 | 在边缘缓存并配置正确的 Vary 头部 | Vary: Accept-Encoding, Accept 以防止提供错误格式 |
参见:references/caching-strategies.md 了解缓存层次结构、Service Worker 模式和 CDN 配置。
核心理念: 核心 Web 指标——LCP、INP 和 CLS——是谷歌以用户为中心的性能指标,直接影响搜索排名和用户体验。每个指标针对不同的阶段:加载(LCP)、交互性(INP)和视觉稳定性(CLS)。
其原理: 这些指标衡量的是用户实际体验到的,而不是服务器报告的。如果英雄图像加载过晚,页面可能拥有快速的 TTFB 但 LCP 却很差。如果主线程 JavaScript 阻塞了输入处理(INP 差),页面可能加载很快但感觉迟钝。为这些指标优化意味着为真实的用户感知优化。
关键见解:
requestIdleCallback代码应用:
| 上下文 | 模式 | 示例 |
|---|---|---|
| LCP 优化 | 预加载 LCP 元素;设置 fetchpriority="high" | <img src="hero.webp" fetchpriority="high"> |
| INP 优化 | 拆分长任务;让出主线程 | 使用 scheduler.yield() 或 setTimeout 来分块处理工作 |
| CLS 预防 | 为异步内容预留空间 | <img width="800" height="600"> 或 CSS aspect-ratio |
| TTFB 减少 | CDN、服务器端缓存、流式 SSR | 使用 Transfer-Encoding: chunked 进行边缘渲染 |
| 性能预算 | 设置阈值并阻止超出阈值的部署 | 在 CI 流水线中设置 LCP < 2.5 秒,INP < 200 毫秒,CLS < 0.1 |
参见:references/core-web-vitals.md 了解测量工具、调试工作流和优化清单。
核心理念: 当数据必须在客户端和服务器之间持续流动时,选择正确的传输方式——WebSocket、SSE 或长轮询——决定了延迟、资源使用和可扩展性。
其原理: HTTP 的请求-响应模型为实时数据带来了开销。WebSocket 建立了一个持久的全双工连接,帧开销最小(每帧约 2 字节)。服务器发送事件(SSE)通过标准 HTTP 提供更简单的服务器到客户端推送。正确的选择取决于通信是单向还是双向、数据流动的频率以及基础设施限制。
关键见解:
代码应用:
| 上下文 | 模式 | 示例 |
|---|---|---|
| 聊天 / 协作 | 带心跳和重连的 WebSocket | new WebSocket('wss://...') 每 30 秒发送一次 ping |
| 实时动态 / 通知 | 用于服务器到客户端流式传输的 SSE | new EventSource('/api/updates') 带自动重连 |
| 旧版后备 | WebSocket 被阻止时使用长轮询 | 在循环中使用 fetch('/poll') 并设置超时 |
| 连接弹性 | 重连时使用指数退避 | 延迟:1 秒、2 秒、4 秒、8 秒... 上限为 30 秒 |
| 扩展 | 在 WebSocket 服务器后面使用发布/订阅代理 | 使用 Redis Pub/Sub 或 NATS 进行水平扩展 |
参见:references/real-time-communication.md 了解 WebSocket 生命周期、SSE 模式和扩展策略。
| 错误 | 失败原因 | 修复方法 |
|---|---|---|
| 增加带宽来解决页面缓慢问题 | 对于大多数 Web 流量,瓶颈是延迟,而非带宽 | 减少往返次数:预连接、缓存、使用 CDN |
| 一次性加载所有 JS | 解析器阻塞脚本延迟首次绘制和交互性 | 代码分割;使用 defer;延迟加载非关键模块 |
| 没有资源提示 | 浏览器在解析过程中太晚才发现关键资源 | 为首屏关键资源添加 preconnect、preload |
缺少 Cache-Control 或到处使用 no-store | 每次访问都从源站重新下载所有资源 | 为静态资源设置正确的 max-age;使用内容哈希 |
| 忽略 CLS | 布局偏移破坏用户信任并损害搜索排名 | 为所有图像、嵌入内容和广告设置明确的尺寸 |
| 为所有场景使用 WebSocket | 当 SSE 或 HTTP 轮询足够时带来不必要的复杂性 | 根据数据流模式匹配传输方式;服务器推送使用 SSE |
| 在 HTTP/2 上进行域名分片 | 破坏多路复用;创建额外的 TCP 连接 | 合并到一个源;让 HTTP/2 进行多路复用 |
| 未启用压缩 | HTML、CSS、JS 以完整大小传输,浪费带宽 | 在服务器和 CDN 上启用 Brotli(首选)或 Gzip |
| 问题 | 如果否 | 行动 |
|---|---|---|
| TTFB 是否低于 800 毫秒? | 服务器或网络太慢 | 添加 CDN,启用服务器缓存,检查后端 |
| LCP 是否低于 2.5 秒? | 最大元素加载太晚 | 预加载 LCP 资源;设置 fetchpriority="high" |
| INP 是否低于 200 毫秒? | 交互期间主线程被阻塞 | 拆分长任务;延迟非关键 JS |
| CLS 是否低于 0.1? | 元素在初始渲染后发生偏移 | 设置明确的尺寸;为动态内容预留空间 |
| 静态资源是否使用内容哈希缓存? | 重复访问者重新下载所有内容 | 在文件名中添加哈希;设置 Cache-Control: immutable |
| 是否启用了 HTTP/2 或 HTTP/3? | 缺少多路复用和头部压缩 | 在服务器上启用 HTTP/2;通过 CDN 添加 HTTP/3 |
| 渲染阻塞资源是否最小化? | CSS 和同步 JS 延迟首次绘制 | 内联关键 CSS;defer 脚本;移除未使用的 CSS |
| 是否启用了压缩(Brotli/Gzip)? | 传输未压缩的文本资源 | 在服务器/CDN 上启用 Brotli;回退到 Gzip |
此技能基于 Ilya Grigorik 关于浏览器网络和 Web 性能的全面指南:
Ilya Grigorik 是一位 Web 性能工程师、作者和开发者倡导者,曾在谷歌工作十多年,致力于 Chrome、Web 平台性能和 HTTP 标准。他曾是 W3C Web 性能工作组的联合主席,并为 HTTP/2 及相关 Web 标准的开发做出了贡献。他的著作《High Performance Browser Networking》(O'Reilly,2013)被广泛认为是理解浏览器如何与网络交互的权威参考——从 TCP 和 TLS 基础到 HTTP 协议演进,再到实时通信模式。Grigorik 的方法强调,有意义的优化需要理解底层协议,而不仅仅是应用表面技巧,并且延迟是塑造 Web 性能的根本约束。
每周安装数
204
代码库
GitHub 星标数
255
首次出现
2026 年 2 月 23 日
安全审计
安装于
codex196
gemini-cli195
github-copilot195
amp195
kimi-cli195
opencode195
A systematic approach to web performance optimization grounded in how browsers, protocols, and networks actually work. Apply these principles when building frontend applications, reviewing performance budgets, configuring servers, or diagnosing slow page loads.
Latency, not bandwidth, is the bottleneck. Most web performance problems stem from too many round trips, not too little throughput. A 5x bandwidth increase yields diminishing returns; a 5x latency reduction transforms the user experience.
The foundation: Every network request passes through DNS resolution, TCP handshake, TLS negotiation, and HTTP exchange before a single byte of content arrives. Each step adds round-trip latency. High-performance applications minimize round trips, parallelize requests, and eliminate unnecessary network hops. Understanding the protocol stack is not optional -- it is the prerequisite for meaningful optimization.
Goal: 10/10. When reviewing or building web applications, rate performance 0-10 based on adherence to the principles below. A 10/10 means full alignment with all guidelines; lower scores indicate gaps to address. Always provide the current score and specific improvements needed to reach 10/10.
Six domains for building fast, resilient web applications:
Core concept: Every HTTP request pays a latency tax: DNS lookup, TCP three-way handshake, and TLS negotiation -- all before any application data flows. Reducing or eliminating these round trips is the single highest-leverage optimization.
Why it works: Light travels at a finite speed. A packet from New York to London takes ~28ms one way regardless of bandwidth. TCP slow start means new connections begin transmitting slowly. TLS adds 1-2 more round trips. These physics-level constraints cannot be solved with bigger pipes -- only with fewer trips.
Key insights:
dns-prefetchCode applications:
| Context | Pattern | Example |
|---|---|---|
| Connection warmup | Pre-establish connections to critical origins | <link rel="preconnect" href="https://cdn.example.com"> |
| DNS prefetch | Resolve third-party domains early | <link rel="dns-prefetch" href="https://analytics.example.com"> |
| TLS optimization | Enable TLS 1.3 and session resumption | Server config: ssl_protocols TLSv1.3; with session tickets |
| Initial payload | Keep critical HTML under 14KB compressed | Inline critical CSS, defer non-essential scripts |
| Connection reuse |
See: references/network-fundamentals.md for TCP congestion control, bandwidth-delay product, and TLS handshake details.
Core concept: HTTP has evolved from a simple request-response protocol to a multiplexed, binary, server-push-capable system. Choosing the right protocol version and configuring it properly eliminates entire categories of performance problems.
Why it works: HTTP/1.1 forces browsers into workarounds like domain sharding and sprite sheets because it cannot multiplex requests. HTTP/2 solves multiplexing but inherits TCP head-of-line blocking. HTTP/3 (QUIC) moves to UDP, eliminating head-of-line blocking and enabling connection migration. Each generation removes a bottleneck.
Key insights:
103 Early Hints insteadCode applications:
| Context | Pattern | Example |
|---|---|---|
| HTTP/2 migration | Remove HTTP/1.1 workarounds | Undo domain sharding, remove sprite sheets, stop concatenating files |
| Stream prioritization | Signal resource importance to the server | CSS and fonts at highest priority; images at lower priority |
| 103 Early Hints | Send preload hints before the full response | Server sends 103 with Link: </style.css>; rel=preload |
| QUIC/HTTP/3 | Enable HTTP/3 on CDN or origin | Add Alt-Svc: h3=":443" header to advertise HTTP/3 support |
| Header optimization | Minimize custom headers to reduce overhead |
See: references/http-protocols.md for protocol comparison, migration strategies, and server push vs. Early Hints.
Core concept: The browser must build the DOM, CSSOM, and render tree before painting pixels. Any resource that blocks this pipeline delays first paint. Optimizing the critical rendering path means identifying and eliminating these bottlenecks.
Why it works: CSS is render-blocking: the browser will not paint until all CSS is parsed. JavaScript is parser-blocking by default: <script> halts DOM construction until the script downloads and executes. Fonts can block text rendering for up to 3 seconds. Each blocking resource adds latency directly to time-to-first-paint.
Key insights:
async downloads scripts in parallel and executes immediately; defer downloads in parallel but executes after DOM parsing<link rel="preload"> fetches critical resources at high priority without blocking rendering<link rel="prefetch"> fetches resources for likely next navigations at low priorityfont-display: swap to avoid invisible text during font loadingCode applications:
| Context | Pattern | Example |
|---|---|---|
| Critical CSS | Inline above-the-fold styles in <head> | <style>/* critical styles */</style> + async load full CSS |
| Script loading | Use defer for most scripts; async for independent scripts | <script src="app.js" defer></script> |
| Resource hints | Preload critical fonts, hero images, above-fold assets | <link rel="preload" href="font.woff2" as="font" crossorigin> |
See: references/resource-loading.md for async/defer behavior, resource hint strategies, and image optimization.
Core concept: The fastest network request is one that never happens. A layered caching strategy -- browser memory, disk cache, service worker, CDN, and origin -- dramatically reduces load times for repeat visitors and subsequent navigations.
Why it works: Cache-Control headers tell the browser and intermediaries exactly how long a response remains valid. Content-hashed URLs enable aggressive immutable caching. Service workers provide a programmable cache layer that works offline. Each cache hit eliminates a full network round trip.
Key insights:
Cache-Control: max-age=31536000, immutable for content-hashed static assets (JS, CSS, images)Cache-Control: no-cache still caches but revalidates every time -- use for HTML documentsETag and Last-Modified enable conditional requests (304 Not Modified) that save bandwidthstale-while-revalidate serves cached content immediately while fetching a fresh copy in the backgroundVary headers correctly to avoid cache pollutionCode applications:
| Context | Pattern | Example |
|---|---|---|
| Static assets | Long-lived immutable cache with hash busting | style.a1b2c3.css with Cache-Control: max-age=31536000, immutable |
| HTML documents | Revalidate on every request | Cache-Control: no-cache with ETag for conditional requests |
| API responses | Short TTL with stale-while-revalidate | Cache-Control: max-age=60, stale-while-revalidate=3600 |
See: references/caching-strategies.md for cache hierarchy, service worker patterns, and CDN configuration.
Core concept: Core Web Vitals -- LCP, INP, and CLS -- are Google's user-centric performance metrics that directly impact search ranking and user experience. Each metric targets a different phase: loading (LCP), interactivity (INP), and visual stability (CLS).
Why it works: These metrics measure what users actually experience, not what servers report. A page can have a fast TTFB but terrible LCP if the hero image loads late. A page can load quickly but feel sluggish if main-thread JavaScript blocks input handling (poor INP). Optimizing for these metrics means optimizing for real user perception.
Key insights:
requestIdleCallback for non-urgent workCode applications:
| Context | Pattern | Example |
|---|---|---|
| LCP optimization | Preload LCP element; set fetchpriority="high" | <img src="hero.webp" fetchpriority="high"> |
| INP optimization | Break long tasks; yield to main thread | scheduler.yield() or setTimeout to chunk work |
| CLS prevention | Reserve space for async content | <img width="800" height="600"> or CSS aspect-ratio |
See: references/core-web-vitals.md for measurement tools, debugging workflows, and optimization checklists.
Core concept: When data must flow continuously between client and server, choosing the right transport -- WebSocket, SSE, or long polling -- determines latency, resource usage, and scalability.
Why it works: HTTP's request-response model creates overhead for real-time data. WebSocket establishes a persistent full-duplex connection with minimal framing overhead (~2 bytes per frame). Server-Sent Events (SSE) provide a simpler server-to-client push over standard HTTP. The right choice depends on whether communication is unidirectional or bidirectional, how frequently data flows, and infrastructure constraints.
Key insights:
Code applications:
| Context | Pattern | Example |
|---|---|---|
| Chat / collaboration | WebSocket with heartbeat and reconnection | new WebSocket('wss://...') with ping every 30s |
| Live feeds / notifications | SSE for server-to-client streaming | new EventSource('/api/updates') with auto-reconnect |
| Legacy fallback | Long polling when WebSocket is blocked | fetch('/poll') in a loop with timeout |
| Connection resilience | Exponential backoff on reconnection | Delay: 1s, 2s, 4s, 8s... capped at 30s |
| Scaling | Use a pub/sub broker behind WebSocket servers |
See: references/real-time-communication.md for WebSocket lifecycle, SSE patterns, and scaling strategies.
| Mistake | Why It Fails | Fix |
|---|---|---|
| Adding bandwidth to fix slow pages | Latency, not bandwidth, is the bottleneck for most web traffic | Reduce round trips: preconnect, cache, CDN |
| Loading all JS upfront | Parser-blocking scripts delay first paint and interactivity | Code-split; use defer; lazy-load non-critical modules |
| No resource hints | Browser discovers critical resources too late in the parse | Add preconnect, preload for above-fold critical resources |
Cache-Control missing or no-store everywhere | Every visit re-downloads all resources from origin | Set proper max-age for static assets; use content hashing |
| Question | If No | Action |
|---|---|---|
| Is TTFB under 800ms? | Server or network too slow | Add CDN, enable server caching, check backend |
| Is LCP under 2.5s? | Largest element loads too late | Preload LCP resource; set fetchpriority="high" |
| Is INP under 200ms? | Main thread blocked during interactions | Break long tasks; defer non-critical JS |
| Is CLS under 0.1? | Elements shift after initial render | Set explicit dimensions; reserve space for dynamic content |
| Are static assets cached with content hashes? | Repeat visitors re-download everything | Add hash to filenames; set Cache-Control: immutable |
| Is HTTP/2 or HTTP/3 enabled? | Missing multiplexing and header compression | Enable HTTP/2 on server; add HTTP/3 via CDN |
This skill is based on Ilya Grigorik's comprehensive guide to browser networking and web performance:
Ilya Grigorik is a web performance engineer, author, and developer advocate who spent over a decade at Google working on Chrome, web platform performance, and HTTP standards. He was a co-chair of the W3C Web Performance Working Group and contributed to the development of HTTP/2 and related web standards. His book High Performance Browser Networking (O'Reilly, 2013) is widely regarded as the definitive reference for understanding how browsers interact with the network -- from TCP and TLS fundamentals through HTTP protocol evolution to real-time communication patterns. Grigorik's approach emphasizes that meaningful optimization requires understanding the underlying protocols, not just applying surface-level tricks, and that latency is the fundamental constraint shaping web performance.
Weekly Installs
204
Repository
GitHub Stars
255
First Seen
Feb 23, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
codex196
gemini-cli195
github-copilot195
amp195
kimi-cli195
opencode195
ESLint迁移到Oxlint完整指南:JavaScript/TypeScript项目性能优化工具
1,600 周安装
Excel-CLI 命令行工具:Windows Excel 自动化脚本与批处理操作指南
506 周安装
移动应用发布策略指南:从ASO优化到推广渠道的完整发布计划
516 周安装
Shopify应用开发最佳实践指南:React Router、App Bridge与Webhook安全处理
511 周安装
品牌声音准则生成工具 - 从文档、对话和报告自动创建LLM就绪的品牌指南
527 周安装
影响力心理学框架:道德说服的七大原则与应用指南 | 产品设计与营销策略
525 周安装
合规追踪工具 - SOC 2, ISO 27001, GDPR, HIPAA, PCI DSS 框架审计与证据管理
530 周安装
| Keep-alive connections to avoid repeated handshakes |
Connection: keep-alive (default in HTTP/1.1+) |
| Audit cookies and custom headers; remove unnecessary ones |
| Image optimization | Lazy-load below-fold images; use modern formats | <img loading="lazy" src="photo.avif" srcset="..."> |
| Font loading | Prevent invisible text with font-display | @font-face { font-display: swap; } |
| Service worker cache-first strategy |
| Cache static shell; network-first for dynamic content |
| CDN config | Cache at edge with proper Vary headers | Vary: Accept-Encoding, Accept to prevent serving wrong format |
| TTFB reduction | CDN, server-side caching, streaming SSR | Edge rendering with Transfer-Encoding: chunked |
| Performance budget | Set thresholds and block deploys that exceed them | LCP < 2.5s, INP < 200ms, CLS < 0.1 in CI pipeline |
| Redis Pub/Sub or NATS for horizontal scaling |
| Ignoring CLS | Layout shifts destroy user trust and hurt search ranking | Set explicit dimensions on all images, embeds, and ads |
| Using WebSocket for everything | Unnecessary complexity when SSE or HTTP polling suffices | Match transport to data flow pattern; SSE for server push |
| Domain sharding on HTTP/2 | Defeats multiplexing; creates extra TCP connections | Consolidate to one origin; let HTTP/2 multiplex |
| No compression | HTML, CSS, JS transfer at full size, wasting bandwidth | Enable Brotli (preferred) or Gzip on server and CDN |
| Are render-blocking resources minimized? | CSS and sync JS delay first paint | Inline critical CSS; defer scripts; remove unused CSS |
| Is compression enabled (Brotli/Gzip)? | Transferring uncompressed text resources | Enable Brotli on server/CDN; fall back to Gzip |