1招关WordPress头部Google与emoji预解析

大家好，我是保哥。今天聊一个老生常谈但又很多人没搞透的话题：WordPress头部那几行dns-prefetch和preconnect提示，到底要不要清理，怎么清理才不会误伤。这个话题我从2017年第一次在博客上写过，但这些年WordPress内核迭代了好几个版本，钩子换了名字，资源域名也增减过，老教程里的代码搬过来直接用反而会出问题。所以这次我把整个排查、清理、验证的流程从头到尾重新写一遍，并把我自己在十几个站点上踩过的坑都附在里面，希望对你有用。读完这篇你不仅能解决Google域名预解析的问题，还能学会用更工程化的方法应对未来WordPress内核新增的任何资源提示。

先搞清楚问题：那几行代码到底是什么

在国内访问一个WordPress站，按F12打开浏览器开发者工具，再切到Network面板，你常常会看到首屏渲染前后悄悄发出几条DNS查询请求，目标地址是fonts.googleapis.com、ajax.googleapis.com或者s.w.org。这些请求看似无害，但对国内用户来说几乎全是死链，浏览器会傻乎乎地等到超时（默认大约5秒到30秒不等）才放弃，整个页面的"感知速度"就被拖下来了。

这些请求的源头来自WordPress头部HTML里类似下面这样的几行：

<link rel='dns-prefetch' href='//fonts.googleapis.com' />
<link rel='dns-prefetch' href='//ajax.googleapis.com' />
<link rel='dns-prefetch' href='//s.w.org' />
<link rel='preconnect' href='//s.w.org' />

它们是WordPress的"资源提示"机制输出的，目的是让浏览器提前对常用第三方域名做DNS解析、TCP握手甚至TLS协商，从而在真正加载图片、字体或脚本时省下几百毫秒。这个机制本身没错，错的是它对国内网络环境完全不适用：Google系域名在国内大概率连不上，提前解析也是白搭；s.w.org这个域名是WordPress用来托管emoji图片资源的SVG服务，对中文站基本没用。

所以我们要做的事情有两个：第一，关掉对国内不可达域名的DNS预解析；第二，干掉emoji这种不必要的功能负担。把这两件事做对了，国内访客的首屏体验立竿见影地提升一个档次。

这里再补一个我观察到的小坑：很多朋友以为只要把Google字体替换成本地字体就万事大吉，但WordPress的emoji模块仍然会单独发起对s.w.org的连接预热，所以不能只盯着字体。完整的清理方案要把两条线都覆盖到，否则访客打开页面时还是会看到那条孤零零的死亡DNS查询。

识别你的站点是否需要处理

在动手改代码之前，先确认你的站点确实有这些资源提示。最直接的办法是在浏览器里打开任一前端页面，按Ctrl+U查看页面源码，按Ctrl+F搜索关键词。我自己常用的检查清单是：

• 搜索dns-prefetch，看看href里有哪些第三方域名。
• 搜索s.w.org，确认是否有emoji相关的资源。
• 搜索preconnect，看看有没有更激进的连接预热请求。
• 搜索fonts.googleapis，这是Google字体的标志。
• 搜索wp-emoji，确认emoji JS是否被加载。

如果这些关键词全都搜不到，那说明你已经用过某个优化插件或者主题作者已经处理过了，可以跳过本文。如果搜到任意一项，继续往下看。

这里多提一句，部分朋友会担心："我用了Cloudflare CDN，是不是dns-prefetch就不影响国内速度了？"答案是不一定。Cloudflare加速的是你自己服务器的资源，第三方域名是浏览器直连，CDN帮不上忙。换句话说，无论你用什么CDN，只要HTML头部还存在Google域名的dns-prefetch，访客的浏览器就会忠实地去查那个无法到达的DNS。CDN改变不了浏览器的预解析行为。

再有一种常见误判：访客抱怨速度慢，你打开自己的电脑测试却觉得很快。这通常是因为你本地有翻墙工具，Google域名能正常解析，所以预解析瞬间完成。务必用国内裸网环境（4G手机热点、机房大陆节点）做对比测试，才能拿到真实数据。我在2024年给某个客户排查首页慢的问题时就吃过这个亏：自己机房网络下首屏只要1.2秒，客户用上海家庭宽带打开却要5.8秒，差点以为是CDN问题，最后才确认是Google字体DNS超时。

核心方案：一行代码移除资源提示

打开你当前主题的functions.php（或者子主题的functions.php，下面会讲为什么推荐子主题），把下面这段代码加到末尾：

/**
 * 移除WordPress默认输出的dns-prefetch与preconnect资源提示
 * Author: 保哥
 */
remove_action( 'wp_head', 'wp_resource_hints', 2 );

