简介

本指南面向DouPHP项目的生产部署，提供一套可落地的内容压缩与传输优化方案。重点覆盖：

• Gzip/Brotli 压缩策略（文本、图片、字体）
• 静态资源优化（CSS/JS合并压缩、图片懒加载、SVG优化）
• 传输层优化（HTTP/2多路复用、TCP连接复用、带宽利用率提升）
• 压缩效果监控（大小对比、传输时间、CPU使用率）

说明：DouPHP框架本身未内置应用层Gzip/Brotli开关，推荐在Web服务器（Nginx/Apache）或CDN层统一开启；框架侧通过响应头与缓存策略配合，最大化利用浏览器与中间节点缓存。

项目结构

DouPHP采用前后端分离的入口设计，并通过统一的URL重写规则将请求分发到前台、后台与API入口。静态资源（js/css/images）通常由Web服务器直接服务，利于启用传输压缩与长缓存。

graph TB
A["客户端"] --> B["Web服务器<br/>Nginx/Apache"]
B --> C["URL重写<br/>.htaccess"]
C --> D["前台入口 index.php"]
C --> E["后台入口 admin/index.php"]
C --> F["API入口 api/index.php"]
B -.-> G["静态资源<br/>js/css/images/fonts"]

核心组件

• HTTP响应基类：负责设置状态码与响应头并输出正文，是后续扩展压缩头的切入点。
• 安全响应头中间件：在管道前置下发安全相关响应头，便于与压缩/缓存头协同。
• 工具控制器：为静态脚本提供带指纹的强缓存响应头，适合用于构建“预压缩+强缓存”的资源管线。

架构总览

下图展示从请求进入Web服务器到返回压缩内容的整体流程，强调Web服务器层压缩与框架响应头的协作点。

sequenceDiagram
participant C as "客户端"
participant W as "Web服务器"
participant R as "路由/入口"
participant M as "中间件"
participant H as "控制器/业务"
participant S as "响应发送"
C->>W : "HTTP 请求 (Accept-Encoding : gzip, br)"
W->>R : "转发至入口"
R->>M : "执行中间件(安全头等)"
M-->>R : "继续处理"
R->>H : "执行业务逻辑"
H-->>S : "生成响应体"
S-->>W : "Response : : send() 输出状态码与头"
W-->>C : "根据 Accept-Encoding 选择 gzip/br/无压缩"

详细组件分析

1) Gzip 压缩配置（文本内容）

