WordPress lent sur mobile : quoi optimiser en premier

Playbook diagnostic rapide (trouver le goulot vite)

Si vous ne faites rien d’autre, faites ceci. La lenteur sur mobile est généralement l’une de trois choses : réponse serveur lente (TTFB), charge utile lourde (images/polices/JS/CSS) ou chaos tiers (publicités, traceurs, widgets de chat). L’astuce est de déterminer laquelle en quelques minutes, pas en semaines.

Étape 1 : Décidez si c’est le temps serveur ou le temps navigateur

• Vérifiez le TTFB depuis une requête froide. Si le TTFB est systématiquement élevé (> 600–800ms) sur les réseaux mobiles, corrigez d’abord côté serveur : cache, PHP-FPM, base de données, appels backend, latence d’origine.
• Si le TTFB est correct mais que le LCP est mauvais, vous êtes en territoire front-end : images, CSS bloquant le rendu, JS lourd, polices, décalages de mise en page.
• Si le TTFB est parfois correct et parfois horrible, suspectez des ratés de cache, de la contention backend, des cron, ou un voisin bruyant (saturation CPU/I/O).

Étape 2 : Confirmez que le cache fonctionne vraiment

• Si vous pensez avoir du cache mais que chaque requête atteint PHP, vous n’avez pas de cache. Vous avez de l’espoir.
• Recherchez les en-têtes de cache, le statut du cache en amont et les logs serveur qui montrent des réponses rapides/statiques.

Étape 3 : Trouvez les plus gros octets sur le chemin critique

• Sur mobile, les images et le JS sont les coupables habituels.
• Vérifiez l’élément LCP : si c’est une image principale, corrigez-la avant de discuter des index de base de données.
• Supprimez les scripts tiers qui bloquent le thread principal ou ajoutent de longues tâches. La plupart des scripts « indispensables marketing » sont optionnels une fois que vous montrez leur coût en performance.

Étape 4 : Validez avec une métrique puis passez à la suivante

Choisissez une métrique de réussite par itération : TTFB, LCP, INP (latence d’interaction) ou octets transférés totaux. N’essayez pas de tout réparer en même temps ; vous livreriez un tas de changements et n’apprendriez rien.

Pourquoi la lenteur mobile est différente (et pourquoi vous devez vous en soucier)

Le mobile n’est pas juste un « bureau plus petit ». C’est un moteur physique différent.

• Le CPU est moins puissant, et les navigateurs brident agressivement pour économiser la batterie.
• La latence réseau domine. Même quand le débit semble correct, les allers-retours coûtent cher. Chaque recherche DNS, poignée TLS et redirection fait mal.
• La pression mémoire est réelle. De gros bundles JavaScript et des thèmes lourds peuvent déclencher le GC du navigateur aux pires moments.
• L’entrée est tactile. On peut « s’en sortir » avec un rendu lent sur bureau ; on ne peut pas tolérer des taps qui laguent.

De plus : vous n’optimisez pas pour un labo. Vous optimisez pour l’utilisateur médian désordonné avec 12 onglets ouverts, un signal radio hésitant et un téléphone qui a connu des jours meilleurs.

Une citation à garder sur un post‑it : idée paraphrasée de John Allspaw : « La fiabilité vient de la manière dont les systèmes se comportent en conditions réelles, pas de leur comportement en tests idéaux. »

Blague #1 : Le travail sur la performance ressemble à un régime — personne n’aime compter les calories, mais tout le monde veut les photos pour la plage.

Faits intéressants et contexte historique

Un peu de contexte vous aide à arrêter de répéter les plus grands tubes de l’industrie.

1. WordPress a été lancé en 2003 comme un fork de b2/cafelog, bien avant que « mobile-first » existe. Beaucoup de patterns par défaut sont nés à l’époque du web desktop.
2. HTTP/2 (standardisé en 2015) a réduit la douleur des nombreuses petites requêtes, mais n’a pas rendu le JavaScript démesuré ou les images géantes magiquement bon marché.
3. Google a introduit les Core Web Vitals en 2020 pour quantifier l’expérience utilisateur, poussant la performance de « agréable » à « poste budgétaire ».
4. JPEG existe depuis le début des années 1990 ; les formats modernes comme WebP (2010) et AVIF (vague d’adoption autour de 2019) réduisent significativement les octets pour les photos sur mobile.
5. Le trafic mobile a dépassé le desktop depuis des années pour de nombreux secteurs ; « nous sommes surtout desktop » vient souvent d’une vue analytique dépassée ou d’un biais interne.
6. Les CDN ont commencé comme accélérateurs d’assets statiques mais ont évolué en plateformes edge complètes avec cache, WAF, redimensionnement d’images et gestion de bots — utiles pour WordPress, mais faciles à mal configurer.
7. Le pattern admin-ajax.php de WordPress est devenu un point douloureux de performance à mesure que thèmes/plugins l’utilisaient pour des fonctionnalités « live » ; beaucoup de sites se sont accidentellement auto-DDOS.
8. Le lazy-loading est passé du hack JS au natif avec loading="lazy", mais il peut encore être mal utilisé et retarder le LCP si vous lazy‑chargez l’image héro.
9. PHP 7 (2015) a été un bond en performance ; PHP 8+ ajoute des améliorations et un JIT (surtout non pertinent pour WordPress typique), mais les gains majeurs viennent du cache d’opcode et d’éviter le travail inutile.

