HTTPS静态资源加载慢通常不在证书本身，而源于协议协商低效（如HTTP/2未启用）、TLS握手频繁（会话复用缺失）、代理链路退化（HTTP/1.0导致连接重建）或静态文件路径配置错误（root/alias不匹配、权限不足）。
HTTPS 全站启用后静态资源加载慢，问题通常不在证书本身，而在于协议协商、连接复用、缓存策略或文件服务路径这几个环节。直接看 Network 面板里单个 JS/CSS 图片的 TTFB（首字节时间）是否普遍超过 300ms，就能快速区分是 TLS 层还是 HTTP 层的问题。
查协议与握手耗时
打开 Chrome DevTools → Network → 刷新页面 → 看 Protocol 列：
- 若显示 h1 或空白，说明 HTTP/2 没生效，需确认 Nginx listen 指令含
http2，且证书支持 ALPN（Let’s Encrypt 默认支持，自签名需重签） - 若 Protocol 是 h2 但 TTFB 仍高，点开某资源 → Timing 标签页 → 关注 “SSL” 和 “Connection setup” 时间：超过 200ms 说明 TLS 握手频繁，需检查会话复用配置
- 执行
curl -I --http2 https://your-domain.com，返回头不含HTTP/2 200，则 HTTP/2 未启用或被降级
验会话复用与加密套件
移动端 WebView 尤其依赖会话复用，否则每次新建连接都走完整 TLS 握手：
- 确保全局启用了共享缓存：
ssl_session_cache shared:SSL:10m;（放在 http 块） - 延长超时：
ssl_session_timeout 10m; - 关闭不稳定的 Session Tickets：
ssl_session_tickets off; - 加密套件精简为现代组合：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; - 仅保留 TLSv1.2 和 TLSv1.3：
ssl_protocols TLSv1.2 TLSv1.3;
看代理链路与后端通信
如果 Nginx 是反向代理（比如转发 /api 或静态资源到另一服务），默认用 HTTP/1.0，会导致每个请求重建 TCP 连接：
- 在对应 location 或 server 块中添加：
proxy_http_version 1.1; - 确保后端响应包含
Connection: keep-alive头（Spring Boot、Node.js 默认支持，Tomcat 需确认 connector 配置） - 若代理 WebSocket，补上：
proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";
核静态资源服务配置本身
HTTPS 能建立，不代表文件能读取——这是最常被忽略的“隐身故障”：
- 检查
location块是否匹配到资源后缀，比如location ~ \.(js|css|png)$是否覆盖实际路径 - 确认
root或alias路径正确，且文件系统权限允许 Nginx worker 进程读取（如ls -l /path/to/static） - 开启浏览器缓存：
expires 7d;并移除add_header Cache-Control no-cache; - 启用 Gzip：
gzip on;+gzip_types text/css application/javascript image/svg+xml;（注意 mime.types 中定义的类型要一致）
不复杂但容易忽略
