很多 WordPress 站长做性能优化时,最容易卡在插件选择上:有人说 WP Rocket 一键缓存最省心,也有人说 Perfmatters 更轻、更适合精细化控制;图片优化又会遇到 Imagify vs Smush peut-être Smush vs Imagify 的纠结。问题是,这四个插件并不是同一类工具,如果只看“哪个评分高”,很容易装错组合,甚至把网站越优化越慢。
这篇文章不做简单的“谁第一名”排名,而是按照真实使用场景来拆:缓存和前端资源优化看 WP Rocket 与 Perfmatters;图片压缩、WebP、媒体库批处理看 Imagify 与 Smush。你可以把它当作一份上线前的插件搭配清单,尤其适合企业官网、Elementor 站点、WooCommerce 商店和内容型博客。

先说结论:不要把四个插件当成同一个赛道
如果你只想要一个最省心的缓存插件,WP Rocket 通常更适合;如果你已经有服务器缓存、LiteSpeed Cache、Cloudflare APO 或托管主机自带缓存,只想关闭多余脚本、延迟加载、减少前端请求,Perfmatters 更容易发挥价值。两者可以同时使用,但要避免功能重复,例如延迟 JS、Lazy Load、预加载、数据库清理等选项不要两边都开。
图片优化方面,Imagify 和 Smush 的定位更接近,二选一更稳。Imagify 的优势是压缩策略直接、WebP/AVIF 转换体验清晰,适合希望快速处理整站图片的用户;Smush 的优势是免费功能友好、界面容易理解,适合预算有限、图片量不算特别大的站点。不要同时启用两个图片压缩插件去处理同一批图片,否则可能出现重复压缩、备份混乱、文件体积不降反升的问题。
Perfmatters vs WP Rocket:核心差异是什么?
WP Rocket 的核心价值是缓存与整体加速。它面向的用户是“我不想研究太多技术细节,但希望打开几个开关后速度明显提升”。常见功能包括页面缓存、缓存预加载、文件优化、延迟加载图片、延迟 JavaScript、数据库清理、CDN 设置等。对于普通共享主机、Nginx/Apache 环境、没有复杂服务器缓存的站点,WP Rocket 的上手成本很低。
Perfmatters 更像一把手术刀。它不是传统意义上的页面缓存插件,而是帮助你禁用 WordPress 不必要的功能、按页面管理脚本、延迟加载资源、优化 Google Fonts、本地化分析脚本、减少 WooCommerce 非购物页资源加载。它特别适合已经有缓存方案、但前端资源仍然臃肿的网站。
举个例子:一个 Elementor 企业站,首页加载了表单、滑块、弹窗、图标库和 WooCommerce 样式,但产品页并不多。WP Rocket 能解决缓存和部分文件优化问题;Perfmatters 则可以把某些页面根本用不到的脚本禁用掉。两者关注点不同,WP Rocket 解决“页面能不能缓存、资源能不能延迟”,Perfmatters 解决“这些资源该不该出现在这个页面”。
什么时候选 WP Rocket?
如果你的网站没有成熟缓存体系,或者你不确定主机层缓存是否配置正确,WP Rocket 是更稳的第一选择。它适合以下情况:站点访问量中小、使用普通主机或 VPS、没有专门运维人员、希望减少 TTFB 和重复生成页面的压力、想快速开启缓存预加载和基础文件优化。
WP Rocket 的另一个优势是文档和兼容经验比较丰富。遇到 Elementor、WooCommerce、Contact Form 7、Rank Math、Yoast、Cloudflare 等常见组合时,网上能找到很多排查案例。对于不想每天调参数的站长来说,这种“省心”本身就很值钱。
但 WP Rocket 不是万能按钮。文件压缩、合并、延迟 JS 这些功能要逐项测试,尤其是有轮播图、弹窗、支付按钮、会员登录、地图、聊天工具的网站。建议每开启一个关键选项,就用无痕窗口检查首页、文章页、产品页、结账页和移动端菜单,确认没有交互失效。
什么时候选 Perfmatters?
如果你已经有 LiteSpeed Cache、Cloudflare、Kinsta/Cloudways/SiteGround 等主机层缓存,或者网站最大问题不是缓存,而是前端脚本太多,那么 Perfmatters 更值得考虑。它适合有一定排查能力的站长,尤其是愿意按页面测试资源加载的人。
Perfmatters 的 Script Manager 是很多用户选择它的原因。比如表单插件只在联系页面使用,没必要全站加载;WooCommerce 的购物车碎片脚本不一定要在所有内容页运行;某些营销弹窗只在落地页出现,也不该拖慢整个站点。通过按页面禁用脚本,往往比单纯压缩文件更有效。
不过,Perfmatters 的门槛也在这里。你需要知道某个脚本属于哪个插件,禁用后会影响哪个功能。第一次使用时不要全站批量关闭,最好从测试站或低风险页面开始。每次只调整一类资源,并记录修改前后的 PageSpeed、WebPageTest 或浏览器 DevTools 数据。
Perfmatters 和 WP Rocket 可以一起用吗?
可以,但前提是分工明确。比较常见的组合是:WP Rocket 负责页面缓存、缓存预加载、基础延迟加载;Perfmatters 负责禁用无用功能、脚本管理、字体优化和局部资源控制。这样搭配时,最重要的是避免重复开启同类功能。
例如 Lazy Load 不要两个插件都开;延迟 JS 不要两边同时处理同一个文件;数据库清理选择一个插件即可;预加载、预连接、DNS Prefetch 也要统一管理。重复优化不是双倍效果,很多时候会变成冲突、闪屏、按钮失效或后台难以排查。
如果你的网站以 WooCommerce 为主,还要特别注意购物车、结账、我的账户页面不要被错误缓存。WP Rocket 通常会自动排除关键页面,但站点做过自定义 URL、多语言路径或会员插件时,仍然建议手动确认。Perfmatters 在 WooCommerce 资源禁用上也要谨慎,不能为了首页分数牺牲转化流程。