Le seul modèle mental dont vous avez besoin : TTFB vs rendu

Les plaintes sur la lenteur mobile se résument généralement à : « J’ai tapé et il m’a regardé. » Ce regard est soit le serveur qui n’envoie pas d’octets (TTFB), soit le navigateur qui suffoque sur ce qu’il a reçu (rendu/CPU).

Groupe A : TTFB élevé (le serveur est le goulot)

Causes typiques :

• Pas de cache de page (ou il est contourné pour mobile / utilisateurs connectés / query strings).
• Exécution PHP lente à cause de plugins lourds, appels distants ou misses d’object-cache.
• Latence base de données (requêtes lentes, index manquants, MySQL surchargé, stockage lent).
• Origine éloignée des utilisateurs et pas de cache CDN.
• Limitation de débit ou challenges WAF qui ajoutent de la latence pour les clients mobiles.

Groupe B : TTFB faible mais peinture lente (le front-end est le goulot)

Causes typiques :

• Image LCP trop grosse, non optimisée, servie sans tailles réactives.
• CSS bloquant le rendu et retards de chargement des polices.
• Bundles JavaScript trop volumineux, trop de scripts tiers, longues tâches.
• Trop de nœuds DOM issus des page builders et des thèmes « tout faire ».

Groupe C : Ça dépend (intermittent)

Si le problème va et vient, supposez une tempête de misses de cache, des tâches cron périodiques, des pics de trafic ou une contention de ressources. Les problèmes intermittents de performance se corrigent rarement par « minifier le JS » et se règlent presque toujours en supprimant la variabilité : cache, capacité et limites.

Tâches pratiques : commandes, sorties, décisions (12+)

Ce sont des tâches de niveau production. Chacune inclut une commande, ce que vous regardez et la décision suivante. Exécutez-les sur votre hôte WordPress ou un clone staging. Si vous ne pouvez pas lancer de commandes (hébergement managé), demandez à votre fournisseur d’exécuter des équivalents — ou migrez vers un endroit où vous pouvez observer votre propre système.

Task 1: Measure TTFB and total time from the origin

cr0x@server:~$ curl -s -o /dev/null -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total} size:%{size_download}\n" https://example.com/
dns:0.012 connect:0.034 tls:0.081 ttfb:0.742 total:1.214 size:185432

Ce que cela signifie : ttfb est le temps jusqu’au premier octet ; total est la durée totale ; size sont les octets retournés.

Décision : Si le TTFB > ~0.6–0.8s de façon constante, arrêtez de discuter des formats d’images et corrigez d’abord le cache serveur et la latence backend.

Task 2: Compare cache hit vs miss using headers

cr0x@server:~$ curl -sI https://example.com/ | egrep -i "cache|age|cf-cache-status|x-cache|x-fastcgi-cache|server|vary"
server: nginx
vary: Accept-Encoding
cache-control: max-age=0, no-cache, no-store, must-revalidate
x-cache: MISS

Ce que cela signifie : Cette réponse n’est pas propice au cache et montre un miss (ou pas de cache).

Décision : Pour les pages publiques, vous voulez généralement des en-têtes cacheables et un statut de cache visible HIT au bord et/ou à l’origine. Si vous n’obtenez pas de HIT, le mobile souffrira en premier.

Task 3: Confirm whether WordPress is generating the page (PHP hit) or serving static HTML

cr0x@server:~$ tail -n 5 /var/log/nginx/access.log
203.0.113.10 - - [27/Dec/2025:10:11:22 +0000] "GET / HTTP/2.0" 200 185432 "-" "Mozilla/5.0" "upstream_response_time=0.690 request_time=1.201"
203.0.113.11 - - [27/Dec/2025:10:11:23 +0000] "GET /wp-content/uploads/2025/12/hero.jpg HTTP/2.0" 200 742193 "-" "Mozilla/5.0" "-"