保存上传，清缓存，刷新前端，再看一次源码。dns-prefetch和preconnect那几行应该全部消失了。

这一行代码做的事情很简单：WordPress内核在初始化时把wp_resource_hints这个函数挂在了wp_head这个钩子上、优先级是2，我们用remove_action把它摘下来即可。注意优先级参数2必须和挂载时一致，写错了remove_action会静默失败，不会报错也没有效果。

这是个WordPress钩子机制里的经典坑：remove_action的第三个参数必须和原add_action完全一致，否则相当于你在告诉WordPress "请帮我摘下一个不存在的回调"，自然没有任何效果。这种静默失败最难排查，所以记住一句话：移除回调前先确认它的优先级。确认方式是去翻wp-includes/default-filters.php，搜索wp_resource_hints，看挂载时写的优先级数字是几。

彻底禁用emoji相关资源

上面那一行只解决了dns-prefetch和preconnect，但emoji还会通过另一组钩子加载一段不小的JS和CSS。我们一并清理。完整版本的代码如下：

/**
 * 全面清理WordPress头部多余的资源提示与emoji相关请求
 * Author: 保哥
 */
add_action( 'init', function () {
    // 1. 移除 dns-prefetch / preconnect 输出
    remove_action( 'wp_head', 'wp_resource_hints', 2 );

    // 2. 移除前端 emoji 脚本与样式
    remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
    remove_action( 'wp_print_styles', 'print_emoji_styles' );

    // 3. 移除后台 emoji
    remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
    remove_action( 'admin_print_styles', 'print_emoji_styles' );

    // 4. 移除 RSS 与评论里的 emoji
    remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
    remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
    remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );

    // 5. 防止 TinyMCE 加载 emoji 插件
    add_filter( 'tiny_mce_plugins', function ( $plugins ) {
        return is_array( $plugins ) ? array_diff( $plugins, array( 'wpemoji' ) ) : array();
    } );
} );

这段代码我用add_action( 'init', ... )包了一层，原因是wp_resource_hints这类钩子是在WordPress初始化阶段才注册的，太早或太晚执行remove_action都可能错过时机。挂到init上是最稳妥的位置。

如果你确实要在文章里偶尔用emoji，那只清理资源提示、不动emoji部分，把第2步到第5步注释掉即可。现代浏览器原生支持emoji字符显示，没有wp-emoji-release.min.js也能看到笑脸表情。

再多说一点，WordPress的emoji模块在十年前是为了兼容IE与一些古旧Android浏览器才加进来的。今天主流浏览器对Unicode表情的渲染早已成熟，这套模块的存在意义已经非常有限。我在自己的所有站点上都默认禁用了emoji相关资源，多年来没有任何访客因此投诉过。

保留必要的预解析：自有CDN与统计域名

清理之后并不意味着dns-prefetch就完全不能用了。我们删掉的是WordPress自动加的几条无效提示，但你站点真正需要预解析的域名（比如自己的图床、阿里云的OSS、百度统计、Plausible等）应该手动加回来。在functions.php里继续加：

/**
 * 添加自有需要预解析的域名
 * Author: 保哥
 */
add_filter( 'wp_resource_hints', function ( $urls, $relation_type ) {
    if ( 'dns-prefetch' === $relation_type ) {
        $urls[] = '//cdn.zhangwenbao.com';
        $urls[] = '//hm.baidu.com';
    }
    if ( 'preconnect' === $relation_type ) {
        $urls[] = '//cdn.zhangwenbao.com';
    }
    return $urls;
}, 10, 2 );

注意这里有个矛盾：我们前面用remove_action( 'wp_head', 'wp_resource_hints', 2 )把整个函数从wp_head摘下来了，那wp_resource_hints这个过滤器还有意义吗？答案是没有。如果你需要保留必要的预解析，就不要用remove_action这一招，而是用更精细的过滤：

add_filter( 'wp_resource_hints', function ( $urls, $relation_type ) {
    // 把 Google 与 s.w.org 从默认列表里剔除
    $blocked = array( 'fonts.googleapis.com', 'ajax.googleapis.com', 's.w.org' );
    foreach ( $urls as $key => $url ) {
        $href = is_array( $url ) && isset( $url['href'] ) ? $url['href'] : (string) $url;
        foreach ( $blocked as $domain ) {
            if ( false !== strpos( $href, $domain ) ) {
                unset( $urls[ $key ] );
                break;
            }
        }
    }
    // 加入自己的域名
    if ( 'dns-prefetch' === $relation_type ) {
        $urls[] = '//cdn.zhangwenbao.com';
    }
    return array_values( $urls );
}, 10, 2 );

这套写法的好处是黑名单和白名单一起管理，未来WordPress内核增加新的默认提示时也不会把你打个措手不及。我自己的站点用的就是这一套，运行了三年多没出过问题。