• 适用内容类型：text/html、text/css、application/javascript、application/json、font/*等。
• 建议压缩级别：生产环境使用中等压缩级别以平衡CPU与体积。
• 忽略小文件：避免对极小响应进行压缩，减少CPU开销。
• 浏览器兼容性：现代浏览器均支持gzip；可通过Vary: Accept-Encoding确保正确缓存。

实施要点

• 在Nginx/Apache中启用对应模块并按MIME类型过滤。
• 保持Cache-Control与ETag/Last-Modified配合，使压缩后的资源可被长期缓存。
• 若使用CDN，优先在边缘节点启用压缩，减轻源站压力。

2) 图片格式优化

• 优先使用现代格式：WebP/AVIF，回退到JPEG/PNG。
• 按需尺寸：服务端生成多分辨率缩略图，前端按设备像素比选择。
• 渐进式/有损权衡：列表图适度有损，关键大图保留无损或高质量。
• 懒加载：首屏外图片延迟加载，降低初始传输量。

3) 字体文件压缩策略

• 字体文件（woff2/woff）已自带压缩，无需再次Gzip/Brotli重复压缩。
• 仅加载必要字形，裁剪子集以减少体积。
• 使用font-display优化渲染体验，避免FOIT/FOUT。

4) Brotli 压缩支持

• 现代浏览器兼容性：Chrome/Edge/Firefox/Safari较新版本均支持Brotli。
• 压缩效果对比：Brotli通常比Gzip体积更小，但CPU消耗更高。
• 性能影响评估：在高并发场景下，建议仅在边缘节点或具备硬件加速的环境启用Brotli；源站可仅做Gzip。

实施要点

• Web服务器根据Accept-Encoding协商选择br/gzip。
• 结合Vary: Accept-Encoding保证缓存正确性。
• CDN层优先启用Brotli，源站降级为Gzip作为兼容保障。

5) 静态资源优化（CSS/JS合并压缩、图片懒加载、SVG优化）

• CSS/JS合并与压缩：构建阶段合并、压缩、添加内容哈希；运行时通过强缓存与ETag命中。
• 图片懒加载：首屏以上图片立即加载，其余使用loading="lazy"或IntersectionObserver。
• SVG优化：移除冗余元数据、使用路径而非位图、内联关键SVG减少请求数。

6) 传输层优化（HTTP/2、TCP复用、带宽利用率）

• HTTP/2多路复用：启用HTTP/2，减少队头阻塞，提高并发效率。
• TCP连接复用：Keep-Alive与HTTP/2复用连接，减少握手开销。
• 带宽利用率：合理分片大文件、启用Range请求、使用CDN就近分发。

7) 压缩效果监控（大小对比、传输时间、CPU使用率）

• 大小对比：记录Content-Length与Transfer-Encoding，统计压缩比。
• 传输时间：采集TTFB、首字节、完整下载耗时，区分压缩与非压缩。
• CPU使用率：在压测环境下观察启用压缩前后的CPU占用变化，评估性价比。
• 指标落地：可在中间件或日志中埋点，结合APM/日志平台聚合分析。

依赖关系分析

• URL重写规则决定请求是否进入PHP入口，静态资源通常绕过PHP，直接由Web服务器服务，从而更高效地启用压缩与缓存。
• 框架响应发送集中在Response::send，便于统一注入缓存与安全头，与Web服务器压缩策略形成闭环。
• 安全头中间件在管道前置下发，确保所有响应携带一致的安全策略，避免被后续逻辑覆盖。

graph LR
HT[".htaccess"] --> |重写| PHP["PHP入口"]
PHP --> RESP["Response::send()"]
RESP --> |设置头| WEB["Web服务器"]
WEB --> |压缩/缓存| CL["客户端"]
SEC["安全头中间件"] --> RESP

性能考量

• 压缩算法选择：文本优先Brotli（边缘），源站Gzip兜底；二进制资源（图片/视频）不重复压缩。
• 缓存策略：静态资源使用强缓存与内容哈希，动态内容使用短缓存+ETag。
• 资源优先级：首屏关键CSS/JS内联或尽早加载，非关键资源延后。
• 连接复用：启用HTTP/2与Keep-Alive，减少握手与TLS开销。
• 监控反馈：持续跟踪压缩比、传输时延与CPU占用，动态调优。

故障排查指南

• 未生效压缩：检查Web服务器是否启用相应模块；确认Accept-Encoding包含gzip/br；核对Vary: Accept-Encoding是否正确。
• 缓存异常：确认ETag/Last-Modified与Cache-Control一致；清理浏览器与CDN缓存后复测。
• 安全头缺失：检查中间件是否执行；确认headers_sent前调用；验证配置项security.headers是否生效。
• 性能退化：如启用Brotli后CPU飙升，考虑仅在边缘启用，源站回退Gzip或降低压缩级别。

结论

DouPHP的压缩优化应以“Web服务器/CDN层压缩 + 框架响应头与缓存策略”为核心。通过合理的压缩策略、静态资源优化与传输层调优，并结合监控反馈持续迭代，可在保证稳定性的前提下显著提升页面加载速度与带宽利用率。

附录

• 配置参考位置
  • 应用基础配置：config/config.php
  • 安全响应头配置：config/security.php
  • URL重写与静态资源排除：.htaccess
• 关键代码位置
  • 响应发送入口：core/web/http/Response.php
  • 安全头中间件：core/foundation/middleware/AbstractSecurityHeadersMiddleware.php
  • 静态脚本强缓存示例：admin/controller/tool/ToolController.php