Ce que cela signifie : La requête de la page d’accueil a un upstream response time (~0.69s) ce qui signifie probablement qu’elle est passée par PHP-FPM. L’image est servie directement (pas d’upstream).

Décision : Si vos pages publiques montrent régulièrement des temps upstream, implémentez un cache de page complet (plugin cache, Nginx fastcgi_cache, Varnish ou cache HTML CDN).

Task 4: Check PHP-FPM saturation (slow requests and queueing)

cr0x@server:~$ sudo ss -lntp | grep php-fpm
LISTEN 0      511          127.0.0.1:9000      0.0.0.0:*    users:(("php-fpm8.2",pid=1123,fd=8))

Ce que cela signifie : PHP-FPM écoute. Ce n’est pas suffisant ; il faut savoir si les workers sont occupés.

Décision : Activez la page de statut PHP-FPM et inspectez active/idle/queue. Si vous voyez une file, vous êtes CPU-bound ou sous-provisionné en workers — le caching et la réduction du code battent « plus de workers » la plupart du temps.

Task 5: Verify PHP opcache is enabled and healthy

cr0x@server:~$ php -i | egrep -i "opcache.enable|opcache.memory_consumption|opcache.interned_strings_buffer|opcache.max_accelerated_files"
opcache.enable => On => On
opcache.memory_consumption => 128 => 128
opcache.interned_strings_buffer => 16 => 16
opcache.max_accelerated_files => 10000 => 10000

Ce que cela signifie : L’opcache d’opcodes est activé, avec des réglages modérés.

Décision : Si opcache est désactivé, activez-le. Si la mémoire est trop petite, vous aurez du churn et perdrez le bénéfice — augmentez-la. C’est de la « performance ennuyeuse », et c’est la meilleure.

Task 6: Identify slow MySQL queries

cr0x@server:~$ sudo tail -n 20 /var/log/mysql/mysql-slow.log
# Query_time: 2.314  Lock_time: 0.000 Rows_sent: 10  Rows_examined: 512340
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts
LEFT JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id)
WHERE wp_posts.post_type = 'product' AND wp_posts.post_status = 'publish'
ORDER BY wp_posts.post_date DESC LIMIT 0, 10;

Ce que cela signifie : Une requête a pris 2.3 secondes et a examiné un demi-million de lignes. Le mobile ressent cela comme « tap… attendre… rien ».

Décision : Supprimez/remplacez le pattern du plugin qui cause cela, ajoutez les bons index (prudemment), et reposez-vous sur le cache de page pour ne pas l’exécuter par visite.

Task 7: See if the database is I/O bound

cr0x@server:~$ iostat -xz 1 5
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.22    0.00    3.10   24.88    0.00   53.80

Device            r/s     w/s   rkB/s   wkB/s  await  aqu-sz  %util
nvme0n1         220.0   180.0  8200.0  5400.0  18.40    3.20  92.00

Ce que cela signifie : L’utilisation du disque est élevée, avec un temps d’attente non négligeable ; l’iowait est élevé. Le stockage est brûlant.

Décision : Si MySQL est sur la même machine et que vous voyez ça, vous avez besoin de moins de lectures (caching), de meilleurs index, d’un stockage plus rapide ou de séparer les rôles. « Ajouter plus de workers PHP » ne résoudra pas un disque saturé.

Task 8: Check CPU and memory pressure during a slow period

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  1      0  31200  84200 612000    0    0   820   610  420  980 25  6 50 19  0
 3  2      0  29800  83500 605000    0    0  1120   900  470 1100 31  7 41 21  0

Ce que cela signifie : La file d’exécution augmente, il y a des processus bloqués, et l’iowait est significatif (wa ~ 20%). Pas d’activité de swap, donc ce n’est pas du swapping.

Décision : Cela indique un goulet I/O ou une base de données. Priorisez le caching et le tuning base de données / stockage plutôt que les changements front-end.

Task 9: Count third-party domains (latency tax on mobile)

cr0x@server:~$ curl -s https://example.com/ | grep -Eo 'https?://[^"]+' | awk -F/ '{print $3}' | sort -u | head
cdn.example.net
fonts.googleapis.com
fonts.gstatic.com
stats.vendor-a.com
tagmanager.vendor-b.com

Ce que cela signifie : Chaque domaine tiers ajoute DNS+TLS+requête et peut bloquer le rendu s’il est mal utilisé.

Décision : Si vous avez plus d’une poignée de tiers sur le chemin critique, commencez à supprimer ou différer. Sur mobile, « mais c’est async » n’est pas une garantie ; le travail sur le thread principal se produit toujours.

