性能优化 on 寻 Mi 处

同一个 Hugo 站点，Nginx 配好之后快了一倍

Wed, 11 Jun 2025 21:20:00 +0800

我一开始对 Nginx 托管静态站的理解是，把 root 指过去，try_files 写上，就完事了。

确实能跑。但用 Lighthouse 一测，分数不高。用 curl -w 看各阶段耗时，发现时间都花在传输上，服务器处理只占几毫秒。

也就是说，瓶颈不在 Nginx 的逻辑，在它吐数据的方式。

这篇文章记录一下我把这些都调过一遍之后的结果，首屏从一点六秒降到八百毫秒。

先量一下基线

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\nSize: %{size_download} bytes\n" https://blog.mibase.top/

这个命令把各个阶段拆开。TTFB 是首字节时间，Total 是总时间。两者的差就是传输时间。

我改之前，TTFB 是 0.18 秒，Total 是 1.2 秒。传输花了一秒多，说明 html 本身太大。

看一下首页的大小：

`1`	`curl -s -o /dev/null -w "%{size_download}\n" https://blog.mibase.top/`

一百二十 KB。对于纯文本的 html 来说，太大了。Stack 主题的首页会列出十几篇文章，每篇带摘要，加上内联的 css，确实容易膨胀。

先把 gzip 打开

gzip on;
gzip_vary on;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_proxied any;
gzip_types
    text/plain
    text/css
    text/xml
    text/javascript
    application/javascript
    application/json
    application/xml
    application/rss+xml
    image/svg+xml;

gzip_comp_level 6 是个折中。1 最快但压缩率低，9 最慢但只多压几个百分点。6 是常用的平衡点，压缩一百二十 KB 的 html 大概花 3 毫秒，压到三十 KB。

gzip_min_length 1024 是小于一 KB 的不压。因为压缩本身有开销，小文件压了反而更大。

gzip_vary on 会在响应里加 Vary: Accept-Encoding，告诉缓存层不同编码的响应要分开存。不加这个，中间有缓存的话可能把 gzip 的内容发给不支持 gzip 的客户端。

gzip_proxied any 是让经过代理的请求也压缩。默认只对没有 Via 头的请求压。用了 Cloudflare 之后，请求都带 Via，不加这个就不压了。

gzip_types 里默认不包含 text/html，因为 Nginx 认为 html 一定要压，它是内置的。但别的类型要显式列出来。

brotli 比 gzip 更好

如果 Nginx 编译的时候带了 brotli 模块，可以再上一层。

Debian 和 Ubuntu 的官方包默认不带，得用第三方源：

1
2

sudo apt install -y libbrotli1
# 用 ondrej 的 nginx 源，或者自己编译

装完之后：

brotli on;
brotli_comp_level 6;
brotli_min_length 1024;
brotli_types
    text/plain
    text/css
    text/javascript
    application/javascript
    application/json
    application/xml
    image/svg+xml;

brotli 对文本的压缩率比 gzip 高百分之十五到二十。同样一百二十 KB 的 html，gzip 压到三十 KB，brotli 能压到二十五 KB。

但 brotli 压缩更慢，级别 11 的时候能慢十倍。级别 6 是个合理的点。

还有个细节，brotli 需要 https 才能被浏览器支持。http 下浏览器不接受 br 编码。

缓存头怎么设

静态博客的资源分成两类，一类是带指纹的，一类是不带的。

Hugo 处理过的 css、js 带指纹，比如 main.a1b2c3d4.css。这类可以设一年：

location ~* \.(css|js|woff2?|ttf|eot)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
    access_log off;
}

图片我用的是 Page Bundle 里的原图，文件名不带指纹。这类设短一点，一周：

location ~* \.(jpg|jpeg|png|gif|webp|avif|svg|ico)$ {
    expires 7d;
    add_header Cache-Control "public, max-age=604800";
    access_log off;
}

html 最短：

location ~* \.html$ {
    expires 10m;
    add_header Cache-Control "public, max-age=600, must-revalidate";
}

must-revalidate 让浏览器在缓存过期后必须回源确认，不能拿旧的凑合。

access_log off 是给静态资源的。这些请求量最大，写日志的开销不小，而且它们的日志没什么分析价值。

http2 和 http3

http2 已经是很成熟的东西了，Nginx 从 1.9.5 开始支持。

server {
    listen 443 ssl;
    http2 on;
    ...
}

注意 Nginx 1.25.1 之后语法变了。以前是 listen 443 ssl http2;，现在是单独一行 http2 on;。用老语法会报一个 deprecation 警告。

