Preconnect 到底该用在哪些域名上？
我在优化一个电商网站的首屏加载速度，听说 preconnect 能减少 DNS、TCP 和 TLS 的握手时间，就试着加了几个。但不确定是不是加多了反而有副作用？
比如我现在页面里用了 CDN 图片、第三方统计脚本、还有支付接口，这三个都加了 preconnect：
<link rel="preconnect" href="https://cdn.example.com" rel="external nofollow" >
<link rel="preconnect" href="https://analytics.vendor.com" rel="external nofollow" >
<link rel="preconnect" href="https://pay.gateway.com" rel="external nofollow" >但 Lighthouse 报告说“避免不必要的 preconnect”，而且我注意到有些请求其实只在用户点击后才触发（比如支付），这种也需要提前连吗？到底怎么判断哪些值得 preconnect？
- 2
回答
27浏览
preconnect明明写了，为什么DNS预解析还是没生效？
在首页头部加了<link rel="preconnect" href="https://cdn.example.com">，但开发者工具网络面板里这个CDN的资源DNS查询时间还是显示"0...
- 1
回答
16浏览
Webpack打包后怎么分析bundle里到底包含了哪些模块？
我用Webpack打包完项目，发现vendor.js特别大，想看看里面到底塞了哪些依赖，但不知道怎么生成分析报告。试过加--analyze参数，但好像没生效？ 网上说要用webpack-bundle-...
- 1
回答
43浏览
前端如何在表单中只收集必要用户信息？
我最近在做一个用户注册页面，产品经理说要遵循数据最小化原则，但我有点拿不准到底该收哪些字段。比如手机号、邮箱、昵称这些是必须的吗？还是说可以只让用户填邮箱就行？ 现在表单里有这些字段：<inpu...
- 1
回答
11浏览
Hippy里怎么监听页面滚动到底部？
我在用 Hippy 开发一个列表页，想在用户滑动到底部时自动加载更多数据。但文档里没找到类似 onScrollEnd 或 onReachBottom 的回调，试了 ScrollView 的 onScr...
- 1
回答
15浏览
域名分片真的还能提升图片加载速度吗？
我最近在优化一个老项目，听说以前用域名分片能绕过浏览器并发限制，就试着把静态资源拆到 cdn1、cdn2 两个子域下。但实际测下来发现首屏图片加载反而更慢了，是不是现在 HTTP/2 普及之后这招已经...
- 1
回答
29浏览
Kraken 中如何正确监听页面滚动到底部事件？
我在用 Kraken 开发一个移动端列表页，想实现滚动到底部自动加载更多数据。但按照文档监听 scroll 事件好像没反应，控制台也不报错。 我试过在页面根元素上加监听，也试过用 document.d...
- 1
回答
16浏览
Cookie 的 Domain 设置到底该怎么配才安全？
我在开发一个子域名下的前端应用，比如 app.example.com，后端设置 Cookie 时指定了 Domain 为 .example.com，这样主站和其他子域都能读到。但听说这样有安全风险，是...
- 1
回答
29浏览
域名分片真的还能提升图片加载速度吗？
我最近在优化一个老项目，听说以前用域名分片能绕过浏览器并发限制，就试着把静态资源拆到 cdn1、cdn2 两个子域下。但实际测下来发现首屏图片加载反而更慢了，是不是现在 HTTP/2 普及后这招已经失...
- 2
回答
17浏览
Nikto扫描结果看不懂，怎么判断哪些是真漏洞？
我用Nikto扫了自己搭的测试站点，出来一堆警告，但分不清哪些是真的安全问题，哪些是误报。比如它说“/server-status”可访问，但我根本没开这个模块，这算漏洞吗？ 试过对照OWASP Top...
- 1
回答
39浏览
React Fiber架构里render和commit阶段到底怎么分工的？
最近在看React源码，对Fiber架构有点懵。我知道更新分render和commit两个阶段，但具体哪些工作是在render阶段做、哪些留到commit阶段执行？比如useEffect和useLay...
1. 关键资源优先，比如首屏必须加载的CDN资源，你加的
https://cdn.example.com是对的；2. 第三方脚本如果阻塞渲染（比如某些A/B测试工具），可以preconnect；
3. 交互后才触发的请求（比如支付接口）就别preconnect了，纯浪费；
你现在的配置里，支付网关那个可以去掉，用户点击支付按钮时才用的连接没必要提前建立。统计脚本要看具体情况，如果是异步加载不影响首屏的也可以去掉。
实测方法很简单：用Chrome DevTools的Performance面板记录加载过程，看哪些域名请求出现在关键渲染路径上。只给这些加preconnect就行，一般2-3个足够了。
代码可以这样优化：
注意加上crossorigin属性，特别是要加载跨域资源时。再提醒下，preconnect有效期很短（Chromium默认大概10秒），所以对首屏之后很久才用到的资源基本没用。
先说你这三个域名的情况：
cd.example.com 这种静态资源域名，如果图片、CSS、JS 是首屏就加载的，加 preconnect 没问题，甚至可以加 dns-prefetch 或 prefetch 一起配合用；
analytics.vendor.com 这种埋点脚本，如果是在首屏就自动发请求（比如 pageview 上报），那也值得 preconnect；但如果只是页面加载完几秒后才发请求，或者用户不滚动就不触发，那加了也没用，反而浪费连接池；
pay.gateway.com 这种明显是交互后才用的（用户点支付按钮才跳），千万别 preconnect，Lighthouse 说的“不必要的”基本就是指这类。
额外提醒几个坑：
preconnect 会提前建立 TCP 和 TLS 握手，占用浏览器的并发连接数（Chrome 默认每个域名最多 6 个连接），如果全站域名都 preconnect，可能把关键请求的连接数挤占了；
最好控制在 3 个以内，最多别超过 6 个；
可以结合用户行为做动态 preconnect，比如用户鼠标悬停在支付按钮上时，再动态插入 link 标签去 preconnect，这样更精准；
验证方式很简单：打开 Chrome DevTools 的 Network 面板，过滤 XHR 或 doc 类型，看哪些请求是首屏必须的，再结合 Lighthouse 的“减少关键请求深度”建议，优先处理那些延迟高、体积大、且跨域的资源。
最后说句实话，preconnect 不是万能药，很多情况下优化资源加载顺序、减少请求数、压缩体积比它更管用，别本末倒置。