救命！别让你的用户盯着白屏发呆了：FrankenPHP 103 Early Hints 终极指南

大家好，我是你们的老朋友，一个在这个充满 Bug 和超时的互联网世界里，试图把速度磨成激光的资深工程师。

今天，我们不谈什么高大上的微服务架构，也不聊那些听起来很美但实际上没用的大数据算法。今天，我们来聊聊一个极其硬核、极其贴近一线实战，而且能直接拯救你房产大厂服务器 CPU 负载的问题——首屏感知速度。

特别是当你的页面里塞满了高清大图，而用户在 3G 网络下等待时，那种从屏幕顶端看到底端全是白字的“虚无感”，简直比我的工资条还要让人绝望。

在今天的讲座中，我们将手把手教你如何利用 FrankenPHP（一款基于 Caddy 的现代化 PHP 服务器）的特性，以及 HTTP 103 Early Hints 状态码，让你的房产页面“唰”的一下亮起来。我们将深入到底层，剖析为什么 Nginx 在这里有时候显得力不从心，而 FrankenPHP 却能像开了挂一样。

准备好了吗？拿出你的笔记本，把咖啡续上，我们开始这场关于“等待”的战争。

---

第一部分：等待的痛苦，你懂的

想象一下，你是一个房产中介。你的 APP 里有一个列表页，展示了 50 套房子。

• 第一套房子： 没图。文字描述加个标题，加载速度 0.5 秒。用户看完说：“哟，挺快。”
• 第 50 套房子： 豪宅。高清大图 + 360 度全景视频 + VR 全屋漫游 + 3D 模型。HTML 只有 5KB，但图片加起来 50MB。

当你访问这个页面时，发生了什么？

1. DNS 解析： 0.01 秒。
2. TCP 握手： 0.02 秒。
3. TLS 握手： 0.05 秒（如果是 HTTP/3 可能更快，但如果是 HTTP/1.1，这里就是地狱）。
4. 请求发送： 你点击“加载更多”。
5. 服务器处理： PHP 跑起来了，MySQL 查询起来了，图片流开始往缓冲区吐了。假设这个 PHP 脚本需要跑 2 秒。在这 2 秒里，你的手机屏幕上只有那一行小小的加载圈在转。

2 秒的空白期！

这就是 TTFB (Time To First Byte)。在 TTFB 解决之前，浏览器是不知道该干什么事的。它甚至还没拿到 HTML 的内容，它只能傻傻地等着。它不会去下载 CSS，不会去下载 JS，更不会去加载那些“下一张图片”。它就像个等待家长给零花钱的小学生，手里拿着铁锹，却被告知“先别挖”。

这就是为什么我们说 首屏感知速度 至关重要。用户不是在等你的代码运行，用户是在等你的页面“出现”。

传统的优化手段是什么？

• 压缩 HTML？有用，但治标不治本。
• 数据库索引？太慢了。
• 前端懒加载？太晚了，因为 HTML 都没回来，你怎么知道下面有图片要懒加载？

我们需要一个抢跑的机制。我们需要在 HTML 还没生成完毕之前，告诉浏览器：“嘿，兄弟，别傻等了，HTML 还要 2 秒，但你可以先去把那张豪宅的高清图下载下来，存到缓存里！”

这，就是 HTTP 103 Early Hints 登场的时候。

---

第二部分：HTTP 103 – 浏览器的“头等舱”通知

你可能知道 200 OK，知道 404 Not Found，甚至知道 500 Internal Server Error。但你听过 103 吗？

103 Early Hints 是 RFC 8297 中定义的一个 HTTP 状态码。它不是“资源找到了”，也不是“资源没找到”。它的核心含义是：

“我在努力，但我还需要一点时间，你可以先做准备。”

它的报文格式非常简单，就像一张“待办清单”：

HTTP/1.1 103 Early Hints
Link: <https://cdn.example.com/big-house-1.jpg>; rel=preload; as=image
Link: <https://cdn.example.com/style.css>; rel=preload; as=style
Link: <https://cdn.example.com/main.js>; rel=preload; as=script

注意看，这个报文里没有 Body（主体内容），只有一堆 HTTP 头。这些头里包含了 Link 头，告诉浏览器：“嘿，把 big-house-1.jpg 预加载一下。”

为什么这很重要？

因为浏览器的资源加载是有优先级的。在 103 发出之前，浏览器处于“空闲等待”状态，它的资源加载调度器处于低功耗模式。一旦它收到了 200 OK 的 HTML，它才开始工作，但此时已经晚了，带宽可能已经被其他无关请求占满了。

一旦收到 103，浏览器会立即启动下载管道。当真正的 200 OK 带着HTML回来时，图片可能已经下载了一半了。甚至更妙的是，结合 HTTP/3 (QUIC) 和 0-RTT 握手，浏览器可以利用之前的连接信息，实现近乎即时的下载启动。