http2 的好处是多路复用。同一个连接上可以并发多个请求，不用像 http1.1 那样开六个连接。对于首页要加载几十个资源的场景，提升很明显。

http3 基于 QUIC，Nginx 从 1.25 开始有实验性支持，需要单独编译。我试过一次，配置有点麻烦，而且国内很多网络对 UDP 443 不友好。暂时没用。

try_files 的写法

1
2
3

location / {
    try_files $uri $uri/ $uri.html =404;
}

这个写法支持无扩展名的 URL。比如 /p/hello-world/ 会先找目录，找不到再找 /p/hello-world.html。

Hugo 的默认输出是目录加 index.html，所以 $uri/ 那一步就能命中。但如果你改过 uglyURLs，就得靠 $uri.html。

=404 是最后兜底，找不到就返回 404。如果不写这个，Nginx 会返回一个内部的 404 页面，有时候行为不一致。

还有一个优化，把 index 指令写明确：

`1`	`index index.html;`

默认就是 index.html，但写出来能省一次查找。

文件描述符

这个在另一篇里详细说过，这里提一句。静态站请求量大，每个请求都要打开文件，fd 不够会报 Too many open files。

worker_rlimit_nofile 65535;

events {
    worker_connections 8192;
}

worker_rlimit_nofile 是 nginx 自己能打开的文件数上限，要配合 systemd 的 LimitNOFILE 一起调。

sendfile 和 tcp 参数

1
2
3

sendfile on;
tcp_nopush on;
tcp_nodelay on;

sendfile 让 Nginx 用内核的零拷贝直接把文件送到 socket，不用先读到用户态再写出去。静态文件服务必开。

tcp_nopush 是等数据攒够一个包再发，减少小包数量。它和 sendfile 配合使用效果最好。

tcp_nodelay 是不等待，立刻发。它和 tcp_nopush 看起来矛盾，实际上 Nginx 会根据情况自动选择。对于 keepalive 的连接用 nopush，对于要立刻响应的用 nodelay。

keepalive 的调整

1
2

keepalive_timeout 30s;
keepalive_requests 1000;

默认 keepalive_timeout 是 75 秒，太长了，会占着连接不放。30 秒对静态站够用。

keepalive_requests 是单个连接最多处理多少请求。默认 1000，对于首页要加载几十个资源的场景，一次连接就够了。

一个容易忽略的点：open_file_cache

这个功能会缓存打开的文件句柄，减少 open() 系统调用。

open_file_cache max=10000 inactive=30s;
open_file_cache_valid 60s;
open_file_cache_min_uses 2;
open_file_cache_errors on;

max=10000 是最多缓存一万个文件描述符。inactive=30s 是三十秒没被访问就释放。

open_file_cache_min_uses 2 是至少被访问两次才缓存。只访问一次的文件，缓存了也是浪费。

这个对静态站的效果挺明显，尤其是文章页多的时候。我用 strace 看过，开了之后 openat 调用少了很多。

不过要小心，如果你的文件经常变（比如部署的时候覆盖），缓存可能导致短时间读到旧文件。open_file_cache_valid 60s 是六十秒校验一次，影响不大。

部署时的原子替换

Hugo 构建的时候会先写到一个临时目录，然后整体替换 public。但如果在替换的过程中有请求进来，可能读到一半新一半旧的内容。

我的做法是构建到新目录，然后用符号链接切换：

1
2

hugo --minify --gc -d /srv/www/blog/releases/$(date +%s)
ln -sfn /srv/www/blog/releases/$(date +%s) /srv/www/blog/current

Nginx 的 root 指向 /srv/www/blog/current。

符号链接的切换是原子的，Nginx 打开文件的时候会跟随链接，所以不会有中间状态。

这个做法还有个好处，回滚就是把链接指回上一个目录，一秒搞定。

改完之后的效果

`1`	`curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\nSize: %{size_download}\n" https://blog.mibase.top/`

TTFB 0.09 秒，Total 0.28 秒，Size 28 KB。

从一点二秒到零点二八秒。Lighthouse 移动端从 62 分到 96 分。

哪些改动最有用

如果只能做三件事，我会选这三件。

开 gzip，或者 brotli。这个改动最小，收益最大，html 从一百二十 KB 降到三十 KB。

给静态资源设长缓存。第二次访问的时候，浏览器直接用本地的，一个请求都不发。

用 http2。首页要加载几十个资源，多路复用省掉的连接开销很可观。

剩下的 sendfile、open_file_cache 这些，是锦上添花。做不做差别不大，但既然配置一次就能长期生效，顺手做了也没什么坏处。

最后

静态博客的性能优化，本质上是在做两件事。让传输的数据更少，让重复的请求更少。

