wordpress网站速度优化实战:LCP 从 17 秒降到 2.8 秒的全过程
wordpress网站速度优化实战:LCP 从 17 秒降到 2.8 秒的全过程
这是一篇完整的修复记录。C端woocommerce电商站基于 WordPress + WooCommerce + GeneratePress,优化重灾区,比B端站多太多冗余资源,又杂又难找。
技术栈:WordPress + WooCommerce + GeneratePress 主题 + Code Snippets Pro(所有自定义代码)+ GSAP 动画 + Lenis 平滑滚动,托管在 SiteGround。
PageSpeed Insights 移动端跑分LCP(最大内容渲染)17 秒,页面加载时一片空白,字体闪烁,图片巨大,JS 阻塞严重。30 多个插件同时运行
很常见的电商站配置+很常见的速度问题
问题可以归纳为五大类:渲染阻塞资源、图片过大、JS/CSS 冗余、插件臃肿、动画阻塞首屏渲染。
下面按我实际的优化顺序来讲
第一步:先把缓存优化了,这一步直接上优化插件就行,我比较习惯WP rocket+Asset CleanUp
1. 缓存与压缩
SiteGround 自带 Speed Optimizer 插件,但功能偏基础。WP Rocket很多功能可以和Siteground的自带优化插件协同,各管各的,网站速度评分会加,它的 Delay JS Execution 和 Remove Unused CSS 功能比 SG Optimizer 强很多。
关键配置:
Minify CSS/JS → 开
Combine CSS/JS →不开(极易破坏样式和脚本依赖)
Optimize CSS Delivery → Load CSS Asynchronously(不要选 Remove Unused CSS,会把自定义样式删掉)
Delay JS Execution → 开
Defer JS → 开
LazyLoad Images/iframes → 开
Add missing image dimensions → 开
Preload Links → 开
一个点千万注意:Remove Unused CSS,结果整个网站样式全崩了。切回 Load CSS Asynchronously 后恢复。另外 WP Rocket 和 SG Optimizer不能同时开缓存功能,会冲突。
2. 删除 CSS @import,改用非阻塞加载
我的 Global Design System CSS 里用了 @import url('https://fonts.googleapis.com/...') 加载 Google Fonts。这是一个渲染阻塞操作——这种常见的字体引用操作一定会出现阻塞渲染,带一个迂回操作,其实更直观的是去下载对应的字体文件传到服务器,然后在前端直接调用,这里不展开,感兴趣可以留言评论区里给个方法
修复:删掉 CSS 里的 @import,改用 PHP 在 wp_head 里输出非阻塞的 标签:
add_action('wp_head', function(){
echo '';
echo '';
// media="print" 是关键——不阻塞渲染,onload 后切回 all
echo '';
}, 1);
media="print"技巧的原理:浏览器认为这是打印样式表,不会阻塞渲染,但仍然会下载。下载完成后 onload 把 media 切回 all,字体就生效了。
3. 按页面条件加载 WooCommerce 资源
WooCommerce 默认在所有页面加载它的 CSS 和 JS,包括你的首页、关于我们、FAQ 等根本不需要电商功能的页面。
add_action('wp_enqueue_scripts', function(){
if (is_woocommerce() || is_cart() || is_checkout() || is_account_page()) return;
// 非商城页面,卸载 WC 资源
wp_dequeue_style('woocommerce-general');
wp_dequeue_style('woocommerce-layout');
wp_dequeue_style('woocommerce-smallscreen');
wp_dequeue_script('wc-cart-fragments');
wp_dequeue_script('woocommerce');
wp_dequeue_style('dashicons');
}, 999);
效果:首页和内容页的请求数减少了 6-8 个。
4. 精简 WordPress 核心
WordPress 默认加载了很多你可能永远用不到的东西:
// 禁用 emoji 脚本(~45KB)
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');
// 禁用 oEmbed(嵌入预览)
remove_action('wp_head', 'wp_oembed_add_discovery_links');
remove_action('wp_head', 'wp_oembed_add_host_js');
// 禁用 XML-RPC(安全+性能)
add_filter('xmlrpc_enabled', '__return_false');
// 禁用 wp-embed.js
wp_deregister_script('wp-embed');
// 禁用 jquery-migrate(现代主题不需要)
add_action('wp_default_scripts', function($scripts){
if (!is_admin() && isset($scripts->registered['jquery'])){
$scripts->registered['jquery']->deps =
array_diff($scripts->registered['jquery']->deps, ['jquery-migrate']);
}
});
这些零碎加起来能省 100-200KB,而且减少了 DNS 查询和 HTTP 请求数。
阶段性结果:移动端 PageSpeed 从极低分升到66 分,LCP 从天文数字降到4.1 秒,TBT 从 160ms 降到 30ms。但还远不够。
第三阶段:动画引擎重构——最大的突破
6. 首屏元素跳过动画,LCP 直降 84%
这是整个优化过程中效果最大的一步。
网站用了大量滚动动画:.reveal(渐入)、.split-text(文字拆分)、.wipe-reveal(遮罩揭开)等。这些元素的默认 CSS 是 opacity: 0 或 clip-path 隐藏状态,等 JS 检测到它们进入视口后才触发动画,C端站站点的前端效果可以显著提高留存率,这些动画在建站的时候就规划好了,后期速度慢很大一部分原因是很多插件在每个页面都加载导致页面本身的JS变大。
问题:首屏的标题、按钮、产品图也用了这些动画类。浏览器的渲染流程是:
HTML 解析 → 元素 opacity: 0(不可见)
CSS 加载完成 → 仍然 opacity: 0
JS 下载 + 解析 + 执行 → IntersectionObserver 注册
Observer 触发 → opacity: 1
步骤 3 的延迟直接决定了 LCP。JS 越大、网络越慢,首屏空白时间越长。
修复思路:加一个 isAboveFold() 判断——如果元素在视口 110% 高度以内(首屏),直接跳过动画,立即设为可见状态:
function isAboveFold(el) {
var rect = el.getBoundingClientRect();
return rect.top < window.innerHeight * 1.1;
}
function initScrollReveal() {
var elements = document.querySelectorAll('.reveal, .reveal-left, .reveal-right');
elements.forEach(function(el) {
if (isAboveFold(el)) {
// 首屏元素:跳过动画,直接可见
el.classList.add('visible');
} else {
// 非首屏元素:正常注册 IntersectionObserver
observer.observe(el);
}
});
}
对 .split-text、.split-words、.wipe-reveal 也做了同样处理。
效果:产品页 LCP 从 17.65 秒 → 2.86 秒,降幅 84%。这一个改动比前面所有优化加起来效果都大。
7. 页面过渡动画 + 链接预加载
为了提升页面间导航的体感速度(PageSpeed 不测这个,但用户感知非常明显),我加了两个东西:
CSS 页面过渡:点击链接时,用一个全屏色块做擦除动画(200ms),遮住旧页面的消失过程,新页面加载完后再反向擦除。视觉上感觉是"丝滑切换"而不是"白屏等待"。
Hover 预加载:鼠标悬停在链接上时,注入 ,让浏览器提前下载目标页面。等用户真正点击时,页面大概率已经在缓存里了。
document.addEventListener('mouseover', function(e) {
var link = e.target.closest('a[href]');
if (!link || link.href.includes('#') || link.href.includes('add-to-cart')) return;
if (!document.querySelector('link[href="' + link.href + '"]')) {
var prefetch = document.createElement('link');
prefetch.rel = 'prefetch';
prefetch.href = link.href;
document.head.appendChild(prefetch);
}
});
注意要排除 add-to-cart、AJAX、外部链接等不该预加载的 URL。
第四阶段:插件大扫除
8. 从 30+ 插件精简到 18 个
逐个审查了所有插件,按三个标准分类:
核心必留:WooCommerce、Code Snippets Pro、Stripe/PayPal 支付、Complianz(GDPR 合规)、WP Mail SMTP、Rank Math SEO、Imagify(图片压缩)、WP Rocket。
功能已被代码替代,可删:Smart Custom 404(已用 PHP snippet 的 template_include 过滤器替代)、Asset CleanUp(已用 Performance Boost snippet 的 wp_dequeue 替代)。
插件一定注意能不用就不用,很多插件只管功能不管性能,优化起来很麻烦,你不知道在哪用过在哪没用,也不知道关了会不会崩,毕竟这些插件不是自己装的
一次性减少 10-12 个插件。每个插件即使"停用"了,WordPress 仍然会在 init 阶段扫描它的文件头,多了就是几十毫秒的 TTFB 开销。
第五阶段:图片优化
9. 缩略图尺寸匹配实际显示尺寸
我的"新品上架"轮播卡片在页面上只显示 300x300px,但 PHP 里请求的是 large 尺寸(1024x1024)。改成 woocommerce_thumbnail(300x300)后,这一个组件省了约440KB。
WordPress 的 wp_get_attachment_image() 函数接受一个 $size 参数,很多人习惯写 'full' 或 'large'。实际应该根据 CSS 里元素的最大显示尺寸来选择合适的注册尺寸。
10. 产品主图预加载
产品详情页的 LCP 通常是产品主图。用 PHP 在 里提前 preload:
add_action('wp_head', function() {
if (!is_product()) return;
global $post;
$img_id = get_post_thumbnail_id($post->ID);
if ($img_id) {
$src = wp_get_attachment_image_url($img_id, 'woocommerce_single');
echo '';
}
}, 1);
一个重要认知:PageSpeed 分数 ≠ 真实体感
优化到中后期,我发现分数双端90了,但实际打开速度的提升感并不明显。而用户的真实体感还包括:
维度
PageSpeed 是否覆盖
页面间导航的空白等待
❌
滚动流畅度(掉帧)
❌
点击按钮到响应的延迟
部分(INP)
动画丝滑度
❌
字体/图片闪烁
部分(CLS)
所以我后来调整了优化原则:体感优先于评分。页面过渡动画、hover 预加载、Lenis 平滑滚动——这些对 PageSpeed 分数帮助为零,但对用户感知的提升是巨大的。
优化成果总结
指标
优化前
优化后
降幅
产品页 LCP
17.65s
2.86s
-84%
移动端 PageSpeed
极低
66+
—
首页请求数
70+
~45
-35%
插件数量
30+
~18
-40%
轮播组件体积
~600KB
~160KB
-73%
给 WooCommerce 站长的建议清单
先查图片:
用 DevTools Network 按 Size 排序,找出最大的几张图,通常这是最大瓶颈
按页面条件加载资源:
WooCommerce 的 CSS/JS 不该出现在非商城页面
不要在 CSS 里 @import 字体:
用 + media="print" 替代
首屏元素不要做动画:
或者用 isAboveFold() 判断跳过
审查插件:
每个插件都有 init 成本,能用代码替代的就替代
缓存工具只开一个:
WP Rocket 和主机自带缓存不要同时开
改完一定清缓存再测:
SiteGround 的缓存会让你以为代码没生效
体感比分数重要:
预加载、页面过渡、平滑滚动对分数没帮助,但用户能感受到
技术栈:WordPress 6.x + WooCommerce + GeneratePress + Code Snippets Pro + GSAP + Lenis + WP Rocket + SiteGround



