跳到主要内容

Web 应用交付优化

· 阅读需 6 分钟

两个黄金法则:最小化 1) 延迟 2) 负载

最小化延迟…

  • 减少 DNS 查询

    • 使用快速的 DNS 提供商,平均响应时间(cloud flare < DNS Made Easy < AWS Route 53 < GoDaddy < NameCheap)。注意:某些地区的结果可能有所不同
    • DNS 缓存。TTL 权衡 = 性能 <> 时效性
    • 减少第三方域名数量或使用快速 DNS 的服务(与 HTTP1 的域名分片优化冲突)
    • ==DNS 预取== <link rel="dns-prefetch" href="//www.example.com/" >
  • 重用 TCP 连接。

  • 最小化 HTTP 重定向数量

  • 使用 CDN

    • 例如,Netflix 开发自己的硬件并与本地 ISP 合作提供 CDN
  • 消除不必要的资源

  • 在客户端缓存资源

    1. HTTP 缓存头
      • cache-control 用于 max-age
        • 注意,对于 JS 文件:确保浏览器获取更改的简单方法是使用带有哈希的 output.filename 替换。Webpack 缓存
      • expires
        • 如果同时设置了 Expires 和 max-age,则 max-age 将优先。
    2. last-modified,ETag 头以验证自上次加载以来资源是否已更新
      • 基于时间的 Last-Modified 响应头(不常用,因为 nginx 和微服务)
      • 基于内容的 ETag(实体标签)
        • 当最后修改日期难以确定时,此标签非常有用。
        • 通过哈希生成
    3. 一个常见的错误是只设置上述两个中的一个
  • 在传输过程中压缩资产

    • 使用 JPEG、WebP 而不是 PNG
    • HTTP2 自动压缩头部
    • nginx gzipped

最小化负载…

  • 消除不必要的请求字节

    • 特别是对于 cookies
      • 尽管 HTTP 标准未规定头部/ cookie 的大小限制,但浏览器/服务器通常会强制执行…
        • cookies 的 4KB 限制
        • 头部的 8KB ~ 16 KB 限制
      • cookies 会在每个请求中附加
  • 并行处理请求和响应

    • 当浏览器被资源阻塞时,预加载扫描器会提前查看并提前调度下载:约 20% 的提升

应用协议特定优化

  • HTTP 1.x

    • 使用 HTTP keepalive 和 HTTP 管道化:在同一连接上并行调度多个请求,而无需以串行方式等待响应。
    • 浏览器只能打开有限数量的连接到特定域,因此…
      • 域名分片 = 更多来源 * 每个来源 6 个连接(DNS 查询可能引入更多延迟)
      • 打包资源以减少 HTTP 请求
      • 内联小资源
  • HTTP 2.X

    • 引入二进制帧层后,我们获得 每个来源一个连接,并支持多路复用/流优先级/流量控制/服务器推送,因此移除 1.x 优化…
      • 移除不必要的连接和图像拆分
      • 使用服务器推送:之前内联的资源可以被推送并缓存。

工具

参考文献

Want to keep learning more?