Nginx 提供了足够多的手段，但大部分默认值不是为静态站调的。花一个小时把这些配置过一遍，之后每一次访问都会受益。

把 Hugo 博客的加载速度从三秒压到八百毫秒

Sun, 29 Dec 2024 20:18:00 +0800

博客搭起来之后，我有一阵子特别在意 Lighthouse 那个分数。

第一次跑的时候，移动端性能 41 分，红色的。首屏内容绘制三点二秒，最大内容绘制四点一秒。这个成绩放在 2024 年，属实难看。

花了一个周末逐项处理，现在稳定在 96 分左右，首屏八百毫秒。这篇记录一下具体做了什么，哪些有用，哪些是白费劲。

先搞清楚慢在哪

别一上来就乱改。先跑一遍 Lighthouse，看它给的诊断项。

打开 Chrome 开发者工具，Lighthouse 标签页，选 Mobile，跑一次。跑完会给你一堆建议，按影响大小排序。

我那次排在最前面的是三件事。图片没有指定尺寸导致布局偏移，字体加载阻塞渲染，还有一个第三方脚本。

改之前先记一下基线，不然改完不知道有没有变好。

图片是最大的问题

我博客的文章配图是直接从手机相册里拖出来的，一张四兆。首页卡片显示的是缩略图，但它加载的其实是原图，浏览器自己缩。

这就很浪费。一个用户打开首页，要下十几兆的图片，手机上还容易因为内存不足崩掉。

Hugo 内置了图片处理，用 Page Bundle 就能直接调：

1
2
3

{{ $img := .Resources.Get "cover.jpg" }}
{{ $small := $img.Resize "800x webp q80" }}
<img src="{{ $small.RelPermalink }}" width="{{ $small.Width }}" height="{{ $small.Height }}" alt="封面">

Resize "800x webp q80" 的意思是，宽度缩到 800，保持比例，转成 webp 格式，质量 80。webp 比 jpg 小百分之三十左右，肉眼几乎看不出区别。

如果要响应式，用 srcset：

{{ $img := .Resources.Get "cover.jpg" }}
{{ $s := $img.Resize "480x webp" }}
{{ $m := $img.Resize "800x webp" }}
{{ $l := $img.Resize "1200x webp" }}
<img
  src="{{ $m.RelPermalink }}"
  srcset="{{ $s.RelPermalink }} 480w, {{ $m.RelPermalink }} 800w, {{ $l.RelPermalink }} 1200w"
  sizes="(max-width: 600px) 480px, (max-width: 900px) 800px, 1200px"
  width="{{ $m.Width }}" height="{{ $m.Height }}"
  loading="lazy" alt="封面">

width 和 height 一定要写。这是 Lighthouse 那个"图片元素没有明确的宽度和高度"的根源。有了这两个属性，浏览器在图片加载之前就能预留出空间，不会发生布局偏移。CLS 这个指标直接从 0.24 降到 0.01。

loading="lazy" 让首屏之外的图片延迟加载。但首屏的图片不要加，加了反而会拖慢 LCP。

字体

Stack 主题默认用的是系统字体栈，本来不该有这个问题。但我自己加了个思源黑体，从 Google Fonts 拉的。

问题在于，Google Fonts 的那个 css 是渲染阻塞的。浏览器必须等它下载完，才能决定用什么字体显示文字。国内访问 Google 的域名还经常超时，一等就是好几秒。

解决办法是把字体下到本地，自己托管：

1
2

mkdir -p static/fonts
wget -O static/fonts/NotoSansSC-Regular.woff2 "https://..."

然后在 css 里：

@font-face {
  font-family: 'Noto Sans SC';
  src: url('/fonts/NotoSansSC-Regular.woff2') format('woff2');
  font-display: swap;
  unicode-range: U+4E00-9FFF;
}

font-display: swap 是关键。它让浏览器先用后备字体显示文字，等自定义字体下载完了再替换。用户不会看到一片空白。

中文字体文件很大，完整的思源黑体有十几兆。所以我又做了一步，用 fonttools 做子集化，只保留常用的三千多个字：

1
2

pip install fonttools brotli
pyftsubset NotoSansSC-Regular.otf --text-file=common.txt --flavor=woff2 --output-file=NotoSansSC-subset.woff2

这样能从十几兆压到六百多 KB。

不过说实话，后来我干脆把自定义字体删了，直接用系统字体栈：

`1`	`font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", sans-serif;`

效果上没什么差别，还省了六百 KB 的下载。这是我折腾一圈之后最实际的一个决定。

渲染阻塞的 css 和 js