Imagify vs Smush:图片优化该怎么选?
图片往往是 WordPress 页面体积的大头,尤其是作品集、产品图、博客配图、Banner 很多的网站。Imagify vs Smush 的选择,本质上是在“压缩效率、格式转换、免费额度、操作习惯”之间做平衡。
Imagify 的体验偏直接:选择压缩级别,批量优化媒体库,并生成现代图片格式。它适合希望尽快把图片体积降下来、愿意为稳定批量处理付费的站点。对于图片较多、追求 WebP/AVIF 的内容站和电商站,Imagify 通常更利落。
Smush 的优势是入门友好,免费版对很多小站已经够用,界面也比较容易理解。它适合刚开始做性能优化、图片数量有限、预算敏感的站点。如果你只是每周发几篇文章,图片不算大,Smush 的免费功能可能已经能解决大部分问题。
Smush vs Imagify:别只看压缩率,还要看恢复能力
很多人比较 Smush vs Imagify 时,只盯着“压缩后小了多少 KB”。这当然重要,但不是唯一指标。更实际的问题是:原图是否保留?压缩后画质能否接受?是否支持 WebP 或 AVIF?是否能批量处理历史图片?删除插件后图片是否还能正常访问?是否与 CDN、缓存插件、主题的响应式图片机制兼容?
如果你是摄影、设计、家居、跨境电商这类重视觉网站,压缩质量要放在第一位。不要为了把 PageSpeed 分数从 89 拉到 95,把产品图压得发灰、发糊。建议先抽取 20 张典型图片测试:大 Banner、产品图、文章配图、透明 PNG、移动端裁剪图都要覆盖。确认画质和兼容性后,再批量处理整站媒体库。
另外,图片插件不是 CDN 的替代品。图片压缩解决的是文件体积,CDN 解决的是访问距离和分发速度,缓存插件解决的是页面生成和资源加载策略。三者互相配合,但不要混为一谈。
推荐搭配:按网站类型选择
普通企业官网:WP Rocket + Imagify 是省心组合。前者解决缓存和基础优化,后者处理图片体积。设置好后维护成本低,适合没有专职技术人员的团队。
Elementor 或页面构建器站点:WP Rocket + Perfmatters + Imagify 更有空间,但也更需要测试。Elementor 常见问题是 CSS/JS 资源多、第三方组件多,Perfmatters 的按页脚本管理能补上 WP Rocket 的不足。
LiteSpeed 主机网站:如果你已经用 LiteSpeed Cache 做页面缓存,通常不需要再上 WP Rocket。这时可以考虑 Perfmatters + Imagify 或 Smush。缓存插件重复安装,往往比不优化更麻烦。
预算有限的小博客:先用主机缓存或免费缓存方案,再搭配 Smush 免费版。等文章数量、图片数量和收入上来后,再评估 Imagify 或更完整的缓存方案。
WooCommerce 商店:优先保证购物流程稳定。缓存插件要正确排除购物车、结账、账户页;图片插件要保证产品图清晰;Perfmatters 禁用脚本时不要影响变体切换、加入购物车、支付按钮和库存刷新。
上线前测试清单
- 开启缓存后,检查首页、分类页、文章页、产品页、结账页是否正常。
- 延迟 JavaScript 后,测试菜单、搜索、弹窗、表单、轮播图、支付按钮。
- 图片压缩前先备份 uploads 目录和数据库。
- 批量生成 WebP/AVIF 后,检查 Safari、Chrome、移动端是否正常显示。
- 只保留一个图片优化插件,不要让 Imagify 和 Smush 同时处理同一批图片。
- 每次只改一类设置,记录修改时间和测试结果。
如果你正在做更系统的站点提速,可以继续阅读 361sale 之前的 Perfmatters vs WP Rocket 加速插件选择指南,也可以参考 Elementor 编辑器加载很慢的排查顺序。性能优化不是堆插件,而是把缓存、资源、图片、服务器和主题模板逐层理顺。
FAQ:常见问题
Perfmatters vs WP Rocket,哪个更适合新手?
新手通常先选 WP Rocket,因为它的缓存和基础优化更完整,配置路径也更直观。Perfmatters 更适合已经知道网站慢在哪里,并愿意按页面管理脚本的用户。
Imagify vs Smush,哪个压缩效果更好?
不同图片类型结果会不一样。Imagify 在批量压缩和现代格式转换上更直接,Smush 入门和免费使用更友好。建议用自己站点的真实图片测试,而不是只看别人给出的压缩率。
可以同时安装 Imagify 和 Smush 吗?
不建议。图片优化插件最好二选一,同时使用容易造成重复压缩、备份混乱和排查困难。除非你非常清楚每个插件负责的文件范围,否则不要混用。
总结:先分工,再搭配
Perfmatters vs WP Rocket 的关键不是谁完全取代谁,而是缓存与资源控制的分工;Imagify vs Smush 的关键也不是谁永远最好,而是图片量、预算、画质和格式转换需求。大多数站点可以从“一个缓存方案 + 一个图片优化插件”开始,等数据证明还有瓶颈,再加入 Perfmatters 做精细化管理。少装、少重复、可回滚,才是 WordPress 性能优化最稳的路线。
Lien vers cet article :https://www.361sale.com/fr/87789/L'article est protégé par le droit d'auteur et doit être reproduit avec mention.


















