域名配置那些事儿从基础到实战的完整指南
长孙美菊优化前：卡得不行
最近接手了一个老项目，用户反映页面加载特别慢，有时候要等个5-6秒才能看到主要内容。打开Chrome DevTools一看，各种资源加载时间长到离谱，特别是第三方资源和CDN的请求，动不动就是2-3秒的延迟。查了一下域名解析时间，有些甚至达到了1.2秒，这还得了？
更气人的是，因为域名配置不当，导致很多资源走了不必要的重定向，DNS查询次数翻倍，TTFB（Time to First Byte）也是居高不下。优化前的页面整体加载时间基本在4.8-5.2秒左右，用户流失率明显偏高。
找到病颈了！
用PageSpeed Insights、WebPageTest这些工具一顿分析，问题主要集中在域名配置和资源加载策略上。DNS解析成了最大的瓶颈，加上一些不合理的子域名配置，让浏览器不得不做额外的DNS查询和TCP握手。
我还发现一个问题，就是静态资源分散在多个不同的域名下，而且没有充分利用浏览器的并发连接能力。每次加载页面都是一堆DNS查询，每个资源都要单独建立TCP连接，这种配置简直是在给性能挖坑。
优化方案：域名合并与CDN配置
首先是域名合并，把原来散落在各个地方的静态资源统一到一个CDN域名下。原来有5-6个不同域名的静态资源，现在整合成2个域名：一个专门放图片资源，一个放CSS/JS文件。
原来的配置：
<link rel="stylesheet" href="https://css.example.com/style.css">
<script src="https://js.example.com/app.js"></script>
<img src="https://img1.example.com/photo1.jpg" />
<img src="https://img2.example.com/photo2.jpg" />
<link rel="stylesheet" href="https://cdn.example.com/vendor.css">优化后的配置：
<link rel="stylesheet" href="https://static-cdn.jztheme.com/css/main-v2.css">
<script src="https://static-cdn.jztheme.com/js/app-v2.js"></script>
<img src="https://images-cdn.jztheme.com/photo1.jpg" />
<img src="https://images-cdn.jztheme.com/photo2.jpg" />这样做的好处是减少了DNS查询次数，从原来的6次减少到2次。而且可以更好地利用HTTP/2的多路复用特性，提高资源加载效率。
DNS预解析和预连接
对于必须要访问的第三方域名，我加了dns-prefetch来提前解析：
<link rel="dns-prefetch" href="//third-party-api.com">
<link rel="dns-prefetch" href="//analytics.google.com">
<link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>这里需要注意一点，preconnect会同时进行DNS查询、TCP握手和TLS协商，如果只是想做DNS解析的话用dns-prefetch就够了，不然会增加不必要的开销。
域名分片的合理使用
之前为了并发加载搞了很多子域名，其实是个误区。现代浏览器对单个域名的并发连接数已经提升到6-8个了，过多的域名反而会增加DNS查询负担。我现在只保留了3个域名：
- 主站域名：处理业务逻辑请求
- 静态资源域名：CSS、JS、字体文件
- 图片资源域名：各种图片资源
原来的配置过于复杂，现在简化了很多。而且每个域名都有明确的用途，方便后续的缓存策略配置。
Cookie优化与域名隔离
我把静态资源的域名设置为完全独立的子域名，避免携带不必要的Cookie。主站域名下的API请求需要认证信息，但静态资源就不需要了：
// 主站域名携带session cookie
// https://www.example.com/api/data (有cookie)
// 静态资源域名不携带任何cookie
// https://static-cdn.jztheme.com/css/style.css (无cookie)这样每次请求静态资源就少了几KB的Cookie传输，对于大流量站点来说节省还是很可观的。
HTTPS证书优化
所有域名都配置了OCSP Stapling，减少了SSL握手时间。证书也统一使用了ECC算法，比RSA握手速度快不少。这里踩过坑，一开始证书链配置不对，导致握手时间特别长。
nginx配置示例：
ssl_certificate /path/to/certificate.crt;
ssl_certificate_key /path/to/private.key;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
# 启用TLS 1.3
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;性能数据对比
优化前后对比数据：
- 首屏加载时间：从5.1秒降到1.8秒
- DOMContentLoaded：从3.2秒降到0.9秒
- DNS查询次数：从6次降到2次
- 平均DNS解析时间：从800ms降到150ms
- 页面整体加载时间：从4.8秒降到1.2秒
效果还是很明显的，特别是DNS解析时间和资源加载并行度的提升。用户的感知速度改善特别大，页面基本1-2秒就能看到主要内容了。
Caching策略配合
域名配置优化后，我也重新调整了缓存策略。静态资源域名设置了较长的max-age，通过文件名版本控制来更新缓存：
location ~* .(js|css|png|jpg|jpeg|gif|ico|svg)$ {
expires 1y;
add_header Cache-Control "public, immutable";
add_header Vary Accept-Encoding;
}这样既保证了缓存效果，又能及时更新资源。域名配置和缓存策略搭配起来，整体性能提升很明显。
以上是我的优化经验，有更好的方案欢迎交流
这次域名配置优化花了我差不多一周时间，主要是要测试各种边界情况。优化过程中也遇到了一些兼容性问题，比如某些老旧浏览器对HTTP/2的支持不够完善，最终还是回到了HTTP/1.1的配置。
总的来说，合理的域名规划确实能带来显著的性能提升，特别是对于高并发的站点来说。DNS查询的优化效果可能在低延迟网络环境下不太明显，但在复杂的网络环境中差异还是很大的。
以上是我踩坑后的总结，希望对你有帮助。如果你们有更优的实现方式欢迎评论区交流，毕竟性能优化这事儿没有银弹，每种方案都有适用场景。
暂无评论