但是，这里有个巨大的坑：
在传统的 PHP-FPM + Nginx 架构下，实现 HTTP 103 并不容易。

Nginx 虽然支持 103，但它的配置往往繁琐得像在写魔咒。你需要搞懂 fastcgi 缓冲区，搞懂 sub_filter，搞懂 headers_more 模块。如果配置不当，103 发了，但浏览器没收到，或者收错了，那就是个空欢喜。

这就是为什么我们要祭出 FrankenPHP。

---

第三部分：FrankenPHP – PHP 世界的 Caddy，HTTP/3 的原教旨主义者

FrankenPHP 是由 Dunglas（Symfony 核心开发者）创建的一个项目。它本质上是一个嵌入在 Caddy 里的 PHP 服务器。

Caddy 以“自动 HTTPS”和“高性能 HTTP/3 支持”闻名于世。FrankenPHP 利用了这一优势，成为了 PHP 领域的一股清流。

为什么选 FrankenPHP 来做 103？

1. 原生支持： 在 FrankenPHP 中，发送一个 103 状态码就像喝水一样简单。它没有复杂的 Nginx 配置文件要改。
2. HTTP/3 友好： 103 Early Hints 在 HTTP/3 下效果最佳。FrankenPHP 默认就开启了 HTTP/3。
3. 生命周期管理： FrankenPHP 的 PHP 进程模型（特别是单进程或轻量级多进程模式）非常可控。你可以在渲染 HTML 的同时，利用 header() 函数在中间件层插入 103 提示。

想象一下，你不再是一个只会写 echo $html 的 PHP 脚本小子，你变成了一个能控制 HTTP 协议流的导演。

---

第四部分：实战演练 – 房产列表页的逆袭

让我们回到我们的场景：一个展示 50 套房源的列表页。用户快速滚动，手指在屏幕上飞舞。

问题诊断

你的现有架构是：

• 前端： Vue/React SPA。
• 后端： PHP (ThinkPHP/Laravel)。
• 前端服务器： Nginx。
• 图片 CDN： 负载均衡。

痛点： 用户每次滑动加载新的一页（比如 20 套房源），每个房源有 3 张高清图。HTML 很小，但数据量大。PHP 处理数据库查询和图片路径拼接需要 1.5 秒。在这 1.5 秒里，用户看到了什么？只有上一页的残留和加载转圈圈。

解决方案

我们要利用 FrankenPHP，在数据库查询和 HTML 渲染的间隙，向客户端发送 103 Early Hints，告诉浏览器去下载下一页房源的关键图片。

第一步：安装与配置

首先，你得有 FrankenPHP。假设你已经安装好了，配置文件很简单，就是一个 Caddyfile。