Task 10: Find the heaviest images and whether you’re serving modern formats

cr0x@server:~$ find /var/www/html/wp-content/uploads -type f -name "*.jpg" -o -name "*.png" | xargs -r du -h | sort -hr | head
5.8M	/var/www/html/wp-content/uploads/2025/12/hero-homepage.jpg
4.1M	/var/www/html/wp-content/uploads/2025/12/header.png
3.9M	/var/www/html/wp-content/uploads/2025/11/banner-sale.jpg

Ce que cela signifie : Des images de plusieurs mégaoctets sont courantes et brutales sur mobile, surtout si ce sont des éléments LCP.

Décision : Convertissez les images héro en WebP/AVIF (là où supporté), redimensionnez aux dimensions réelles et assurez-vous d’un srcset réactif. Si le thème le désactive, corrigez le thème ou remplacez-le.

Task 11: Confirm gzip/brotli compression for text assets

cr0x@server:~$ curl -sI -H "Accept-Encoding: br,gzip" https://example.com/wp-content/themes/site/style.css | egrep -i "content-encoding|content-length|vary"
content-encoding: br
vary: Accept-Encoding

Ce que cela signifie : Brotli est activé. Bien.

Décision : Si vous ne voyez pas de Content-Encoding, activez gzip/brotli. C’est peu risqué et aide significativement le mobile pour CSS/JS/HTML.

Task 12: Check HTTP cacheability of static assets

cr0x@server:~$ curl -sI https://example.com/wp-content/uploads/2025/12/hero-homepage.jpg | egrep -i "cache-control|expires|etag|last-modified"
cache-control: public, max-age=31536000, immutable
etag: "a1b2c3d4"

Ce que cela signifie : Parfait : cache longue durée. Les assets statiques doivent être fortement mis en cache ; utilisez la version des fichiers pour les mises à jour.

Décision : Si vous voyez no-cache sur images/CSS/JS, corrigez vos règles serveur/CDN. Sinon, chaque visite mobile paie le même coût de téléchargement à nouveau.

Task 13: Locate WordPress cron pressure (surprise background work)

cr0x@server:~$ wp cron event list --due-now --path=/var/www/html
+--------------------------+---------------------+---------------------+------------+
| hook                     | next_run_gmt        | next_run_relative   | recurrence |
+--------------------------+---------------------+---------------------+------------+
| wc_scheduled_sales       | 2025-12-27 10:12:00 | 1 minute ago        | hourly     |
| action_scheduler_run_queue | 2025-12-27 10:10:00 | 3 minutes ago       | every_minute |
+--------------------------+---------------------+---------------------+------------+

Ce que cela signifie : Des événements planifiés sont dus. Si WP-Cron s’exécute sur les requêtes utilisateurs, cela peut provoquer des pics de latence imprévisibles.

Décision : Désactivez le déclenchement de WP-Cron sur les chargements de page et exécutez un vrai cron système lançant wp cron event run --due-now selon un planning.

Task 14: Check PHP error logs for “performance by exception”

cr0x@server:~$ sudo tail -n 20 /var/log/php8.2-fpm.log
[27-Dec-2025 10:11:19] WARNING: [pool www] child 2245, script '/var/www/html/index.php' (request: "GET /") executing too slow (3.214 sec), logging
[27-Dec-2025 10:11:19] NOTICE: [pool www] child 2245 stopped for tracing, pid 2245

Ce que cela signifie : Vous avez des exécutions PHP lentes, pas seulement des réseaux lents. Quelque chose à l’intérieur de WordPress prend des secondes.

Décision : Ajoutez du profiling au niveau application (même temporairement), identifiez la fonction plugin/thème qui consomme du temps et corrigez ou supprimez-la. Ne vous contentez pas d’« augmenter les timeouts ».

Quoi optimiser en premier (ordre, opinion)

C’est la partie que les gens veulent sauter. Très bien. Voici l’ordre qui gagne le plus souvent en production.

1) Avoir un vrai cache de page pour les utilisateurs anonymes

Si votre site sert la même page d’accueil à des milliers de visiteurs anonymes mais la génère avec PHP+MySQL à chaque fois, vous brûlez du CPU et ajoutez de la latence sans raison. Le cache de page (au bord, reverse proxy ou plugin WordPress) est le levier unique le plus puissant pour réduire le TTFB.

• Le cache HTML en edge est optimal quand on peut le faire en sécurité (purge lors des mises à jour, contournement pour pages connectées/panier/checkout).
• Nginx FastCGI cache est excellent si vous contrôlez le serveur.
• Le cache via plugin est mieux que rien, mais les plugins peuvent être fragiles et incohérents sous charge.

