关于HTTP/2服务器推送WOFF2字体的可行性及缓存适配方法咨询

Hey David, great questions—HTTP/2 server push for fonts is a tricky but high-impact area, so let’s break this down clearly:

Short answer: Yes, for most modern audiences, but you need to account for edge cases where browsers don’t support WOFF2.

Here’s the breakdown:

• WOFF2 is supported by nearly all modern browsers (Chrome, Firefox, Safari, Edge, etc.)—it’s the most efficient font format available, with 30-50% smaller file sizes than WOFF. Pushing it cuts down on round trips and speeds up text rendering, which aligns perfectly with Zach’s emphasis on fast font delivery.
• For older browsers like IE11 (which only supports WOFF, not WOFF2), you’ll need a fallback strategy. Instead of pushing both formats (which wastes bandwidth), you can:
  • Use user-agent detection on the server to push the appropriate format only if the browser supports it.
  • Serve a CSS @font-face block that lists WOFF2 first, then WOFF as a fallback—browsers will automatically pick the first supported format. In this case, push only WOFF2; unsupported browsers will ignore it and request WOFF separately, and you can choose to push WOFF for those user segments if they make up a meaningful portion of your traffic.

The key is to prioritize WOFF2 for the majority, but avoid over-pushing formats that won’t be used.

Chris Coyer’s approach (and similar industry best practices) centers on using cookies to track cached resources—this is the most reliable way to avoid pushing fonts that the user already has stored locally.

Here’s a step-by-step implementation:

• First visit: When a user requests your page and doesn’t have a cookie indicating the font is cached:
  1. Your server sends the main HTML/CSS response.
  2. Alongside it, you push the WOFF2 font via HTTP/2 server push.
  3. Include a Set-Cookie header in the response: Set-Cookie: woff2_cached=1; Max-Age=31536000; Path=/ (match the Max-Age to your font’s cache TTL to keep them in sync).
• Subsequent visits: When the user returns with the woff2_cached=1 cookie, your server skips pushing the font—since you know it’s already in their browser cache.

Additional considerations:

• Use the Vary: Cookie header on your font responses to ensure CDNs or proxies don’t serve cached versions of the font (or push decisions) to users with different cookie states.
• For private/incognito browsing, cookies won’t persist, so you might push the font again—but this is a minor tradeoff compared to the performance gains for regular users.
• If you have multiple fonts, you can extend this pattern with separate cookies (e.g., font_primary_cached=1, font_secondary_cached=1) or a single cookie with a comma-separated list of cached fonts.

Another alternative is using Service Workers to intercept font requests and trigger push only if the font isn’t cached, but this adds client-side complexity. The cookie-based method is simpler and works across all browsers that support HTTP/2.

内容的提问来源于stack exchange，提问作者David Braun