11 mars 13:490
Aujourd'hui, le référencement est toujours d'actualité, mais le jeu a changé. Auparavant, on s'appuyait sur des tas de contenus, des tas de mots-clés pour obtenir du trafic, et maintenant on accorde plus d'attention à la qualité du contenu + à la confiance dans la marque + à l'expérience de l'utilisateur. En plus de s'appuyer uniquement sur le SEO est en fait de plus en plus difficile, beaucoup de bonnes SEO + médias sociaux + marketing de contenu + conversion de domaine privé à faire ensemble. Le référencement reste un canal d'acquisition de clients à long terme, mais il ne peut plus être considéré comme le seul canal.Il travaille dur.
11 mars 10:540
Normal, inclus seulement au nom de Google pour voir la page, ne signifie pas qu'immédiatement au classement, "a été inclus mais n'a pas été classé" habituellement parce que : la concurrence des mots-clés, le poids de la page est faible, le contenu n'est pas assez fort, la page est relativement nouvelle. Continuez à optimiser les mots-clés à longue traîne, la qualité du contenu et la chaîne interne, il faut généralement un peu de temps pour que le classement s'améliore lentement !Amelia Foster 6 mars 16:200
Avez-vous une capture d'écran ?lit. même un fils qui n'est pas un poisson connaît la joie du poisson 6 mars 09:230
Ne commencez pas par utiliser les plugins d'optimisation, mais localisez d'abord les goulets d'étranglement : Utilisez Query Monitor pour voir les SQL lents, les crochets lents. Mettez tous les plugins en pause pour les comparer, puis activez-les un par un. Vérifier que l'autoload est trop grand (tableau des options). Vérifier les index de la base de données avec les requêtes de tables volumineuses. S'attaquer d'abord aux performances de l'hôte et de la base de données si le TTFB du serveur est élevé.Il travaille dur.
3 mars 16:470
Bonjour Windjammer, il n'y a vraiment pas besoin de s'embêter avec des environnements locaux compliqués, les gens ordinaires suivent ces étapes et la mise à jour ne fera pas planter le site 👇. Tout d'abord, sauvegarder l'ensemble du site, fichiers + base de données sont préparés, c'est la ligne de fond, hors du problème peut être une clé pour revenir en arrière. Si vous voulez mettre à jour votre site, ne le faites pas en un seul clic, mais faites-le par lots, changez d'abord les plugins sans importance, puis les principaux. Immédiatement après la mise à jour, videz le cache, passez au premier plan pour vérifier la page d'accueil, la page d'article, les boutons, les formulaires, ces positions clés. Il est préférable d'installer un plug-in qui prend en charge le retour à la version précédente ; en cas de panne, il est possible de revenir à l'ancienne version en une seconde. En résumé : sauvegarder d'abord, changer par lots, vérifier après avoir changé, laisser un moyen de revenir en arrière, très stable ✅😎 J'espère que cela vous aidera !bugbang 2 mars 09:550
En général, ce n'est pas le paiement qui n'a pas fonctionné, mais le rappel (webhook) qui n'a pas renvoyé l'état de la commande. Étapes de dépannage : WooCommerce → Statut → Logs : voir si la passerelle de paiement a une erreur de webhook / une erreur de signature / un dépassement de délai. Vérifiez si le site est bloqué par un WAF (Cloudflare, Pagoda Firewall, plugins de sécurité). Vérifiez si l'option "Cache checkout pages/interface paths" est activée (les pages de paiement et les interfaces de rappel ne doivent pas être mises en cache). Recherchez dans les journaux d'erreurs du serveur les erreurs 500/fatal qui interrompent l'exécution du callback. Solution : Libérer les URLs de rappel de wp-json, wc-api et de la passerelle de paiement (configurer selon la documentation de la passerelle). Désactiver le cache et le test de compression JS merge sur la page de paiement une fois. Si vous utilisez Cloudflare : définissez les règles "no-challenge" et "no-block" pour les URL de rappel.Ulla Nala Zhenhuan (18嬛嬛嬛) 31 janvier 09:360
1) Déterminer s'il s'agit d'une "attente normale" ou d'un "blocage anormal". Vous pouvez d'abord examiner trois signaux : si le délai de publication de la page est compris entre 7 et 14 jours, s'il n'y a qu'un petit nombre de pages avec ce statut et si la page est apparue dans le plan du site XML. Si ces trois éléments sont réunis, il s'agit très probablement d'une étape normale d'exploration et d'évaluation, et il n'est pas nécessaire d'intervenir immédiatement. 2) Dans quelles circonstances "attendre" est-il inutile ? Les cas suivants ne seront pas résolus automatiquement par le temps : la page n'a presque pas de liens internes (page isolée), le contenu est très similaire aux pages existantes sur le site, les points canoniques renvoient à d'autres URL, et trop d'articles similaires sont publiés sur le même sujet pendant une courte période. Dans ce cas, Google a été parcouru, mais a jugé que "cela ne vaut pas la peine d'entrer dans l'index". 3) La façon la plus efficace d'intervenir manuellement (sans chichis) La priorité est de faire ces 3 choses : ajouter des liens internes, créer un lien vers la page à partir d'anciens articles ou rubriques connexes, améliorer la densité de l'information sur le premier écran. Les 2-3 premiers paragraphes répondent directement à la question de l'utilisateur, évitent trop de remplissage, confirment que la page canonique est autoréférentielle pour éviter d'être jugée comme une page dupliquée, puis vont au SGC pour demander la réindexation. 4) Quelles sont les "actions d'intervention" contre-productives ? Déconseillées : supprimer et reposter fréquemment, cliquer plusieurs fois de suite sur "demander l'indexation", forcer l'empilement de mots-clés pour être indexé, changer arbitrairement d'URL ou de titre. Ces opérations permettront à Google de réévaluer la stabilité de la page, mais ralentiront l'inclusion. 5) Une norme de jugement pratique Si un article : a été crawlé, il n'y a pas de problème de noindex / robots, il y a au moins 1-2 liens internes connexes, le contenu résout manifestement un problème indépendant, il est inclus, ce n'est qu'une question de temps, ce n'est pas un problème de plug-in.Porteur de poste 30 janvier 10:000
La nouvelle station ne fait pas de liens externes peut être complètement, le premier contenu et la structure de la station pour faire un bon travail plus stable. En s'appuyant uniquement sur le contenu, il est généralement possible d'inclure une partie des mots-clés à longue traîne dans le classement, mais la quantité de concurrence élevée sera lente. Il est recommandé d'attendre l'inclusion stable du site, 30-50 contenu de qualité, les mots clés ont commencé à entrer dans le top 20/30, et puis une petite quantité de liens externes, les mots de marque prioritaires / chaîne nue / type de citation, ne viennent pas à chasser le nombre. 👍