Règle : si vos pages publiques n’obtiennent pas de HITs cache, corrigez cela avant de toucher à la minification.

2) Corriger la variabilité du TTFB : cron, contournement de cache et contention backend

Les utilisateurs ne se plaignent pas de la moyenne. Ils se plaignent des pics. Le mobile amplifie les pics parce que le réseau est déjà lent ; ajoutez de la gigue backend et vous obtenez « ça plante ».

• Désactivez WP-Cron sur les chargements de page.
• Réduisez les règles de contournement de cache (query strings, cookies, paramètres UTM).
• Assurez-vous que votre clé de cache est sensée : mobile/desktop devraient généralement partager l’HTML sauf si vous servez vraiment du markup différent.
• Arrêtez de faire des appels API distants dans le chemin de la requête. Mettez-les en cache ou déplacez-les en tâches d’arrière-plan.

3) Optimiser l’élément LCP (généralement une image héro)

Sur mobile, la page « donne l’impression d’être chargée » quand le contenu principal apparaît. C’est le LCP. Si votre LCP est une JPEG de 5 Mo redimensionnée par CSS, vos Core Web Vitals seront catastrophiques.

• Redimensionnez à la taille réellement rendue (plus un peu pour le retina).
• Servez WebP/AVIF avec fallback JPEG.
• Ne pas lazy-loader l’image LCP.
• Préchargez-la si nécessaire, mais seulement la bonne variante (évitez de précharger les assets desktop sur mobile).

4) Supprimez les scripts tiers jusqu’à ce que le site se comporte

C’est là que ça devient politique. Les scripts tiers sont une dette technique de performance que vous payez pour toujours, dans chaque géographie, sur chaque appareil.

• Supprimez ce que vous pouvez. Remplacez ce que vous devez. Auto‑hébergez quand c’est raisonnable.
• Différez les scripts non critiques. Assurez-vous qu’ils ne bloquent pas le rendu.
• Surveillez la « prolifération du tag manager » : un conteneur devient cinq fournisseurs, puis vingt tags, puis tristesse.

5) Réduisez le JavaScript et la complexité du DOM (thèmes/page builders)

Les page builders facilitent le prototypage mais rendent le rendu rapide difficile. Si votre appareil mobile passe des secondes en scripting et layout, vous pouvez compresser les images toute la journée et perdre quand même.

• Désactivez les blocs/widgets/modules non utilisés.
• Arrêtez d’envoyer sliders, animations et mega-menus aux utilisateurs qui veulent juste lire.
• Choisissez un thème qui respecte un budget de performance.

6) Rendre le serveur ennuyeux : PHP moderne, opcache, FPM correct, stockage rapide

Une fois le cache et la charge traités, vous voulez toujours une origine stable :

• PHP 8.1+ avec opcache activé.
• PHP-FPM configuré pour votre CPU/RAM (pas de nombres de processus gigantesques qui thrashent).
• MySQL ajusté pour votre dataset, avec slow query logging activé.
• Stockage SSD/NVMe, pas des disques rotatifs partagés se faisant passer pour du « cloud ».

Blague #2 : Si vous avez « optimisé » en installant cinq plugins de performance, vous n’avez pas optimisé — vous avez créé un petit comité argumentatif.

Trois mini-récits d’entreprise depuis les tranchées performance

1) Incident causé par une mauvaise hypothèse : « Le mobile est mis en cache par défaut »

Une entreprise de taille moyenne avait un site marketing WordPress plus un blog qui alimentait des leads. Le bureau semblait correct, et l’équipe annonçait fièrement avoir activé le cache. Les conversions mobiles, cependant, diminuaient mystérieusement, et les tickets de support décrivaient le site comme « collant » et « aléatoirement lent ».

L’hypothèse erronée était subtile : leurs règles de cache CDN variaient par user-agent, parce que quelqu’un avait ajouté une « optimisation mobile » des années plus tôt qui servait un HTML légèrement différent. Le CDN traitait le mobile comme un bucket de cache séparé mais ne le stockait pas longtemps à cause d’un TTL conservateur. Pire : un plugin marketing posait un cookie pour les utilisateurs anonymes, et le CDN était configuré pour contourner le cache quand n’importe quel cookie existait.

Les utilisateurs desktop arrivaient souvent par des visites directes et avaient un cache réchauffé dans leurs réseaux d’entreprise ; les mobiles arrivaient via des liens sociaux avec paramètres de tracking et déclenchaient plus facilement le contournement de cache. Les serveurs d’origine pouvaient très bien servir le contenu desktop mis en cache. Ils n’étaient pas capables de rendre chaque page mobile dynamiquement lors des pics de campagne.

