为什么要禁用 Emoji？
结论先说：大多数企业站、外贸站、产品站不需要 WordPress 自带的 Emoji 兼容脚本。它会在前台加载 wp-emoji-release.min.js（以及一些相关处理），对这类站点来说通常属于“稳定增加请求，几乎不带来收益”。如果你追求更干净的前端输出、更少的 HTTP 请求、更低的渲染负担，禁用它是性价比很高的优化项。
怎么做更稳？先选“禁用力度”
Emoji 相关功能主要分三块：前台/后台的检测脚本与样式、邮件与 RSS 的静态化处理、编辑器（TinyMCE）里的 Emoji 插件。对大多数站点来说，禁用前台输出就够了；如果你还想更彻底，就把邮件、RSS、编辑器也一并处理。
做什么：3 套方案直接用
方案1（推荐）：完整禁用 Emoji（前台 + 后台 + 编辑器 + DNS 预解析）
把下面代码加入主题 functions.php 或自定义功能插件：
add_action('init', function () {
// 前台与后台：移除 Emoji 检测脚本与样式
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('admin_print_scripts', 'print_emoji_detection_script');
remove_action('wp_print_styles', 'print_emoji_styles');
remove_action('admin_print_styles', 'print_emoji_styles');
// 邮件与 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');
// 编辑器（TinyMCE）：移除 Emoji 插件
add_filter('tiny_mce_plugins', function ($plugins) {
if (is_array($plugins)) {
return array_diff($plugins, array('wpemoji'));
}
return array();
});
// 移除 DNS Prefetch：//s.w.org/images/core/emoji/...
add_filter('wp_resource_hints', function ($urls, $relation_type) {
if ($relation_type === 'dns-prefetch') {
$urls = array_diff($urls, array('https://s.w.org'));
}
return $urls;
}, 10, 2);
});这套是最常用、最“关得干净”的版本。对于不靠内容互动吃饭的企业站来说，基本不会带来副作用。
方案2：只禁用前台 Emoji（保守做法，风险最低）
如果你担心后台编辑器或某些插件依赖（虽然很少见），只处理前台即可：
add_action('init', function () {
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');
});这能立刻减少前台输出与请求，适合你只想“先拿到收益”的情况。
方案3：用插件做（不推荐，但有些人就爱这样）
如果你不想动代码，也可以用性能优化类插件关闭 Emoji。缺点也很现实：为了关一个小功能，多引入一个插件和潜在兼容成本，长期维护并不划算。企业站/外贸站更建议直接用方案1或2写进功能插件里，交付后也更稳定。
如何验证是否生效
打开前台页面源码或用浏览器 Network 面板，确认不再加载 wp-emoji-release.min.js，同时页面 head 中不再出现 Emoji 相关输出。如果你还移除了资源提示，通常也不会再看到指向 s.w.org 的 Emoji 预解析。
总结
WordPress 的 Emoji 支持对内容社区型网站有意义，但对大多数企业站、外贸站来说就是纯成本。优先用方案1一次性禁干净；如果你更保守，方案2也能立刻见效。别把这种基础优化交给一堆插件去“代劳”，服务器会少受点罪，你也少背点锅。