再分享一个进阶建议：如果你的站点引用了多个国内CDN节点（比如静态资源、视频、图片分别用不同的子域名），可以把$urls数组的添加逻辑写成一个配置文件，由运营同事直接维护，开发同事只负责框架。这种切分能让站点在长期演进中保持灵活，不会每次新增CDN都要改一行代码。

验证清理效果与性能对比

改完之后，按下面这个流程做一次完整验证：

1. 用Ctrl+Shift+R硬刷新前端页面，再按Ctrl+U查看源码，确认目标关键词已经消失。
2. 打开开发者工具Network面板，勾选Disable cache，刷新页面，看wp-emoji-release.min.js是否还在请求列表里。
3. 用PageSpeed Insights或者GTmetrix跑一遍，对比清理前后的首屏渲染时间和总阻塞时长。
4. 用webpagetest.org选择上海或北京节点，做一次冷启动测试，看DNS查询的瀑布图是否还有Google系域名。

我自己在某个客户站点上做过对比，清理之前在国内4G网络下首屏需要4.2秒，主要瓶颈就是fonts.googleapis.com的DNS超时；清理之后首屏直接降到1.6秒。这种提升比你折腾任何缓存插件都立竿见影。

如果你想做得更系统，可以把这一类清理动作写成一个内部检查清单，每次接手新站点都跑一遍。我的清单里除了本文讲的资源提示，还有oEmbed、REST API自身的多余链接、xmlrpc端点、版本号暴露等十几项，统一称为"上线前体检"。看似流程化，但能避免你在不同站点之间来回切换时漏掉同一个低级失误。

关于Typecho与其他系统的对照思路

虽然这篇主要讲WordPress，但我自己同时维护着Typecho和WordPress站点，发现这种"内核默认输出对国内不友好的资源提示"的现象不只WordPress独有。Typecho自身没有emoji模块，但很多主题作者会从jsdelivr之类的境外CDN引入字体或脚本，逻辑和这里一模一样。处理思路也完全可以平移：先用浏览器查源码，识别哪些第三方域名是不可达的，再去主题模板里把对应的<link>删掉或换成本地资源。

更进一步说，前端性能优化的本质是"让浏览器的每一次请求都有意义"。无论是WordPress的wp_resource_hints，还是其他CMS的资源加载逻辑，背后都是同一道数学题：用户感知速度等于关键资源到达的最慢一条路径。把那些注定到达不了的请求从HTML里删掉，相当于给整条关键路径松绑。这种思路一旦内化，你以后看任何站点的源码都能自动识别可优化的地方。

我把这种思考方法称作"请求审计"，每次接手新站，第一件事不是看有什么炫酷功能，而是打开Network面板看一遍所有外发请求，把每一条贴着自己的灵魂三问：到达得了吗？到达之后用得上吗？用得上的内容是必需的吗？三个问号下来，往往能砍掉一半以上的无效请求，站点速度自然就上来了。

实战案例：5个客户站点清理前后首屏速度对比

讲了这么多原理，下面把我过去一年半经手过的5个真实客户站点拉出来做对比，让你对清理效果有个具体的预期。所有测试都用国内裸网环境（百度统计的页面加载时长报表 + webpagetest.org上海节点 + 4G手机热点抽测），数据是匿名后的真实数据。

案例A：杭州本地家居博客，2018年建站，主题DUX 6.x。客户反馈打开慢但说不清哪里慢。源码抓出来一看，头部有4条Google域名的dns-prefetch和1条s.w.org的preconnect，还有wp-emoji-release.min.js。按完整方案清理后，webpagetest上海节点测得Document Complete时间从4.2秒降到1.6秒，节省了2.6秒，节省幅度61.9%。客户后台百度统计的"页面加载时长"指标从4.8秒降到1.9秒。

案例B：深圳跨境电商博客，2020年建站，自研主题。这家比较特殊，主题作者自己加了好几条preconnect指向境外的Stripe、PayPal、Google Tag Manager的域名。清理掉Google系两条之后，DOM Content Loaded从3.4秒降到2.1秒。但跟客户确认后，Stripe和PayPal的预解析是必要的（用户结账要走那两个），所以最终只清理了Google和s.w.org这3条。完整对比表格在后面。

案例C：北京某政府公益网站，2017年建站，主题Twenty Seventeen改造版。这家是最典型的"无意识被默认拖累"，没用Google字体、没装任何境外服务，但WordPress内核的默认dns-prefetch照常输出。清理后页面性能没大变化（因为这种政府站本来就轻），但HTML头部从34行精简到21行，对蜘蛛抓取友好度提升了一截。