La solution n’a pas été « ajouter plus de serveurs ». Il s’agissait de normaliser la clé de cache : ignorer les cookies inoffensifs, supprimer/normaliser les query strings de tracking au bord et arrêter de varier l’HTML par user-agent sauf si absolument nécessaire. Ils ont aussi introduit des en-têtes d’état de cache explicites pour que n’importe qui puisse voir HIT/MISS sans deviner.

Résultat : le TTFB est devenu stable. Les rapports de « lenteur aléatoire » ont disparu parce que l’aléa venait d’une politique de cache, pas d’un mystère.

2) Optimisation qui s’est retournée contre eux : « Minifions et combinons tout »

Une autre organisation avait un setup WordPress + WooCommerce. Les pages mobiles étaient lourdes, donc l’équipe a activé une optimisation agressive : combiner CSS, combiner JS, différer tout, inliner le « critical CSS », et une douzaine d’autres toggles qui semblaient productifs.

Pendant une semaine, les chiffres labo s’amélioraient. Puis les plaintes clients ont commencé : des boutons parfois inopérants, la validation du checkout échouant de manière intermittente, et des pages produits présentant des glitches de mise en page uniquement sur certains appareils Android. Le marketing a appelé cela « un problème de marque », ce qui est le corporate pour « on escalade fort ».

Ce qui s’est passé : le plugin d’optimisation a changé l’ordre des scripts et introduit des conditions de course. Les extensions WooCommerce s’attendaient à ce que certaines librairies existent dans un ordre précis ; combiner et différer a brisé ces hypothèses. Pendant ce temps, HTTP/2 faisait que la combinaison d’assets en gros bundles n’était même plus le grand gain d’avant. Ils ont échangé fiabilité contre vitesse théorique.

Le rollback a restauré la fonctionnalité, mais ils n’ont pas abandonné le travail de performance. Ils ont adopté une approche plus ciblée : ne combinez pas à moins d’avoir prouvé que l’overhead des requêtes est le goulot ; retirez plutôt les scripts inutiles, différez seulement les tags non interactifs et gardez le parcours checkout sacré — transformations minimales, prévisibilité maximale.

Leçon : si un tweak de vitesse peut casser le flux de revenus, traitez-le comme un déploiement avec canary, monitoring et plan de rollback. « C’est juste du front-end » est la manière dont on finit en conférence téléphonique d’urgence.

3) Pratique ennuyeuse mais correcte qui a sauvé la situation : observabilité du cache et baselines de capacité

Une entreprise globale gérait plusieurs propriétés WordPress et avait un problème récurrent : chaque grosse campagne causait des « surprises » de performance. L’équipe infra ne voulait pas d’héroïsme ; elle voulait de la prévisibilité.

Ils ont ajouté deux choses ennuyeuses. Premièrement : instrumentation explicite du cache. Chaque réponse portait des en-têtes montrant le statut du cache edge, le statut du cache d’origine et si la requête avait touché PHP. Deuxièmement : des baselines de capacité. Ils ont gardé un tableau de bord simple : CPU origine, I/O disque, profondeur de file PHP-FPM, latence MySQL et ratio HIT CDN.

Pendant la campagne suivante, ils ont vu le ratio HIT baisser pour le trafic mobile seulement. Pas de conjectures — des données. Il s’est avéré qu’un outil d’A/B testing ajouté récemment posait un cookie à la première visite, ce qui contournait le cache edge. Ils ont ajusté le CDN pour ignorer ce cookie sur les pages non personnalisées, et le ratio HIT est revenu en quelques minutes.

Rien de brillant. Pas de nouvelle plateforme. Juste de la visibilité et une baseline rendant le « normal » mesurable. La campagne a réussi, et le postmortem a été heureusement court parce que la réponse était dans les en-têtes.

Erreurs courantes : symptôme → cause racine → correctif

Voici les patterns que je vois de manière récurrente : mêmes symptômes, mêmes mauvaises hypothèses, mêmes corrections qui fonctionnent réellement.

1) Symptôme : Le mobile semble « bloqué » avant qu’autre chose n’apparaisse

Cause racine : TTFB élevé dû à des misses de cache ou au rendu dynamique à chaque requête.

Correctif : Implémentez un cache de page complet pour le trafic anonyme ; vérifiez les HITs via les en-têtes ; normalisez les query strings et cookies qui provoquent un contournement.

2) Symptôme : La première visite est horrible, les visites répétées vont bien

