Nginx虽不支持浏览器级懒加载，但可通过强缓存（expires 1y + immutable）、Gzip/Brotli压缩、HTTP/2多路复用、子域名图床、WebP自适应（try_files $uri.webp $uri）等配置，显著提升懒加载资源交付效率与体验。
Nginx 本身不支持前端意义上的“按需延迟加载”（如 loading="lazy" 这类浏览器渲染行为），它无法感知页面滚动或图片是否进入视口。但你可以通过 Nginx 配置，让静态资源交付更高效、更可控，从而支撑前端懒加载真正生效——避免每次触发懒加载都重新请求、重复下载、慢速响应。
设置强缓存，让懒加载不白忙
如果图片每次滚动到视口才去请求，而服务器又没设缓存，那“懒”就变成了“反复加载”。关键不是推迟请求，而是确保请求只发生一次，后续直接走本地缓存。
- 在
location块中匹配常见静态后缀，设置 1 年有效期和immutable -
expires 1y;和add_header Cache-Control "public, immutable";缺一不可 - 对版本化资源（如
/v2.3.1/logo.png）尤其有效，浏览器会永久信任该 URL 不变
启用 Gzip/Brotli 压缩，缩短单次加载耗时
即使只加载一张图片，体积大也会拖慢首屏体验。压缩能显著降低传输时间，尤其对 CSS、JS、SVG 等文本类静态资源。
- 全局开启：
gzip on;，并指定压缩类型（text/css、application/javascript等） - 小文件也值得压：
gzip_min_length 1024;（1KB 以上才压缩）可调低至 256 - 若启用 Brotli（需编译支持），压缩率比 Gzip 高 15%–20%，适合现代浏览器
分离图床 + 启用 HTTP/2，提升并发加载效率
懒加载常伴随多张图片陆续请求。HTTP/1.1 下多个图片会排队，而 HTTP/2 支持多路复用，能真正实现“按需、并发、快速”。
- 为图片资源单独配置子域名（如
img.example.com），并在 server 块中启用http2 - 配合
sendfile on;和tcp_nopush on;，减少内核态拷贝与小包发送开销 - 搭配
open_file_cache缓存文件句柄，避免高并发下反复打开文件
用 try_files + WebP 自适应，减少无效请求
浏览器发来的图片请求，可能本就不需要原图（比如支持 WebP 却返回了 PNG）。Nginx 可主动判断并返回更优格式，相当于“提前优化”，降低带宽和解码压力。
- 利用
try_files $uri.webp $uri;，优先返回同名 WebP 文件 - 结合
map指令识别Accept: image/webp请求头，动态控制是否尝试 WebP - 对不支持 WebP 的旧客户端，自动回落，无需前端额外判断