Hugo 生成的 css 是通过 resources.Get 和 minify 处理的，Stack 主题已经做得不错了。

但我检查的时候发现，有个 custom.css 是同步加载的，它在 <head> 里，会阻塞渲染。

如果这个 css 不大，可以直接内联：

1
2

{{ $css := resources.Get "css/custom.css" | minify }}
<style>{{ $css.Content | safeCSS }}</style>

内联的好处是省掉一次请求。坏处是不能缓存，每次都要跟着 html 一起下载。所以只适合小文件，几百字节以内。

大一点的用 preload：

1
2

<link rel="preload" href="/css/custom.css" as="style">
<link rel="stylesheet" href="/css/custom.css" media="print" onload="this.media='all'">

这个写法有点绕，原理是先以 media="print" 加载，这样浏览器不会把它当渲染阻塞资源，加载完了再通过 onload 把 media 改成 all。

js 那边，我给所有非关键的脚本都加了 defer：

`1`	`<script src="/js/main.js" defer></script>`

defer 表示下载不阻塞解析，等 html 解析完了再按顺序执行。比 async 更可控，因为 async 的执行顺序不确定。

去掉那个第三方脚本

我在侧边栏加了个访问量统计，用的是某个第三方服务的小挂件。它加载的时候会额外拉三个资源，其中一个还卡了两秒。

看了下它的实现，就是一个 img 加一段脚本。我把它删了，换成了自己写的，用 Cloudflare 的 Workers 记录访问，前端只请求一个自己域名下的接口。

从三个跨域请求变成一个同域请求，这一项就省了将近一秒。

这个教训是，第三方的挂件比自己写的贵得多。你控制不了它的性能，也控制不了它什么时候挂。

缓存策略

静态博客的缓存可以设得很激进。我在 nginx 里给静态资源设了一年：

location ~* \.(css|js|woff2|jpg|jpeg|png|webp|svg)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
}

前提是文件名带指纹。Hugo 的 resources 管道默认会给处理过的资源加 hash，比如 custom.a1b2c3d4.css，改内容就改名字，所以缓存一年也不会出问题。

html 不能这么设，我给了十分钟，加上 must-revalidate。

结构化数据

SEO 这块，除了 title 和 description，最重要的是给搜索引擎结构化数据。

Stack 主题自带了一部分，但不够全。我加了一段 JSON-LD，放在 layouts/partials/head.html 的扩展位置：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": {{ .Title }},
  "datePublished": {{ .Date.Format "2006-01-02T15:04:05Z07:00" }},
  "dateModified": {{ .Lastmod.Format "2006-01-02T15:04:05Z07:00" }},
  "author": {"@type": "Person", "name": "{{ .Site.Params.author }}"},
  "mainEntityOfPage": {"@type": "WebPage", "@id": {{ .Permalink }}}
}
</script>

这个能让搜索结果里显示作者、日期这些信息，点击率会高一些。

sitemap 和 robots

Hugo 默认会生成 sitemap.xml，不用管。

robots.txt 我用的是模板：

User-agent: *
Allow: /
Disallow: /page/

Sitemap: {{ .Site.BaseURL }}sitemap.xml

Disallow: /page/ 是分页页，这些页面内容重复，让爬虫抓了没意义，还分散权重。

收录的情况

提交了 sitemap 之后，我在 Google Search Console 里看，首页三天收录，文章页大概一周。

百度的收录慢很多，而且它对这个域名的抓取频率很低。我后来在百度站长平台手动提交了几次，情况好了一点，但依然不如 Google。

这个我没太纠结。写博客主要是给自己留个记录，有人搜到是意外收获。

那些没用的事

有几个优化我试过但放弃了。

一个是 preconnect 到各种第三方域名。我加了之后 Lighthouse 分数反而掉了两分，因为每个 preconnect 本身也要开销，域名一多就得不偿失。

一个是把 css 全内联。文件一大，html 体积涨到两百多 KB，首字节时间反而变长。现在只内联关键的那部分。

还有一个是 Service Worker 做离线缓存。技术上是能跑，但博客更新频率低，用户很少重复访问同一篇，收益不明显，还容易因为缓存版本没更新导致看到旧内容。

现在的成绩

移动端 96 分，桌面端 99。首屏八百毫秒左右，LCP 一点二秒。

这个分数在个人博客里算不错的，但我越来越觉得分数本身没那么重要。真正有用的是那几个具体的改动，图片压缩、字体本地化、去掉第三方脚本。这三件事做完，体验上的提升是能感觉到的，分数只是顺带的结果。

如果你的博客也慢，我建议先看图片。十有八九，问题就在那儿。