Cause racine : Pas de CDN pour les assets statiques, TTLs courts, ou pas de caching immutable ; le coût réseau mobile domine la première charge.

Correctif : En-têtes de cache longue durée pour les assets statiques, offload vers CDN, activer brotli/gzip, assurer la version des fichiers.

3) Symptôme : LCP est terrible ; tout le reste charge finalement

Cause racine : Image héro trop grosse ou retardée par lazy-load ou CSS/polices bloquants.

Correctif : Optimisez l’image LCP (redimension + format moderne); ne la lazy-loadez pas; préchargez uniquement la variante correcte; réduisez le CSS bloquant le rendu.

4) Symptôme : Taper sur menu/panier/recherche est lent

Cause racine : Thread principal bloqué par du JavaScript lourd et des scripts tiers ; mauvais INP.

Correctif : Supprimez les scripts inutiles, différez les tags non critiques, évitez un DOM géant du page builder, auditez les tiers et supprimez agressivement.

5) Symptôme : Performance ok hors heures de pointe, terrible pendant les campagnes

Cause racine : Saturation d’origine (CPU, BD, disque), queueing PHP-FPM, effondrement du ratio HIT de cache.

Correctif : Rendre le caching résilient, ajouter de la capacité, isoler la base de données, réduire le travail dynamique et monitorer profondeur de file et I/O. Ne « scalez » pas sans réduire le coût par requête.

6) Symptôme : Mobile plus lent que desktop spécifiquement

Cause racine : Variation par user-agent, markup spécifique au mobile, clé de cache différente, ou images plus grandes servies à cause de règles réactives cassées.

Correctif : Unifiez l’HTML entre appareils quand possible ; assurez-vous que le srcset fonctionne ; confirmez que le CDN ne segmente pas inutilement par device.

7) Symptôme : « On a installé un plugin de cache mais rien n’a changé »

Cause racine : Le cache ne sert pas (contournement par cookie, trafic connecté, query strings, conflits de plugin), ou le goulot est le JS tiers et les images, pas la génération HTML.

Correctif : Vérifiez avec en-têtes et logs ; si le cache HTML est HIT mais que le LCP est toujours mauvais, déplacez-vous vers l’optimisation de l’élément LCP et le nettoyage JS/tiers.

8) Symptôme : L’administration est lente ; le front-end est parfois lent

Cause racine : Bloat de base de données, explosion d’options autoloaded, ou plugins coûteux s’exécutant partout.

Correctif : Auditez les plugins, nettoyez les options autoloaded, réduisez les tâches d’arrière-plan, ajoutez un object cache seulement si vous comprenez l’éviction et la mémoire.

Check-lists / plan pas à pas

Voici un plan pragmatique que vous pouvez exécuter sans transformer votre site en projet scientifique.

Phase 1 : Établir une baseline (même jour)

1. Mesurez le TTFB et le temps total depuis votre propre chemin réseau serveur (curl Task 1) et depuis au moins un emplacement externe.
2. Capturez les en-têtes de cache et le statut du cache (Task 2). Faites une capture d’écran. Ne faites pas confiance à la mémoire.
3. Identifiez l’élément LCP sur les templates clés (page d’accueil, catégorie, produit/article). Si c’est une image, notez son fichier et sa taille (Task 10).
4. Listez les domaines tiers présents sur la page (Task 9).
5. Vérifiez la santé des ressources d’origine durant le trafic typique (Tasks 7 et 8).

Phase 2 : Corriger le premier goulot (1–3 jours)

• Si le TTFB est élevé :
  • Implémentez un cache de page complet pour les utilisateurs anonymes (edge ou origine).
  • Normalisez le contournement de cache : ignorez les params marketing ; gérez les cookies avec soin.
  • Déplacez WP-Cron hors des requêtes (Task 13).
  • Activez opcache et confirmez son fonctionnement (Task 5).
• Si le LCP est élevé mais le TTFB ok :
  • Redimensionnez et ré-encodez l’image LCP ; assurez-vous qu’elle n’est pas lazy-loaded.
  • Assurez-vous que les assets statiques ont des durées de cache longues (Task 12).
  • Activez brotli/gzip (Task 11).
• Si l’interaction est lente :
  • Supprimez ou différez les scripts tiers.
  • Enlevez les modules de thème et widgets page builder inutilisés.
  • Évitez les toggles « combinez tout » sauf si c’est prouvé sans risque sur les flux de revenus.

Phase 3 : Stabiliser et prévenir les régressions (continu)