案例D：上海某独立摄影师作品站，2021年建站，主题Astra Pro。这家用了Astra自带的性能选项，号称已经"禁用Google字体"，但源码里Google字体的dns-prefetch依然存在。问题出在Astra只禁用了字体的实际<link rel="stylesheet">加载，没禁用WordPress内核的资源提示输出。我手动加上本文的remove_action之后才彻底干净。这案例提醒大家：插件标榜的"已禁用"未必真的干净，要源码验证。

案例E：广州某独立咖啡品牌官网，2023年建站，主题GeneratePress + GenerateBlocks。这家是GP本身就比较干净的现代主题，但用户为了加Instagram嵌入装了一个第三方插件，引入了cdninstagram.com等四五个境外域名的preconnect。清理掉GP默认输出的Google emoji相关那部分之后，PageSpeed Insights移动端分数从68升到86。

下面这张表把5个案例的关键数据汇总，方便你预估自己站点的清理收益：

5个案例平均提升39.1%。结论很简单：只要你的站点头部还存在境外域名的dns-prefetch或preconnect，清理基本都能带来30%以上的国内首屏提速，最差的政府公益站也有近20%。这套方案的投入产出比是我见过最高的WordPress优化动作之一。

常见问题解答

清理之后我的文章里再也用不了emoji了吗？

不会。WordPress加载的emoji脚本是为了让老旧浏览器（IE、Android 4自带浏览器等）能看到统一的图形表情。现在主流浏览器都原生支持emoji字符渲染，禁用wp-emoji之后用户依然能看到笑脸符号，只是字形会随系统而变。如果你的访客几乎都用现代浏览器，清理是稳赚的。判断方式很简单：用百度统计或者GA看你站点过去30天的"浏览器版本"分布，IE加旧版Android占比低于2%就可以放心禁用。

我用了WP Rocket或者LiteSpeed Cache，还需要这段代码吗？

这两个插件确实能在面板里勾选"Remove Emoji""Remove Resource Hints"之类的选项，但默认不一定全部开启。如果你已经在插件里勾上了，functions.php里再写一遍是无害的；如果你想脱离插件依赖，那这段代码就是你的救命稻草。我个人偏好用代码而不是插件来做这件事，原因是插件升级或更换时可能把配置忘掉，而代码会跟着主题走。

直接修改wp-includes/default-filters.php行不行？

技术上可行，但和改任何核心文件一样，下次WordPress自动更新会把你的改动覆盖。我从来不推荐这种做法。子主题的functions.php才是正确战场。如果你还没建子主题，强烈建议在改任何代码之前先用"Child Theme Configurator"这类插件一键生成子主题，然后所有自定义代码都放进子主题。

移除s.w.org的preconnect之后会不会影响oEmbed？

不会。s.w.org在WordPress里主要承担两个职责：emoji图片回退和oEmbed的favicon显示。oEmbed本身的内嵌功能不依赖这个域名，只是无法显示某些跨站嵌入的小图标。对中文站来说基本无感。如果你确实需要嵌入海外WordPress站点的卡片预览，可以单独保留s.w.org的dns-prefetch，只移除preconnect，差异在毫秒级。

清理代码加到functions.php后白屏报错怎么办？

大概率是粘贴时引号变成中文全角引号了。WordPress的functions.php严格要求所有PHP代码用半角ASCII引号。错误检查方法：用VSCode或者其他代码编辑器打开functions.php，把'和"这两种引号搜索一遍，确认没有''""这些全角变体。还原方法：用FTP连上服务器，把functions.php下载到本地，删掉刚加的那段，重新上传即可。

WordPress版本升级后这段代码会失效吗？

过去十年里wp_resource_hints这个函数名和挂载方式没变过，但print_emoji_detection_script的优先级在WP 4.2时是7，2024年某个版本悄悄改成了7（一直没变）。每次大版本升级后建议跑一次源码验证，搜dns-prefetch和wp-emoji看是否又出现，5分钟搞定。如果出现了，去wp-includes/default-filters.php找新的优先级数字调一下即可。

能不能用浏览器扩展或者本地代理来过滤这些请求？

可以但不解决问题。浏览器扩展只对你自己生效，访客的浏览器照常去查DNS。本地代理同理。真正修复必须在服务器端把HTML输出修干净，否则永远是治标不治本。我见过一些公司给自家产品经理装扩展"提速"，但客户那边速度根本没变，最后还是要走代码方案。

这件事我每次接手一个新的WordPress老站都要做一遍，已经形成肌肉记忆。关键不是"记住这一行remove_action"，而是理解WordPress的钩子机制：内核做了什么事、挂在哪个钩子上、用什么优先级，你才能精确地把不想要的部分剔除。希望这篇能帮你把站点的国内访问速度再压低一截。我是保哥，下次见。