Votre page d'accueil s'affiche en moins de deux secondes, mais une catégorie e-commerce met six secondes à peindre son contenu, ou la liste des articles du blog bloque le scroll. Ce n'est pas une impression : un site lent uniquement sur certaines pages signale presque toujours un problème localisé — requêtes lourdes, cache mal configuré, médias surdimensionnés ou scripts qui ne s'exécutent que sur certains templates.
Chez Apresta, on voit ce schéma régulièrement chez des PME de Lille et de la MEL : la homepage est optimisée (peu de contenu dynamique, hero léger), tandis que les pages « listes » accumulent les requêtes SQL, les vignettes non compressées et les widgets de filtre. La bonne nouvelle : vous n'avez pas à refondre tout le site. Il faut identifier quelles pages, quelles ressources et quelles requêtes créent l'écart.
Pourquoi l'accueil peut être rapide et les catégories lentes
Un site web n'est pas une entité homogène. Chaque template (accueil, catégorie, article, fiche produit) charge un jeu différent de ressources et interroge la base de données différemment.
L'accueil est généralement rapide parce qu'il est statique ou quasi statique, avec peu de requêtes. Les landing pages marketing avec contenu figé suivent la même logique. À l'inverse, les catégories e-commerce avec 48 à 200 produits paginés, les archives blog avec sidebar chargée, les pages de recherche interne ou les filtres facettés (taille, couleur, prix) cumulent volume de données, requêtes HTTP et absence de cache.
La différence de performance vient de trois leviers cumulés : volume de données à récupérer, nombre de requêtes HTTP (images, JS, CSS) et absence de cache sur les templates dynamiques.
Un LCP à 1,8 s sur l'accueil et à 5,2 s sur une catégorie, c'est deux problèmes distincts — pas une « lenteur globale ».
Symptômes : comment reconnaître le problème
Avant d'ouvrir les outils, notez ce que vivent vos utilisateurs et votre équipe. L'accueil et le contact chargent normalement, mais les catégories « freeze » au scroll. Le blog liste 20 articles mais met plus de 4 secondes à afficher la première vignette. PageSpeed Insights est vert sur l'accueil, orange ou rouge sur les archives. Le problème apparaît surtout sur mobile 4G, pas sur fibre bureau.
Après une mise à jour de thème ou de plugin, seules certaines sections ralentissent — signe qu'un composant spécifique aux templates archive est en cause. Si le TTFB (temps de réponse serveur) est élevé uniquement sur les URLs contenant /category/, /blog/ ou /shop/, le problème est probablement côté serveur ou base de données.
Si deux pages au profil similaire (deux catégories du même niveau) ont des temps très différents, suspectez le nombre de produits, la taille des images ou un plugin de filtre actif sur l'une d'elles.
Causes les plus fréquentes sur catégories et blog
Requêtes base de données non optimisées
Les pages « listes » exécutent souvent des requêtes lourdes : tri par popularité, comptage de stock, récupération de toutes les métadonnées produit, jointures sur les taxonomies. Sans index SQL adaptés ou sans cache objet (Redis), chaque visite recalcule tout. Sur une catégorie WooCommerce ou PrestaShop mal optimisée, on voit facilement 80 à 150 requêtes SQL par page.
Cache de page absent ou mal ciblé
Beaucoup de sites mettent en cache l'accueil mais excluent les catégories « par prudence » (panier, stock dynamique). Résultat : chaque hit catégorie repasse par PHP + MySQL. Sur un catalogue de 3 000 références, c'est fatal au TTFB.
Images et médias surdimensionnés
Une grille de 24 produits × une vignette à 800 Ko = près de 20 Mo à télécharger si le lazy loading est mal configuré. Les articles de blog avec photos pleine largeur non compressées reproduisent le même scénario. Le problème n'apparaît pas sur l'accueil parce qu'il y a moins d'images simultanées.
Plugins et widgets spécifiques aux archives
Filtres facettés, « produits vus récemment », carrousels related posts, formulaires newsletter en sidebar : ces blocs s'ajoutent rarement à l'accueil mais s'activent sur les templates archive. Chaque widget peut ajouter 2 à 8 requêtes SQL et 3 à 15 requêtes HTTP. Un seul plugin de filtre mal codé peut expliquer l'écart entre homepage et catégories.
Scripts tiers conditionnels
Un outil de recommandation produit, un chat ou un A/B test peut ne se charger que sur les pages catalogue. Le poids JavaScript explose localement sans impacter l'accueil — d'où l'illusion d'un site « globalement rapide ».
Pagination et profondeur d'archive
La page 1 d'une catégorie peut être cachée ; la page 5, jamais visitée assez souvent pour rester en cache, recalcule à chaque fois. Même logique pour les tags blog peu fréquents.
Diagnostic pas à pas : trouver la page coupable
Commencez par comparer deux profils de pages avec PageSpeed Insights ou WebPageTest : accueil, catégorie e-commerce la plus visitée (Analytics), article de blog moyen, page la plus lente signalée par vos utilisateurs. Notez pour chacune le LCP, le TTFB, le poids total, le nombre de requêtes et l'élément LCP identifié.
Ensuite, isolez le TTFB vs le front-end. Un TTFB > 800 ms pointe vers un problème serveur, cache ou base de données. Un TTFB correct mais un LCP > 4 s oriente vers les images, CSS, JS ou polices.
Ouvrez la waterfall réseau dans Chrome DevTools avec throttling « Slow 4G », rechargez la page lente. Repérez la durée de la requête HTML initiale, les 5 plus gros fichiers et les scripts bloquants avant le LCP.
Activez Query Monitor (WordPress) ou les logs slow query. Sur une catégorie lente, comptez le nombre de requêtes et repérez celles > 50 ms. Au-delà de 100 requêtes SQL par page archive, vous avez un problème structurel.
Enfin, rechargez la même URL catégorie deux fois de suite. Si la seconde visite est 3× plus rapide, le cache fonctionne partiellement — ajustez les règles d'exclusion.
Corrections : prioriser urgent, important, plus tard
Urgent — gains immédiats (1 à 3 jours)
Activez le cache de page sur les catégories et archives blog (avec exclusions panier/compte). Compressez et redimensionnez les vignettes produit (max 30–50 Ko en WebP/AVIF). Activez le lazy load natif sur les images below-the-fold. Désactivez temporairement les widgets sidebar non essentiels pour mesurer l'impact. Vérifiez qu'aucun plugin de filtre ne charge 200 Ko de JS sur mobile.
Important — stabiliser (1 à 3 semaines)
Mettez en place un object cache (Redis) si WooCommerce ou PrestaShop. Optimisez les requêtes lentes identifiées (index, réduction des meta queries). Appliquez du critical CSS sur les templates archive. Servez les assets statiques via CDN — voir CDN, cache et hébergement performances. Auditez les scripts tiers actifs uniquement sur catalogue.
Plus tard — architecture (1 à 3 mois)
Refondre le template catégorie (grille allégée, moins de données par tuile), implémenter une pagination ou un infinite scroll avec prefetch intelligent, ou envisager une séparation headless pour le catalogue si trafic > 50 000 sessions/mois. Mettez en place un monitoring continu des Core Web Vitals par template — voir Core Web Vitals 2026.
Ordres de grandeur budget PME 2026 : quick wins cache + images entre 500 et 2 000 €, optimisation SQL + Redis entre 2 000 et 5 000 €, refonte template performance entre 5 000 et 12 000 €.
Prévention : ne pas recréer le problème
Une fois les pages listes corrigées, verrouillez un budget performance par template, pas seulement sur l'accueil. Fixez un seuil d'alerte : LCP > 2,5 s sur mobile pour toute page > 5 % du trafic. Avant d'installer un plugin, mesurez son impact sur une catégorie test. Automatisez la compression à l'upload et documentez qui purge quoi quand le catalogue change.
Les équipes marketing ajoutent souvent des bannières, des filtres ou des blocs « recommandés » sur les catégories sans mesurer l'impact. Intégrez un contrôle Lighthouse ou PSI dans votre workflow de publication — surtout avant soldes ou campagnes SEA sur pages catégories.
FAQ
Pourquoi mon accueil est rapide mais pas mes catégories ?
L'accueil sert souvent une page mise en cache avec peu de requêtes dynamiques. Les catégories génèrent des listes produits avec requêtes SQL multiples, vignettes lourdes et parfois des filtres JavaScript — d'où un écart de performance normal s'il n'y a pas de cache ni d'optimisation dédiée.
Quel TTFB viser sur une page catégorie e-commerce ?
En France métropolitaine, visez 200 à 600 ms de TTFB sur une catégorie mise en cache. Au-delà de 800 ms sans cache actif, le serveur ou la base de données est le goulot — pas les images.
Le lazy loading suffit-il à accélérer les archives blog ?
Non seul. Il retarde le chargement des images hors écran, mais ne corrige pas un TTFB élevé ni 80 requêtes SQL en sidebar. Combinez lazy loading, cache, images optimisées et allègement des widgets.
Faut-il exclure toutes les catégories du cache ?
Non. Excluez uniquement les pages vraiment personnalisées (panier, checkout, compte, parfois stock temps réel critique). Les catégories et articles blog sont des candidates idéales au cache de page avec TTL de 1 à 24 heures selon la fréquence de mise à jour stock.
Comment savoir quelle catégorie optimiser en premier ?
Tri par trafic organique + trafic payant dans Google Analytics, croisé avec LCP réel dans Search Console ou PageSpeed Insights. Priorisez les pages qui cumulent volume de visites et mauvais LCP — c'est là que le ROI SEO et conversion est maximal.
Et maintenant ?
Un site lent sur certaines pages se corrige page par page, requête par requête — pas avec un plugin miracle sur l'accueil. Commencez par comparer TTFB et LCP entre votre homepage et votre catégorie la plus visitée : en une heure de diagnostic, vous saurez si le problème est serveur, base de données ou front-end.
On accompagne des TPE et PME de Lille et des Hauts-de-France sur ces audits ciblés — souvent sans refonte complète.