1. Ajoutez de l’observabilité du cache : retournez des en-têtes d’état de cache ; loggez le temps de réponse en amont ; suivez le ratio HIT.
2. Laissez le slow query logging activé, avec rotation.
3. Adoptez un budget de performance : taille max image LCP, nombre max de domaines tiers, taille JS max pour les templates mobiles.
4. Testez les parcours checkout et login à chaque changement de performance (canary et rollback).

FAQ

1) Pourquoi mon site WordPress est lent uniquement sur mobile, pas sur desktop ?

Le desktop masque les problèmes avec plus de CPU et souvent une latence plus faible. Le mobile amplifie la latence et le travail sur le thread principal. Si le TTFB est élevé, les réseaux mobiles aggravent la sensation ; si le JS est lourd, les CPU mobiles l’accentuent.

2) Que dois-je vérifier en premier : images ou hébergement ?

Vérifiez le TTFB d’abord. Si le TTFB est systématiquement élevé, c’est côté serveur/cache/BD/edge. Si le TTFB est correct, corrigez les images LCP et le JS. N’achetez pas un serveur plus gros pour résoudre une image héros de 5 Mo.

3) Ai‑je besoin d’un CDN pour la performance mobile ?

Si votre audience est géographiquement distribuée ou si votre origine est lente, oui. Même localement, un CDN aide en mettant en cache les assets statiques et parfois l’HTML. Mais un CDN ne réparera pas des pages non cacheables ou des règles de cache brisées.

4) Un plugin de cache suffit‑il ?

Parfois. Mais les plugins peuvent être contournés par les cookies, les query strings, les états connectés et le comportement de WooCommerce. Si possible, préférez le cache au bord ou le reverse proxy où vous pouvez prouver HIT/MISS et contrôler explicitement les règles de contournement.

5) Dois‑je combiner les fichiers CSS/JS pour réduire les requêtes ?

Pas par défaut. Avec HTTP/2/HTTP/3, réduire le nombre de requêtes est moins critique que réduire la charge utile et l’exécution JS. Combiner peut se retourner contre vous en cassant l’ordre des scripts et en rendant le cache moins efficace.

6) Mes Core Web Vitals montrent un INP mauvais sur mobile. Quelle est la première action ?

Réduisez le travail du thread principal : supprimez les scripts tiers, réduisez le JS des thèmes/page builders et évitez les widgets UI lourds. Ensuite, cherchez les longues tâches dans les outils de performance, mais supprimer d’abord l’inutile gagne souvent.

7) WooCommerce est lent sur mobile — qu’est‑ce qui diffère ?

Les pages WooCommerce ne peuvent souvent pas être mises en cache de la même façon qu’un blog à cause des paniers, sessions et personnalisations. Vous devez être strict sur ce qui est cacheable (les pages produit le sont souvent) et garder le checkout/panier stable et légèrement optimisé plutôt que transformé agressivement.

8) L’indexation de la base de données peut‑elle seule résoudre la lenteur mobile ?

Elle peut corriger un TTFB élevé lorsque des requêtes lentes dominent et que le cache n’est pas viable (ou absent). Mais la plupart des pages publiques WordPress ne devraient pas exécuter de requêtes lourdes par vue. Utilisez le cache pour éviter d’avoir besoin d’index héroïques pour le trafic anonyme.

9) Pourquoi mes résultats de performance varient tant entre les tests ?

La chaleur du cache, la variabilité réseau et les tâches d’arrière-plan (cron, purges de cache, déploiements) causent des fluctuations. Un TTFB intermittent pointe souvent vers des misses de cache, du queueing PHP-FPM ou une contention I/O base de données.

Prochaines étapes pratiques

Faites ces étapes dans l’ordre, et arrêtez-vous quand la métrique bouge. La performance est une file de goulots, pas un seul dragon.

1. Mesurez le TTFB avec curl et décidez : backend d’abord ou front-end d’abord.
2. Prouvez que le cache fonctionne avec en-têtes et logs ; corrigez les règles de contournement qui tuent le mobile.
3. Optimisez l’élément LCP (presque toujours une image) et assurez-vous qu’il n’est pas lazy-loaded.
4. Supprimez les scripts tiers jusqu’à ce que le site se comporte sur un téléphone milieu de gamme.
5. Stabilisez l’origine : opcache activé, WP-Cron hors des requêtes, slow query log activé, surveillez I/O et profondeur de file.
6. Verrouillez les garde‑fous : budget de performance, monitoring et plan de rollback pour les « optimisations ».

Si vous voulez un mantra : optimisez d’abord ce que les utilisateurs ressentent. Sur mobile, c’est généralement la cacheabilité et l’élément LCP. Tout le reste est du travail de détail — précieux, mais seulement après avoir arrêté l’hémorragie.