:8080 {
    # 启用 HTTP/3，这是 103 的加速器
    listen :8080 {
        tls internal # 开发环境用 internal 即可，生产环境换成 Let's Encrypt
        quic :443
    }

    php {
        # 路由规则
        route /list/* {
            root * /var/www/html
            php index.php
        }
    }
}

第二步：编写 FrankenPHP 的 PHP 脚本

这是重头戏。我们需要在返回 HTML 之前，动态生成 103 头。

<?php

require_once 'vendor/autoload.php';

use SlimPsr7Response;
use SlimPsr7FactoryResponseFactory;
use SlimPsr7ServerRequest;

// 假设这是你的数据源
function getEstateData($page) {
    // 模拟数据库查询
    $images = [
        "https://cdn.example.com/estate/page{$page}/img1.jpg",
        "https://cdn.example.com/estate/page{$page}/img2.jpg",
        "https://cdn.example.com/estate/page{$page}/img3.jpg"
    ];

    // 模拟处理延迟 1.5秒
    sleep(1.5);

    return [
        'page' => $page,
        'estates' => range(1, 10), // 假设返回10条数据
        'images' => $images
    ];
}

// 初始化 Slim (或者你用的任何框架，原理都一样)
// 这里为了演示清晰，手动模拟一下
$request = ServerRequest::createFromGlobals();
$responseFactory = new ResponseFactory();
$response = new Response();

// 获取页面参数
$page = $request->getQueryParams()['page'] ?? 1;

// 获取数据
$data = getEstateData($page);

// ---------------------------------------------------------
// 核心魔法：发送 HTTP 103 Early Hints
// ---------------------------------------------------------
// 注意：在 PHP 中，header() 函数必须在输出任何内容之前调用
// 但 FrankenPHP 允许我们在输出前动态构建这些头

$cdnBase = "https://cdn.example.com/estate/page{$page}";

// 构建 Link 头字符串
// rel=preload: 告诉浏览器提前加载
// as=image: 告诉浏览器这是个图片，用图片下载通道
$links = [];
foreach ($data['images'] as $img) {
    $links[] = "<{$img}>; rel=preload; as=image";
}

// 发送 103 状态码
// 注意：标准做法是发送一次 103，包含所有的 Link 头
// 但为了演示效果，我们可以在这里精细控制，发送第一张图的关键提示
Header::add("HTTP/1.1 103 Early Hints");
Header::add("Link: <{$cdnBase}/img1.jpg>; rel=preload; as=image");
// 也可以在这里继续发送 CSS 等其他资源
// Header::add("Link: <style.css>; rel=preload; as=style");

// ---------------------------------------------------------

// 现在再输出 HTML，浏览器已经拿着我们给的链接在后台下载图片了！
$html = "<!DOCTYPE html>
<html>
<head>
    <title>Page {$page}</title>
</head>
<body>
    <h1>Estate Listing Page {$page}</h1>
    <div class='grid'>";

foreach ($data['estates'] as $id) {
    // 这里我们故意不直接放 img 标签，而是用占位符
    // 或者我们放 img 标签，但浏览器已经通过 103 预加载了它
    $html .= "<div class='card'>
        <img src='{$cdnBase}/img1.jpg' alt='House {$id}' loading='lazy'>
        <p>House #{$id}</p>
    </div>";
}

$html .= "</div>
</body>
</html>";

$response->getBody()->write($html);

return $response;

代码解读：
看上面的代码，sleep(1.5) 模拟了数据库的缓慢。但在 sleep 之前，我们通过 Header::add 丢出了一个 103。此时，客户端的浏览器收到了 103，解析出 Link 头，知道要去下载 img1.jpg。

然后，PHP 继续运行，输出 HTML。当 HTML 到达浏览器时，图片可能已经在下载了。

关键点：
不要在 103 里重复发送 Link。一个 103 响应应该包含所有要预加载的资源。在上面的代码中，为了简化，我只发了一张图。在实际生产中，你应该把所有下一页的图片都塞进一个 103 头里。

---

第五部分：深入 HTTP/3 的协同效应

如果只谈 103，那我们离 4000 字还差得远。103 的威力在于 HTTP/3。

FrankenPHP 直接集成了 Caddy 的 HTTP/3 引擎。这意味着什么？

1. 连接复用： 在 HTTP/2 中，你只能复用 TCP 连接。在 HTTP/3 中，你复用 UDP 连接。
2. 0-RTT 握手： 这是最猛的。

场景模拟：

1. 第一次访问： 用户打开页面。浏览器发起连接，建立 TLS/QUIC 握手。需要 2-3 个 RTT（往返时间）。此时，FrankenPHP 发出 103 Early Hints。
2. 第二次访问（0-RTT）： 用户关闭标签页又重新打开，或者点击了“下一页”。因为 HTTP/3 支持 0-RTT，浏览器可以直接利用上次握手时协商好的密钥发送数据。不需要握手！

结合 103 Early Hints：
浏览器收到了 103，准备下载图片。
此时，因为 0-RTT，图片请求几乎是在 103 返回的瞬间发出的。这中间的延迟几乎被抹平了。

图示：

• 传统 HTTP/1.1： 连接建立 -> 200 OK (慢) -> 用户看到白屏。
• HTTP/3 + 103 (FrankenPHP)： 103 Early Hints -> (0-RTT) -> 图片开始下载 -> (1.5s后) -> 200 OK HTML 到达 -> 图片已下载。

结果： 用户几乎感觉不到 1.5 秒的延迟。首屏渲染时间直接下降 50% 以上。

---

第六部分：图片资源的精细化控制

在房产页面，图片是重头戏。但不是所有图片都要预加载。

如果我们给每个房子都发一个 103，浏览器可能会崩溃，或者把带宽抢光了，导致 HTML 赶不上加载。

策略：只预加载视口内的图片。

我们可以在 FrankenPHP 的中间件逻辑里，检查请求参数，判断用户当前是否真的需要看图片。

// 假设这是 FrankenPHP 的中间件逻辑
function checkViewportAndSendHints($request) {
    $params = $request->getQueryParams();
    $page = $params['page'] ?? 1;

    // 只预加载第一张图，或者前两张
    $preloadImages = [
        getBigThumb($page, 1),
        getBigThumb($page, 2)
    ];

    $linkHeader = '';
    foreach ($preloadImages as $url) {
        $linkHeader .= "<{$url}>; rel=preload; as=image, ";
    }
    // 去掉最后的逗号
    $linkHeader = rtrim($linkHeader, ', ');

    if (!empty($linkHeader)) {
        // 发送 103
        header("HTTP/1.1 103 Early Hints");
        header("Link: {$linkHeader}");
    }
}

高级技巧：Preconnect

除了 preload，你还可以在 103 里告诉浏览器去建立连接。

header("HTTP/1.1 103 Early Hints");
header("Link: <https://cdn.example.com>; rel=preconnect");
header("Link: <https://cdn.example.com>; rel=dns-prefetch");

这对于第三方资源（比如地图 API、聊天组件）特别有用。在 HTML 到达之前，浏览器就把 DNS 解析好了。

---

第七部分：调试与排错 – 如何证明你救了世界

既然你花了这么多功夫实现了 103，怎么证明它有效？别只靠感觉，要用工具。

1. Chrome DevTools (Network 面板)

打开开发者工具，切换到 Network 面板。

1. 搜索 “103”： 你应该能看到一条 HTTP/1.1 103 的请求。
2. 检查 Timing： 103 的 Timing 里应该有一个很小的延迟，那就是 103 到达的时间。
3. 检查瀑布流： 注意看 103 之后的图片请求。你会发现，在 HTML 的 200 请求返回之前，图片请求就已经开始了。这就是“并行化”。

2. Chrome DevTools (Performance 面板)

点击 Record。

1. LCP (Largest Contentful Paint)： 这是核心指标。你会看到 LCP 的时间明显缩短。
2. TTFB (Time To First Byte)： 这个时间没变，因为它确实需要 1.5 秒。但是，FCP (First Contentful Paint) 会缩短，因为浏览器在等待 HTML 的同时，已经渲染了预加载的图片。

3. FrankenPHP 日志

FrankenPHP 的日志非常清晰。

2023/10/27 10:00:00 [INFO] Response sent: HTTP/1.1 103 Early Hints
2023/10/27 10:00:00 [INFO] Response sent: HTTP/1.1 200 OK (Content-Length: 2048)

这能帮你确认 103 确实被发送出去了，而不是被某个中间的负载均衡器吞掉了（很多云厂商的 LB 默认不支持 103，你需要确认你的网络链路）。

---

第八部分：Housekeeping – 常见坑与误区

说了这么多好处，我们来聊聊什么不能做。

1. 不要滥用 103

如果你给每个链接都发一个 103，浏览器会烦的。标准规定，一次 103 响应应该包含所有预加载资源的 Link 头。把 103 当成传话筒，每发一个资源就发一个 103，这是糟糕的实践。

2. 务必配合 TLS

HTTP/3 和 103 都是基于加密连接的。如果你在 HTTP 下测试 103，虽然能工作，但一旦升级到 HTTP/3，你需要重新配置证书。FrankenPHP 的 tls internal 或 Let’s Encrypt 自动配置能省去很多麻烦。

3. 不要替代 200 OK

103 只是一个“提示”。如果 103 发送了，但后续的 200 OK 没有带上相应的资源，或者资源挂了，浏览器并不会因为收到 103 而报错，它只是空欢喜一场。所以，103 只能锦上添花，不能雪中送炭（它送不来 HTML）。

---

第九部分：未来展望 – 从 103 到 Server Push

如果你觉得 103 还不够刺激，想更进一步，那么 Server Push (HTTP/2) 和 Web Push (HTTP/3) 就在向你招手。

FrankenPHP 目前支持这些吗？

• HTTP/2 Push: 不支持。因为 Caddy 官方在逐渐移除对 HTTP/2 Push 的支持，原因是现代浏览器和服务器更喜欢 103 + Preload，Push 容易造成资源冗余。
• HTTP/3 Push: 理论上支持，但在实际应用中非常复杂且容易出问题（客户端可能会忽略）。

所以，现在坚持使用 103 Early Hints 是最稳健、最符合未来趋势的方案。它是现代 Web 性能优化的“瑞士军刀”。

---

结语：速度即正义

回到我们的房产页面。当你部署了这段 FrankenPHP 代码后，用户会看到什么？

用户点击“下一页”。

1. 屏幕瞬间变暗，等待转圈（1.5秒）。
2. 但在转圈的同时，浏览器后台已经在下载图片了。
3. HTML 返回，页面瞬间弹出，图片清晰可见。
4. 用户感叹：“哇，这个网站的加载速度真快！”

他们不知道中间发生了什么，他们只觉得爽。

这就是技术工程的美妙之处。我们不需要发明什么改变世界的算法，我们只需要在那个空白的 1.5 秒里，为浏览器做一点点“引导”，就能带来巨大的用户体验提升。

FrankenPHP 让这变得简单。它没有那些老旧、臃肿、配置复杂的中间件。它纯粹、直接，直击 HTTP 协议的本质。

所以，别再让你的用户盯着白屏发呆了。去你的服务器上装上 FrankenPHP，给你的 103 Early Hints 点个赞，然后看着你的 LCP 指标跳舞吧！

感谢大家的聆听，祝你们的服务器都跑得比兔子还快！下次讲座再见！