{"id":22434,"date":"2026-08-28T08:19:00","date_gmt":"2026-08-28T06:19:00","guid":{"rendered":"https:\/\/www.curiaweb.ch\/?post_type=docs&p=22434"},"modified":"2026-08-28T08:19:00","modified_gmt":"2026-08-28T06:19:00","password":"","slug":"ameliorer-le-temps-de-chargement-lent-de-wordpress","status":"publish","type":"docs","link":"https:\/\/www.curiaweb.ch\/fr\/hilfe\/wordpress\/wordpress-langsam-ladezeit-verbessern\/","title":{"rendered":"WordPress est lent : trouver les causes et am\u00e9liorer le temps de chargement"},"content":{"rendered":"

Un site WordPress lent peut avoir de nombreuses causes. De grandes images, trop de plugins ou des plugins mal programm\u00e9s, des requ\u00eates de base de donn\u00e9es lentes, des services externes, un manque de mise en cache, WP-Cron, des processus PHP ou des ressources d'h\u00e9bergement surcharg\u00e9es peuvent influencer le temps de chargement individuellement ou collectivement.<\/p>\n\n\n\n

C'est pourquoi il n'existe pas de solution universelle s\u00e9rieuse du type \u201e Installez ce seul plugin de performance et WordPress sera rapide \u201c. Avant d'optimiser, vous devez d\u00e9couvrir, quelle partie du site Web est r\u00e9ellement lente<\/strong>.<\/p>\n\n\n\n

Une bonne analyse des performances distingue par exemple une r\u00e9ponse lente du serveur, un traitement WordPress complexe et un frontal qui est ralenti dans le navigateur par des images, du JavaScript, du CSS, des polices web ou des services externes.<\/p>\n\n\n\n

\n

En bref :<\/strong> Mesure d'abord, avant d'optimiser. Si la premi\u00e8re r\u00e9ponse du serveur est d\u00e9j\u00e0 lente, tu dois examiner PHP, la base de donn\u00e9es, les extensions, les processus WordPress et les ressources d'h\u00e9bergement. Si la page HTML arrive rapidement, mais que le navigateur met ensuite du temps \u00e0 l'afficher, les causes se situent plut\u00f4t du c\u00f4t\u00e9 des images, du CSS, du JavaScript, des polices ou des ressources externes.<\/p>\n<\/blockquote>\n\n\n\n

Que signifie r\u00e9ellement \u201e WordPress est lent \u201c ?<\/h2>\n\n\n\n

Cette d\u00e9claration peut d\u00e9crire des probl\u00e8mes tr\u00e8s diff\u00e9rents.<\/p>\n\n\n\n

Il se peut que le site public mette plusieurs secondes avant qu'il ne se passe quoi que ce soit. Il se peut que la page s'affiche rapidement, mais que les images et autres \u00e9l\u00e9ments mettent du temps \u00e0 charger. Dans d'autres cas, seul l'espace d'administration WordPress est lent ou seul le module de paiement WooCommerce r\u00e9agit avec du retard.<\/p>\n\n\n\n

Ces situations n'ont pas n\u00e9cessairement la m\u00eame cause.<\/p>\n\n\n\n

C'est pourquoi une optimisation des performances devrait toujours commencer par une description aussi pr\u00e9cise que possible du probl\u00e8me.<\/p>\n\n\n\n

Consid\u00e9rer le Front-end et l'espace d'administration WordPress s\u00e9par\u00e9ment<\/h2>\n\n\n\n

Un site web peut \u00eatre rapide sur le front-end tout en ayant une zone d'administration lente.<\/p>\n\n\n\n

C'est tout \u00e0 fait possible d'un point de vue technique. Les pages publiques peuvent par exemple \u00eatre servies \u00e0 partir d'un cache de pages, tandis que les requ\u00eates au sein de :<\/p>\n\n\n\n

\/wp-admin\/<\/code><\/p>\n\n\n\n

doivent \u00eatre trait\u00e9s dynamiquement par WordPress et PHP.<\/p>\n\n\n\n

Si seule la zone d'administration est lente, vous ne devez par cons\u00e9quent pas automatiquement optimiser les images de la page d'accueil. Inversement, une image principale lente n'explique pas n\u00e9cessairement un \u00e9diteur WordPress poussif.<\/p>\n\n\n\n

Le temps de chargement se compose de plusieurs sections.<\/h2>\n\n\n\n

Lors du chargement d'une page WordPress, plusieurs choses se produisent, pour faire simple.<\/p>\n\n\n\n

Le navigateur doit atteindre le domaine et \u00e9tablir une connexion. Le serveur web traite la requ\u00eate. Si la page ne peut pas d\u00e9j\u00e0 \u00eatre fournie par un cache, PHP lance l'application WordPress. WordPress charge entre autres les extensions et le th\u00e8me, ex\u00e9cute des requ\u00eates de base de donn\u00e9es et g\u00e9n\u00e8re le document HTML.<\/p>\n\n\n\n

Ce n'est qu'ensuite qu'une autre partie importante commence dans le navigateur : le HTML est trait\u00e9 et les ressources suppl\u00e9mentaires telles que les feuilles de style, le JavaScript, les images et les polices sont charg\u00e9es.<\/p>\n\n\n\n

Une indication globale telle que \u201e la page se charge en quatre secondes \u201c ne dit donc pas encore \u00e0 quel endroit ce temps est perdu.<\/p>\n\n\n\n

Qu'est-ce que le TTFB ?<\/h2>\n\n\n\n

TTFB signifie Temps jusqu'au premier octet<\/strong>. En termes simplifi\u00e9s, cette mesure indique le temps n\u00e9cessaire pour que le premier octet de la r\u00e9ponse du serveur arrive chez le client apr\u00e8s une requ\u00eate.<\/p>\n\n\n\n

Un TTFB \u00e9lev\u00e9 peut \u00eatre le signe de probl\u00e8mes c\u00f4t\u00e9 serveur. Cependant, il ne prouve pas automatiquement que le serveur d'h\u00e9bergement est trop lent.<\/p>\n\n\n\n

Plusieurs facteurs peuvent influencer le temps mesur\u00e9, notamment le r\u00e9seau, l'\u00e9tablissement de la connexion, le traitement par le serveur et, dans le cas d'un site WordPress dynamique, le traitement n\u00e9cessaire par PHP et la base de donn\u00e9es.<\/p>\n\n\n\n

\n

Important :<\/strong> Un TTFB \u00e9lev\u00e9 et un rendu visuel lent ne sont pas la m\u00eame chose. Un site WordPress peut r\u00e9pondre rapidement c\u00f4t\u00e9 serveur et sembler n\u00e9anmoins lent par la suite en raison de ressources front-end volumineuses.<\/p>\n<\/blockquote>\n\n\n\n

Le cache de pages transforme fondamentalement les performances de WordPress<\/h2>\n\n\n\n

Sans cache de page, WordPress doit g\u00e9n\u00e9ralement ex\u00e9cuter PHP pour un affichage de page normal, charger WordPress, prendre en compte les plugins et le th\u00e8me, effectuer des requ\u00eates dans la base de donn\u00e9es et g\u00e9n\u00e9rer du HTML \u00e0 partir de cela.<\/p>\n\n\n\n

Un cache de pages peut stocker du HTML d\u00e9j\u00e0 g\u00e9n\u00e9r\u00e9 et le servir \u00e0 nouveau lors de requ\u00eates appropri\u00e9es.<\/p>\n\n\n\n

Cela \u00e9vite \u00e0 WordPress de devoir r\u00e9p\u00e9ter l'int\u00e9gralit\u00e9 du processus dynamique \u00e0 chaque affichage de page anonyme.<\/p>\n\n\n\n

Cela peut faire une diff\u00e9rence de performance consid\u00e9rable, en particulier sur les pages de contenu normales.<\/p>\n\n\n\n

Toutes les pages ne doivent pas \u00eatre mises en cache de la m\u00eame mani\u00e8re<\/h2>\n\n\n\n

Sur les sites web dynamiques, la mise en cache doit \u00eatre utilis\u00e9e de mani\u00e8re cibl\u00e9e.<\/p>\n\n\n\n

Un panier d'achat WooCommerce, une page de validation de commande ou un espace membre personnalis\u00e9 ne peuvent par exemple pas \u00eatre trait\u00e9s simplement comme un article de blog public.<\/p>\n\n\n\n

M\u00eame les utilisateurs connect\u00e9s ont besoin de contenus individuels selon l'application.<\/p>\n\n\n\n

Une mauvaise configuration du cache peut donc \u00eatre rapide, mais causer simultan\u00e9ment des erreurs fonctionnelles ou des contenus incorrects.<\/p>\n\n\n\n

Le cache n'est pas une r\u00e9paration pour du code lent<\/h2>\n\n\n\n

La mise en cache des pages peut acc\u00e9l\u00e9rer consid\u00e9rablement de nombreuses pages publiques. Elle ne doit cependant pas \u00eatre utilis\u00e9e pour masquer compl\u00e8tement des probl\u00e8mes fondamentaux.<\/p>\n\n\n\n

Lorsqu'une requ\u00eate WordPress non mise en cache prend \u00e9norm\u00e9ment de temps, cela peut \u00eatre d\u00fb, par exemple, \u00e0 des extensions inefficaces, \u00e0 des probl\u00e8mes de base de donn\u00e9es ou \u00e0 des appels d'API externes.<\/p>\n\n\n\n

Ces causes peuvent \u00e9galement se produire dans la zone d'administration, pour les utilisateurs connect\u00e9s, lors du paiement ou pour les requ\u00eates non mises en cache.<\/p>\n\n\n\n

\n

Conseil pratique :<\/strong> Lors d'une analyse de performance, v\u00e9rifiez si possible \u00e0 la fois un chargement de page normal en cache et les zones trait\u00e9es dynamiquement. Une page d'accueil rapide ne prouve pas que l'ensemble de l'application WordPress est rapide.<\/p>\n<\/blockquote>\n\n\n\n

Les extensions peuvent ralentir consid\u00e9rablement WordPress<\/h2>\n\n\n\n

Le nombre pur de plugins install\u00e9s n'est pas un indicateur de performance fiable.<\/p>\n\n\n\n

Un site web dot\u00e9 de 30 extensions l\u00e9g\u00e8res peut fonctionner plus rapidement qu'un site web dot\u00e9 de cinq extensions tr\u00e8s complexes.<\/p>\n\n\n\n

Ce qui est d\u00e9cisif, c'est, ce qu'un plugin fait r\u00e9ellement lors d'une requ\u00eate<\/strong>.<\/p>\n\n\n\n

Par exemple, un plugin peut g\u00e9n\u00e9rer de nombreuses requ\u00eates de base de donn\u00e9es, contacter des services externes, charger de grandes quantit\u00e9s de JavaScript ou effectuer des op\u00e9rations gourmandes en calcul \u00e0 chaque chargement de page.<\/p>\n\n\n\n

\u201e Trop de plugins \u201c est un diagnostic trop impr\u00e9cis<\/h2>\n\n\n\n

La recommandation de se contenter de supprimer le plus de plugins possible est donc insuffisante.<\/p>\n\n\n\n

Si WordPress est lent, vous devez identifier les extensions qui posent r\u00e9ellement probl\u00e8me.<\/p>\n\n\n\n

Les extensions dont les performances ont nettement chang\u00e9 apr\u00e8s leur installation ou leur mise \u00e0 jour sont particuli\u00e8rement int\u00e9ressantes.<\/p>\n\n\n\n

Vous devriez \u00e9galement v\u00e9rifier les extensions qui se chevauchent sur le plan fonctionnel. Plusieurs plugins pour la m\u00eame t\u00e2che peuvent non seulement g\u00e9n\u00e9rer une complexit\u00e9 inutile, mais aussi s'influencer mutuellement.<\/p>\n\n\n\n

Nous vous expliquons comment tester de mani\u00e8re contr\u00f4l\u00e9e des extensions les unes contre les autres sous D\u00e9tecter et r\u00e9soudre les conflits de plugins ou de th\u00e8mes dans WordPress<\/a>.<\/p>\n\n\n\n

Le th\u00e8me influence \u00e9galement le temps de chargement<\/h2>\n\n\n\n

Le th\u00e8me actif d\u00e9termine une partie essentielle de l'affichage du frontend. Il peut charger des feuilles de style, du JavaScript, des polices, des images et des fonctionnalit\u00e9s suppl\u00e9mentaires.<\/p>\n\n\n\n

Un th\u00e8me tr\u00e8s volumineux peut par cons\u00e9quent n\u00e9cessiter plus de ressources qu'un th\u00e8me l\u00e9ger.<\/p>\n\n\n\n

Cependant, cela ne signifie pas qu'un th\u00e8me minimaliste rend automatiquement chaque site WordPress rapide. Les page builders, les extensions, les images et les fonctionnalit\u00e9s personnalis\u00e9es peuvent toujours repr\u00e9senter la majeure partie de la charge.<\/p>\n\n\n\n

Le th\u00e8me et le reste du site web doivent donc \u00eatre examin\u00e9s ensemble.<\/p>\n\n\n\n

\u00c9valuer les Page Builders de mani\u00e8re nuanc\u00e9e<\/h2>\n\n\n\n

Les constructeurs de pages permettent des mises en page complexes, mais ils peuvent g\u00e9n\u00e9rer du HTML, du CSS et du JavaScript suppl\u00e9mentaires.<\/p>\n\n\n\n

Que cela pose probl\u00e8me en pratique d\u00e9pend fortement de la mani\u00e8re dont le site web a \u00e9t\u00e9 con\u00e7u.<\/p>\n\n\n\n

De nombreux conteneurs imbriqu\u00e9s, animations, curseurs, vid\u00e9os, grandes images d'arri\u00e8re-plan et de nombreux widgets peuvent rendre une page nettement plus lourde.<\/p>\n\n\n\n

Au lieu de rejeter la faute globalement sur le Page Builder, tu devrais analyser quelles ressources et quels \u00e9l\u00e9ments sont r\u00e9ellement charg\u00e9s sur la page en question.<\/p>\n\n\n\n

Les images comptent parmi les freins les plus fr\u00e9quents du frontend<\/h2>\n\n\n\n

Une photo haute r\u00e9solution provenant directement d'un appareil photo ou d'un smartphone peut peser plusieurs m\u00e9gaoctets. Si une telle image est utilis\u00e9e telle quelle sur un site web, le visiteur doit transf\u00e9rer ces donn\u00e9es, bien que l'image ne soit peut-\u00eatre affich\u00e9e qu'avec une largeur de quelques centaines de pixels.<\/p>\n\n\n\n

C'est pourquoi les images doivent \u00eatre correctement dimensionn\u00e9es et compress\u00e9es de mani\u00e8re judicieuse.<\/p>\n\n\n\n

Les formats d'image modernes peuvent r\u00e9duire davantage la quantit\u00e9 de donn\u00e9es transf\u00e9r\u00e9es, \u00e0 condition qu'ils correspondent au site Web respectif et \u00e0 la prise en charge du navigateur.<\/p>\n\n\n\n

Les dimensions de l'image et la taille du fichier ne sont pas la m\u00eame chose<\/h2>\n\n\n\n

Une image peut par exemple avoir des dimensions de :<\/p>\n\n\n\n

5000 \u00d7 3333 pixels<\/code><\/p>\n\n\n\n

poss\u00e9der, bien que sur le site Web ce soit seulement avec :<\/p>\n\n\n\n

800 \u00d7 533 pixels<\/code><\/p>\n\n\n\n

s'affiche.<\/p>\n\n\n\n

La simple r\u00e9duction visuelle par CSS ne r\u00e9duit pas automatiquement le fichier image d'origine qui doit \u00eatre transf\u00e9r\u00e9.<\/p>\n\n\n\n

C'est pourquoi les dimensions des images doivent d\u00e9j\u00e0 correspondre \u00e0 leur utilisation r\u00e9elle.<\/p>\n\n\n\n

Utiliser le chargement diff\u00e9r\u00e9 \u00e0 bon escient<\/h2>\n\n\n\n

Les images et autres ressources situ\u00e9es bien en dessous de la zone initialement visible ne doivent pas toujours \u00eatre charg\u00e9es imm\u00e9diatement.<\/p>\n\n\n\n

Le chargement diff\u00e9r\u00e9 (Lazy Loading) permet de charger ces ressources au moment o\u00f9 elles sont n\u00e9cessaires.<\/p>\n\n\n\n

Cela r\u00e9duit le volume de donn\u00e9es initial.<\/p>\n\n\n\n

Cependant, une image importante situ\u00e9e dans la zone directement visible ne doit pas \u00eatre artificiellement retard\u00e9e sans r\u00e9flexion. L'optimisation des performances ne signifie pas qu'il faille syst\u00e9matiquement charger chaque ressource le plus tard possible.<\/p>\n\n\n\n

JavaScript peut ralentir l'affichage<\/h2>\n\n\n\n

Les sites Web WordPress modernes utilisent souvent JavaScript pour la navigation, les diaporamas, les formulaires, le suivi, les syst\u00e8mes de consentement, les constructeurs de pages et bien d'autres fonctionnalit\u00e9s.<\/p>\n\n\n\n

Un JavaScript trop important ou mal charg\u00e9 peut retarder le traitement dans le navigateur.<\/p>\n\n\n\n

En particulier sur les appareils mobiles plus lents, ce n'est pas seulement la taille des fichiers qui importe. Le JavaScript doit \u00eatre t\u00e9l\u00e9charg\u00e9, analys\u00e9 et ex\u00e9cut\u00e9.<\/p>\n\n\n\n

C'est pourquoi un fichier plus petit peut tout de m\u00eame co\u00fbter cher s'il g\u00e9n\u00e8re beaucoup de travail de calcul.<\/p>\n\n\n\n

Retarder le JavaScript \u2013 mais de mani\u00e8re contr\u00f4l\u00e9e<\/h2>\n\n\n\n

Les extensions de performance proposent souvent des fonctionnalit\u00e9s telles que le chargement diff\u00e9r\u00e9 ou diff\u00e9r\u00e9 du JavaScript.<\/p>\n\n\n\n

Cela peut am\u00e9liorer l'affichage initial, mais ne doit pas \u00eatre activ\u00e9 aveugl\u00e9ment.<\/p>\n\n\n\n

Si les scripts d\u00e9pendants sont charg\u00e9s dans le mauvais ordre, des menus, des formulaires, des curseurs ou d'autres \u00e9l\u00e9ments interactifs peuvent par exemple tomber en panne.<\/p>\n\n\n\n

Apr\u00e8s de telles optimisations, vous devriez donc toujours tester les fonctionnalit\u00e9s principales du site Web.<\/p>\n\n\n\n

Le CSS peut \u00e9galement devenir un goulot d'\u00e9tranglement<\/h2>\n\n\n\n

Les grandes feuilles de style ou les nombreux fichiers CSS diff\u00e9rents augmentent la charge de travail du navigateur.<\/p>\n\n\n\n

Le CSS n\u00e9cessaire au rendu initial, mais disponible tardivement, peut s'av\u00e9rer particuli\u00e8rement probl\u00e9matique.<\/p>\n\n\n\n

Cependant, m\u00eame ici, le nombre de fichiers le plus faible possible n'est pas automatiquement le seul objectif. Les protocoles de transfert modernes et les m\u00e9canismes de cache modifient l'\u00e9valuation par rapport aux anciennes r\u00e8gles d'optimisation.<\/p>\n\n\n\n

Ce qui est d\u00e9terminant, c'est le comportement de chargement r\u00e9el du site Web.<\/p>\n\n\n\n

Les polices Web co\u00fbtent des requ\u00eates suppl\u00e9mentaires<\/h2>\n\n\n\n

Les polices Web personnalis\u00e9es peuvent am\u00e9liorer le design, mais elles g\u00e9n\u00e8rent des ressources suppl\u00e9mentaires.<\/p>\n\n\n\n

Un nombre particuli\u00e8rement \u00e9lev\u00e9 de familles de polices, de graisses de polices et de services de polices externes peut augmenter le temps de chargement.<\/p>\n\n\n\n

V\u00e9rifiez par cons\u00e9quent quelles variantes de police sont r\u00e9ellement utilis\u00e9es.<\/p>\n\n\n\n

Si des services de polices externes sont utilis\u00e9s, il faut tenir compte non seulement des performances, mais aussi des exigences en mati\u00e8re de protection des donn\u00e9es.<\/p>\n\n\n\n

Les services externes peuvent ralentir un site web rapide<\/h2>\n\n\n\n

Toutes les ressources d'un site WordPress ne sont pas charg\u00e9es depuis son propre serveur.<\/p>\n\n\n\n

Les composants externes typiques sont, par exemple, les services d'analyse et de suivi, les cartes, les vid\u00e9os, les widgets de r\u00e9seaux sociaux, les r\u00e9seaux publicitaires, les syst\u00e8mes de chat ou les polices externes.<\/p>\n\n\n\n

Les performances de ces services \u00e9chappent en partie au contr\u00f4le du propre serveur WordPress.<\/p>\n\n\n\n

Si une page r\u00e9pond rapidement c\u00f4t\u00e9 serveur mais met du temps \u00e0 se charger dans le navigateur, vous devriez par cons\u00e9quent \u00e9galement analyser les requ\u00eates tierces.<\/p>\n\n\n\n

Ne pas sous-estimer les vid\u00e9os int\u00e9gr\u00e9es<\/h2>\n\n\n\n

Une vid\u00e9o int\u00e9gr\u00e9e peut charger des fichiers JavaScript suppl\u00e9mentaires, des images de aper\u00e7u, des connexions et d'autres ressources d'un fournisseur tiers.<\/p>\n\n\n\n

Cet effet peut se multiplier avec plusieurs vid\u00e9os.<\/p>\n\n\n\n

Selon le site web, il peut \u00eatre judicieux de ne charger compl\u00e8tement les m\u00e9dias externes qu'apr\u00e8s une interaction de l'utilisateur.<\/p>\n\n\n\n

La base de donn\u00e9es WordPress comme facteur de performance<\/h2>\n\n\n\n

WordPress stocke les contenus, les param\u00e8tres et de nombreuses donn\u00e9es de plugins dans une base de donn\u00e9es relationnelle.<\/p>\n\n\n\n

Lors d'un chargement de page, WordPress, le th\u00e8me et les plugins ex\u00e9cutent des requ\u00eates sur cette base de donn\u00e9es.<\/p>\n\n\n\n

La seule taille de la base de donn\u00e9es n'est pas automatiquement d\u00e9cisive. Une grande base de donn\u00e9es judicieusement structur\u00e9e peut fonctionner sans probl\u00e8me, tandis qu'une base de donn\u00e9es plus petite peut poser des probl\u00e8mes de performance en raison de requ\u00eates inefficaces.<\/p>\n\n\n\n

Identifier les requ\u00eates de base de donn\u00e9es lentes<\/h2>\n\n\n\n

Lorsqu'une requ\u00eate WordPress dynamique est lente, des requ\u00eates de base de donn\u00e9es individuelles peuvent y contribuer de mani\u00e8re significative.<\/p>\n\n\n\n

Les extensions, en particulier celles dot\u00e9es de fonctions complexes de recherche, de filtrage, de statistiques ou de rapports, peuvent g\u00e9n\u00e9rer des requ\u00eates exigeantes.<\/p>\n\n\n\n

Une analyse professionnelle ne devrait donc pas seulement se demander quelle est la taille de la base de donn\u00e9es, mais quelles requ\u00eates prennent r\u00e9ellement du temps et \u00e0 quelle fr\u00e9quence elles sont ex\u00e9cut\u00e9es.<\/p>\n\n\n\n

wp_options et le chargement automatique<\/h2>\n\n\n\n

La table des options WordPress contient les donn\u00e9es de configuration de WordPress et des extensions. Certaines options sont charg\u00e9es automatiquement lors de nombreuses requ\u00eates WordPress.<\/p>\n\n\n\n

Si des plugins y laissent des donn\u00e9es de chargement automatique tr\u00e8s volumineuses ou inutiles, cela peut nuire aux performances.<\/p>\n\n\n\n

Cependant, de telles entr\u00e9es ne devraient pas \u00eatre supprim\u00e9es de mani\u00e8re al\u00e9atoire de la base de donn\u00e9es sur la base de leur nom.<\/p>\n\n\n\n

\n

Attention :<\/strong> Les \u201e nettoyages \u201c de base de donn\u00e9es peuvent supprimer d\u00e9finitivement des param\u00e8tres ou des donn\u00e9es de plugins. Cr\u00e9ez une sauvegarde avant toute intervention manuelle et ne supprimez que les donn\u00e9es dont la fonction et l'origine ont \u00e9t\u00e9 clairement identifi\u00e9es.<\/p>\n<\/blockquote>\n\n\n\n

Transitoires et donn\u00e9es temporaires<\/h2>\n\n\n\n

WordPress et ses extensions peuvent utiliser des \"transients\" pour stocker temporairement des donn\u00e9es en cache.<\/p>\n\n\n\n

Les transients ne constituent fondamentalement pas une erreur et font partie du m\u00e9canisme normal de WordPress.<\/p>\n\n\n\n

Les impl\u00e9mentations erron\u00e9es ou les quantit\u00e9s inhabituellement grandes de donn\u00e9es temporaires peuvent s'av\u00e9rer probl\u00e9matiques.<\/p>\n\n\n\n

Cependant, la suppression globale de tous les transients n'est pas une strat\u00e9gie de performance durable. S'ils r\u00e9apparaissent imm\u00e9diatement en quantit\u00e9 probl\u00e9matique, la cause doit \u00eatre \u00e9tudi\u00e9e.<\/p>\n\n\n\n

Les r\u00e9visions ne sont pas automatiquement le probl\u00e8me<\/h2>\n\n\n\n

WordPress peut enregistrer les versions ant\u00e9rieures des articles et des pages sous forme de r\u00e9visions.<\/p>\n\n\n\n

Sur les sites web exploit\u00e9s de longue date, cela peut g\u00e9n\u00e9rer un grand nombre d'enregistrements.<\/p>\n\n\n\n

Cela ne signifie pas pour autant que quelques centaines ou milliers de r\u00e9visions sont automatiquement la cause de la lenteur d'un site web.<\/p>\n\n\n\n

Une base de donn\u00e9es doit \u00eatre optimis\u00e9e sur la base de mesures r\u00e9elles et non sur des hypoth\u00e8ses g\u00e9n\u00e9rales.<\/p>\n\n\n\n

Diff\u00e9rencier le cache d'objets et le cache de pages<\/h2>\n\n\n\n

Le cache de pages et le cache d'objets r\u00e9solvent des t\u00e2ches diff\u00e9rentes.<\/p>\n\n\n\n

Un cache de page stocke, pour faire simple, des affichages de pages d\u00e9j\u00e0 g\u00e9n\u00e9r\u00e9s. En revanche, un cache d'objets persistant permet de stocker temporairement des r\u00e9sultats et des donn\u00e9es dont WordPress a besoin lors de son traitement, au-del\u00e0 de requ\u00eates individuelles.<\/p>\n\n\n\n

Des technologies telles que Redis peuvent \u00eatre utilis\u00e9es comme backend pour un cache d'objets persistant.<\/p>\n\n\n\n

Cela peut s'av\u00e9rer particuli\u00e8rement utile pour les applications WordPress dynamiques avec des acc\u00e8s r\u00e9p\u00e9t\u00e9s \u00e0 la base de donn\u00e9es.<\/p>\n\n\n\n

Cependant, un cache d'objets ne remplace pas un cache de page et ne supprime pas non plus un code mal programm\u00e9.<\/p>\n\n\n\n

WooCommerce a des exigences diff\u00e9rentes de celles d'un blog<\/h2>\n\n\n\n

Un blog simple se compose principalement de contenus accessibles publiquement. De nombreuses pages peuvent par cons\u00e9quent \u00eatre mises en cache tr\u00e8s efficacement.<\/p>\n\n\n\n

En revanche, une boutique WooCommerce comporte de nombreuses op\u00e9rations dynamiques. Le panier, la commande, le compte client, les stocks, les prix et d'autres fonctionnalit\u00e9s peuvent d\u00e9pendre de l'utilisateur ou de l'\u00e9tat.<\/p>\n\n\n\n

C'est pourquoi la performance sous WooCommerce doit \u00eatre examin\u00e9e de mani\u00e8re plus nuanc\u00e9e.<\/p>\n\n\n\n

Par exemple, une page d'accueil de boutique extr\u00eamement bien mise en cache dit peu de choses sur la rapidit\u00e9 avec laquelle le tunnel d'achat ou une recherche de produits complexe est trait\u00e9e.<\/p>\n\n\n\n

wp-admin lent : v\u00e9rifier les extensions et les processus en arri\u00e8re-plan<\/h2>\n\n\n\n

Si seul l'espace d'administration de WordPress est lent, vous devriez examiner quels processus s'y d\u00e9roulent.<\/p>\n\n\n\n

Les extensions peuvent charger des widgets de tableau de bord, contacter des serveurs de licence externes, calculer des statistiques ou traiter des donn\u00e9es en arri\u00e8re-plan.<\/p>\n\n\n\n

Un grand nombre de requ\u00eates AJAX ou REST administratives peut \u00e9galement s'av\u00e9rer pertinent.<\/p>\n\n\n\n

Puisque la zone d'administration ne peut g\u00e9n\u00e9ralement pas \u00eatre enti\u00e8rement mise en cache comme une page publique, les processus inefficaces y sont particuli\u00e8rement visibles.<\/p>\n\n\n\n

classer correctement admin-ajax.php<\/h2>\n\n\n\n

WordPress et les plugins peuvent modifier le fichier :<\/p>\n\n\n\n

wp-admin\/admin-ajax.php<\/code><\/p>\n\n\n\n

f\u00fcr AJAX-Anfragen verwenden.<\/p>\n\n\n\n

Viele Zugriffe darauf sind nicht automatisch problematisch. Wenn jedoch sehr h\u00e4ufige oder besonders langsame AJAX-Anfragen auftreten, sollte gepr\u00fcft werden, welche Funktion beziehungsweise welches Plugin sie ausl\u00f6st.<\/p>\n\n\n\n

Das blo\u00dfe Blockieren von admin-ajax.php<\/code> ist keine sinnvolle allgemeine Performance-L\u00f6sung und kann Funktionen der Website besch\u00e4digen.<\/p>\n\n\n\n

WordPress REST API nicht pauschal deaktivieren<\/h2>\n\n\n\n

WordPress und moderne Plugins verwenden die REST API f\u00fcr zahlreiche Funktionen.<\/p>\n\n\n\n

Sie aus Performance-Gr\u00fcnden vollst\u00e4ndig zu deaktivieren, kann den Block-Editor oder Erweiterungen beeintr\u00e4chtigen.<\/p>\n\n\n\n

Wenn REST-Anfragen auff\u00e4llig viel Last erzeugen, sollte die verursachende Anwendung beziehungsweise Route identifiziert werden.<\/p>\n\n\n\n

WP-Cron kann die Performance beeinflussen<\/h2>\n\n\n\n

WordPress verwendet standardm\u00e4\u00dfig WP-Cron, um geplante Aufgaben auszuf\u00fchren.<\/p>\n\n\n\n

Dazu geh\u00f6ren je nach Website beispielsweise geplante Beitr\u00e4ge, Wartungsaufgaben und von Plugins registrierte Hintergrundjobs.<\/p>\n\n\n\n

Bei jedem Seitenaufruf kann WordPress pr\u00fcfen, ob geplante Aufgaben f\u00e4llig sind.<\/p>\n\n\n\n

Wenn sehr viele oder besonders aufwendige Cron-Aufgaben anstehen, kann dies die Website belasten.<\/p>\n\n\n\n

Entscheidend ist deshalb nicht nur, dass WP-Cron existiert, sondern welche Aufgaben dar\u00fcber ausgef\u00fchrt werden und wie lange diese ben\u00f6tigen.<\/p>\n\n\n\n

WP-Cron durch einen echten Cronjob ersetzen<\/h2>\n\n\n\n

Auf geeigneten Hosting-Umgebungen kann es sinnvoll sein, den WordPress-internen Cron-Aufruf nicht bei normalen Seitenaufrufen anzusto\u00dfen, sondern kontrolliert \u00fcber einen serverseitigen Cronjob auszuf\u00fchren.<\/p>\n\n\n\n

Daf\u00fcr kann WordPress beispielsweise mit:<\/p>\n\n\n\n

DISABLE_WP_CRON<\/code><\/p>\n\n\n\n

entsprechend konfiguriert werden.<\/p>\n\n\n\n

Das sollte jedoch nur geschehen, wenn anschlie\u00dfend tats\u00e4chlich ein zuverl\u00e4ssiger externer Cronjob eingerichtet wird.<\/p>\n\n\n\n

\n

Attention :<\/strong> WP-Cron einfach zu deaktivieren, ohne einen Ersatz einzurichten, kann geplante WordPress- und Plugin-Aufgaben verhindern.<\/p>\n<\/blockquote>\n\n\n\n

PHP-Version beeinflusst WordPress-Performance<\/h2>\n\n\n\n

WordPress wird serverseitig \u00fcberwiegend mit PHP ausgef\u00fchrt. Die verwendete PHP-Version beeinflusst deshalb Kompatibilit\u00e4t, Sicherheit und Performance.<\/p>\n\n\n\n

Eine aktuelle, von WordPress und den eingesetzten Erweiterungen unterst\u00fctzte PHP-Version ist grunds\u00e4tzlich sinnvoll.<\/p>\n\n\n\n

Du solltest eine PHP-Version aber nicht ausschlie\u00dflich deshalb wechseln, weil eine h\u00f6here Versionsnummer vermeintlich automatisch jede Website schneller macht.<\/p>\n\n\n\n

Vor einem Wechsel m\u00fcssen Plugins, Theme und individueller Code kompatibel sein.<\/p>\n\n\n\n

Nous vous expliquons comment proc\u00e9der sous Modifier la version PHP pour WordPress et v\u00e9rifier la compatibilit\u00e9<\/a>.<\/p>\n\n\n\n

PHP Memory Limit und Performance unterscheiden<\/h2>\n\n\n\n

Das PHP Memory Limit bestimmt, wie viel Arbeitsspeicher ein einzelner PHP-Prozess beziehungsweise eine PHP-Ausf\u00fchrung innerhalb der jeweiligen Konfiguration verwenden darf.<\/p>\n\n\n\n

Erreicht WordPress dieses Limit, kann ein Fehler wie:<\/p>\n\n\n\n

Taille de m\u00e9moire autoris\u00e9e ... \u00e9puis\u00e9e<\/code><\/p>\n\n\n\n

survenir.<\/p>\n\n\n\n

Ein h\u00f6heres Memory Limit macht eine normal funktionierende WordPress-Seite jedoch nicht automatisch schneller.<\/p>\n\n\n\n

Wenn ein Plugin ungew\u00f6hnlich viel Speicher verbraucht, kann eine Erh\u00f6hung des Limits au\u00dferdem lediglich das Symptom verschieben.<\/p>\n\n\n\n

Die Unterschiede erkl\u00e4ren wir ausf\u00fchrlich unter Limite de m\u00e9moire PHP dans WordPress : identifier et corriger l'erreur<\/a>.<\/p>\n\n\n\n

PHP OPcache<\/h2>\n\n\n\n

PHP-Code muss f\u00fcr die Ausf\u00fchrung verarbeitet werden. OPcache kann bereits kompilierten PHP-Bytecode im Arbeitsspeicher zwischenspeichern, sodass PHP-Dateien nicht bei jeder Anfrage vollst\u00e4ndig neu kompiliert werden m\u00fcssen.<\/p>\n\n\n\n

Auf modernen PHP-Hosting-Umgebungen ist OPcache deshalb ein wichtiger Bestandteil der serverseitigen Performance.<\/p>\n\n\n\n

Als WordPress-Benutzer musst du daran normalerweise nicht st\u00e4ndig \u00c4nderungen vornehmen. Bei einer technischen Performance-Analyse geh\u00f6rt die PHP-Laufzeitumgebung jedoch zum Gesamtbild.<\/p>\n\n\n\n

Hosting-Ressourcen k\u00f6nnen zum Flaschenhals werden<\/h2>\n\n\n\n

Auch eine technisch gut optimierte WordPress-Website ben\u00f6tigt Rechenleistung, Arbeitsspeicher, Datenbankleistung und I\/O-Ressourcen.<\/p>\n\n\n\n

Wenn eine Website dauerhaft mehr Ressourcen ben\u00f6tigt, als ihre Umgebung bereitstellen kann, k\u00f6nnen Anfragen langsamer verarbeitet werden.<\/p>\n\n\n\n

Das betrifft beispielsweise stark frequentierte Websites, umfangreiche WooCommerce-Shops oder Websites mit ressourcenintensiven Plugins.<\/p>\n\n\n\n

Bei CURIAWEB verwenden unsere WordPress-Hosting-Angebote<\/a> eine f\u00fcr WordPress ausgelegte Hosting-Umgebung. Trotzdem sollte bei einem konkreten Performance-Problem immer zuerst gepr\u00fcft werden, welche Ressource tats\u00e4chlich limitiert<\/strong>, statt pauschal mehr Serverleistung als L\u00f6sung anzunehmen.<\/p>\n\n\n\n

CloudLinux-Ressourcen richtig interpretieren<\/h2>\n\n\n\n

In einer CloudLinux-Hosting-Umgebung k\u00f6nnen Ressourcen eines Hosting-Accounts kontrolliert begrenzt werden. Dadurch kann ein einzelner Account nicht unbegrenzt Ressourcen des gesamten Servers beanspruchen.<\/p>\n\n\n\n

Wenn eine WordPress-Website wiederholt an solche Limits st\u00f6\u00dft, ist das eine wichtige Diagnoseinformation.<\/p>\n\n\n\n

Entscheidend ist jedoch, quel<\/strong> Limit erreicht wird und warum.<\/p>\n\n\n\n

Ein pl\u00f6tzlich stark erh\u00f6hter Ressourcenverbrauch kann beispielsweise durch ein problematisches Plugin, Bots, Cronjobs oder ungew\u00f6hnlich viele dynamische Anfragen verursacht werden. Ein gr\u00f6\u00dferes Hosting-Paket w\u00fcrde in einem solchen Fall m\u00f6glicherweise nur mehr Spielraum schaffen, ohne die Ursache zu beseitigen.<\/p>\n\n\n\n

CPU-Auslastung<\/h2>\n\n\n\n

PHP-Code, Datenbankoperationen und andere Prozesse ben\u00f6tigen CPU-Zeit.<\/p>\n\n\n\n

Wenn eine Website dauerhaft rechenintensive Aufgaben ausf\u00fchrt, kann die CPU zum Engpass werden.<\/p>\n\n\n\n

Besonders interessant ist dabei, ob die hohe Last permanent oder nur zu bestimmten Zeiten auftritt.<\/p>\n\n\n\n

Wiederkehrende Lastspitzen k\u00f6nnen beispielsweise auf Cronjobs, Backups, Imports, Scans oder Bots hindeuten.<\/p>\n\n\n\n

I\/O und Festplattenzugriffe<\/h2>\n\n\n\n

WordPress liest und schreibt Dateien und Daten. Auch Plugins k\u00f6nnen gro\u00dfe Mengen an Dateioperationen verursachen.<\/p>\n\n\n\n

Backups, Bildverarbeitung, Sicherheits-Scans, Imports und umfangreiche Logdateien sind Beispiele f\u00fcr Prozesse, die I\/O-Ressourcen beanspruchen k\u00f6nnen.<\/p>\n\n\n\n

Schneller NVMe-Speicher ist hilfreich, kann aber ineffiziente oder unn\u00f6tig h\u00e4ufige Dateioperationen nicht vollst\u00e4ndig kompensieren.<\/p>\n\n\n\n

PHP-Prozesse und gleichzeitige Anfragen<\/h2>\n\n\n\n

Bei dynamischen Seitenaufrufen muss PHP Anfragen verarbeiten. Erreichen sehr viele nicht gecachte Anfragen gleichzeitig die Website, k\u00f6nnen verf\u00fcgbare Prozesse beziehungsweise Worker zum Engpass werden.<\/p>\n\n\n\n

Das ist einer der Gr\u00fcnde, warum effizientes Page Caching bei \u00f6ffentlich cachebaren Inhalten so wirkungsvoll sein kann: Nicht jeder Besucher ben\u00f6tigt dann eine vollst\u00e4ndige neue WordPress-Ausf\u00fchrung.<\/p>\n\n\n\n

Bots k\u00f6nnen WordPress belasten<\/h2>\n\n\n\n

Nicht jeder Website-Aufruf stammt von einem echten Besucher.<\/p>\n\n\n\n

Suchmaschinen, SEO-Tools, Monitoring-Dienste, KI-Crawler, Sicherheits-Scanner und unerw\u00fcnschte Bots k\u00f6nnen ebenfalls Anfragen erzeugen.<\/p>\n\n\n\n

Besonders aggressive Bots k\u00f6nnen dynamische URLs in hoher Frequenz aufrufen und dadurch PHP sowie Datenbank belasten.<\/p>\n\n\n\n

Bei unerkl\u00e4rlichen Lastspitzen lohnt sich deshalb auch ein Blick auf Access Logs und die angeforderten URLs.<\/p>\n\n\n\n

wp-login.php und automatisierte Login-Versuche<\/h2>\n\n\n\n

\u00d6ffentlich erreichbare WordPress-Websites erhalten h\u00e4ufig automatisierte Anfragen auf:<\/p>\n\n\n\n

wp-login.php<\/code><\/p>\n\n\n\n

Eine gro\u00dfe Zahl solcher Anfragen kann zus\u00e4tzliche Ressourcen beanspruchen.<\/p>\n\n\n\n

Geeignete Sicherheitsmechanismen k\u00f6nnen unerw\u00fcnschte Login-Versuche begrenzen. Die Login-Datei einfach zu l\u00f6schen oder WordPress-Core-Dateien zu ver\u00e4ndern, ist dagegen keine L\u00f6sung.<\/p>\n\n\n\n

XML-RPC als m\u00f6gliche Quelle von Requests<\/h2>\n\n\n\n

Je nach Konfiguration und verwendeten Funktionen kann:<\/p>\n\n\n\n

xmlrpc.php<\/code><\/p>\n\n\n\n

Anfragen erhalten.<\/p>\n\n\n\n

Ob XML-RPC ben\u00f6tigt wird, h\u00e4ngt von der konkreten Website und eingesetzten Diensten ab.<\/p>\n\n\n\n

Statt die Funktion pauschal aufgrund allgemeiner Performance-Empfehlungen zu deaktivieren, solltest du zun\u00e4chst pr\u00fcfen, ob dort tats\u00e4chlich relevante Last entsteht und ob abh\u00e4ngige Funktionen existieren.<\/p>\n\n\n\n

Backups k\u00f6nnen tempor\u00e4r Ressourcen ben\u00f6tigen<\/h2>\n\n\n\n

Ein vollst\u00e4ndiges WordPress-Backup muss m\u00f6glicherweise viele Dateien lesen, Archive erstellen und Datenbankinhalte exportieren.<\/p>\n\n\n\n

Bei gro\u00dfen Websites kann das sp\u00fcrbare Ressourcenlast verursachen.<\/p>\n\n\n\n

Wenn WordPress beispielsweise jeden Tag zu einer bestimmten Uhrzeit langsam wird, solltest du deshalb pr\u00fcfen, ob zu diesem Zeitpunkt Backups oder andere geplante Wartungsaufgaben laufen.<\/p>\n\n\n\n

Sicherheits-Scans ben\u00f6tigen ebenfalls Leistung<\/h2>\n\n\n\n

Ein Security-Plugin, das tausende Dateien untersucht, ben\u00f6tigt zwangsl\u00e4ufig Ressourcen.<\/p>\n\n\n\n

Das bedeutet nicht, dass Sicherheits-Scans grunds\u00e4tzlich schlecht sind. Ihre H\u00e4ufigkeit und Ausf\u00fchrung sollten jedoch zur Website und Hosting-Umgebung passen.<\/p>\n\n\n\n

Wenn Performance-Probleme immer w\u00e4hrend eines Scans auftreten, ist der zeitliche Zusammenhang ein wichtiger Hinweis.<\/p>\n\n\n\n

Logdateien k\u00f6nnen unbemerkt sehr gro\u00df werden<\/h2>\n\n\n\n

Fehlerhafte Plugins oder dauerhaft aktiviertes Debugging k\u00f6nnen gro\u00dfe Logdateien erzeugen.<\/p>\n\n\n\n

Eine bekannte WordPress-Debugdatei ist beispielsweise:<\/p>\n\n\n\n

wp-content\/debug.log<\/code><\/p>\n\n\n\n

Wenn ein Fehler bei jedem Seitenaufruf mehrfach protokolliert wird, kann diese Datei schnell wachsen.<\/p>\n\n\n\n

Debugging sollte deshalb zur Diagnose kontrolliert verwendet und anschlie\u00dfend wieder passend konfiguriert werden.<\/p>\n\n\n\n

Nous expliquons cela plus en d\u00e9tail sous Activer le d\u00e9bogage WordPress et utiliser les journaux d'erreurs<\/a>.<\/p>\n\n\n\n

Eine langsame externe API kann WordPress blockieren<\/h2>\n\n\n\n

Plugins kommunizieren teilweise w\u00e4hrend einer Anfrage mit externen Diensten.<\/p>\n\n\n\n

Wenn WordPress auf die Antwort eines langsamen oder nicht erreichbaren externen Servers wartet, kann die eigene Website verz\u00f6gert reagieren.<\/p>\n\n\n\n

Das ist besonders t\u00fcckisch, weil der eigene Server technisch einwandfrei funktionieren kann.<\/p>\n\n\n\n

Wenn Performance-Probleme sporadisch auftreten, k\u00f6nnen externe HTTP-Anfragen deshalb ebenfalls untersucht werden.<\/p>\n\n\n\n

DNS und Netzwerk nicht mit WordPress verwechseln<\/h2>\n\n\n\n

Bevor der Browser WordPress \u00fcberhaupt erreicht, muss die Domain aufgel\u00f6st und eine Verbindung zum Server hergestellt werden.<\/p>\n\n\n\n

Probleme auf dieser Ebene sind keine WordPress-Performance-Probleme im engeren Sinn.<\/p>\n\n\n\n

Eine vollst\u00e4ndige Analyse betrachtet deshalb auch, ob die Verz\u00f6gerung bereits vor der eigentlichen Serververarbeitung entsteht.<\/p>\n\n\n\n

CDN: sinnvoll, aber nicht automatisch notwendig<\/h2>\n\n\n\n

Ein Content Delivery Network kann statische Ressourcen \u00fcber geografisch verteilte Systeme bereitstellen und je nach Konfiguration weitere Optimierungen \u00fcbernehmen.<\/p>\n\n\n\n

Das kann insbesondere bei einem international verteilten Publikum sinnvoll sein.<\/p>\n\n\n\n

Ein CDN repariert jedoch keine langsame PHP-Funktion, keine ineffiziente Datenbankabfrage und kein fehlerhaftes Plugin.<\/p>\n\n\n\n

Bei einer haupts\u00e4chlich regionalen Zielgruppe sollte deshalb gepr\u00fcft werden, welches konkrete Problem durch ein CDN gel\u00f6st werden soll.<\/p>\n\n\n\n

Viele HTTP-Requests sind nicht automatisch schlecht<\/h2>\n\n\n\n

\u00c4ltere Performance-Anleitungen konzentrieren sich h\u00e4ufig stark darauf, die Anzahl einzelner Dateien m\u00f6glichst drastisch zu reduzieren.<\/p>\n\n\n\n

Die Zahl der Requests bleibt relevant, sollte aber nicht isoliert betrachtet werden.<\/p>\n\n\n\n

Dateigr\u00f6\u00dfe, Priorisierung, Cachebarkeit, \u00dcbertragungsprotokoll und Verarbeitungsaufwand im Browser spielen ebenfalls eine Rolle.<\/p>\n\n\n\n

Eine einzelne riesige JavaScript-Datei ist nicht automatisch besser als mehrere sinnvoll strukturierte kleinere Ressourcen.<\/p>\n\n\n\n

Core Web Vitals richtig einordnen<\/h2>\n\n\n\n

Bei der wahrgenommenen Nutzererfahrung sind nicht nur Sekunden bis zum vollst\u00e4ndigen Laden relevant.<\/p>\n\n\n\n

Moderne Performance-Messungen betrachten unter anderem, wann der wichtigste sichtbare Inhalt erscheint, wie schnell eine Seite auf Interaktionen reagiert und ob sich das Layout w\u00e4hrend des Ladens unerwartet verschiebt.<\/p>\n\n\n\n

Deshalb kann eine Website trotz akzeptabler Gesamt-Ladezeit eine schlechte Nutzererfahrung bieten.<\/p>\n\n\n\n

LCP \u2013 Largest Contentful Paint<\/h2>\n\n\n\n

Der Largest Contentful Paint betrachtet vereinfacht, wann ein gro\u00dfes beziehungsweise wichtiges Inhaltselement im sichtbaren Bereich dargestellt wird.<\/p>\n\n\n\n

H\u00e4ufig handelt es sich dabei um ein gro\u00dfes Bild, eine \u00dcberschrift oder einen anderen prominenten Inhalt.<\/p>\n\n\n\n

Ist beispielsweise das Hero-Bild sehr gro\u00df oder wird unn\u00f6tig verz\u00f6gert geladen, kann dies den LCP verschlechtern.<\/p>\n\n\n\n

INP \u2013 Interaction to Next Paint<\/h2>\n\n\n\n

Interaction to Next Paint betrachtet die Reaktionsf\u00e4higkeit einer Seite auf Benutzerinteraktionen \u00fcber den Besuch hinweg.<\/p>\n\n\n\n

Aufwendiges JavaScript kann beispielsweise dazu f\u00fchren, dass der Browser nach einem Klick oder einer anderen Interaktion nicht schnell genug reagieren kann.<\/p>\n\n\n\n

Eine schnelle Serverantwort allein garantiert deshalb noch keine gute Interaktionsperformance.<\/p>\n\n\n\n

CLS \u2013 Cumulative Layout Shift<\/h2>\n\n\n\n

Cumulative Layout Shift bewertet unerwartete Layoutverschiebungen.<\/p>\n\n\n\n

Wenn beispielsweise ein Bild zun\u00e4chst ohne reservierten Platz geladen wird und anschlie\u00dfend den restlichen Inhalt nach unten verschiebt, kann das die visuelle Stabilit\u00e4t beeintr\u00e4chtigen.<\/p>\n\n\n\n

Auch nachtr\u00e4glich geladene Banner, Fonts oder andere Elemente k\u00f6nnen dazu beitragen.<\/p>\n\n\n\n

Labordaten und echte Nutzerdaten unterscheiden<\/h2>\n\n\n\n

Performance-Tools k\u00f6nnen Tests unter kontrollierten Bedingungen durchf\u00fchren. Diese sogenannten Labordaten sind hervorragend f\u00fcr reproduzierbare Analysen geeignet.<\/p>\n\n\n\n

Echte Besucher verwenden jedoch unterschiedliche Ger\u00e4te, Browser und Netzwerkverbindungen.<\/p>\n\n\n\n

Felddaten beziehungsweise reale Nutzerdaten k\u00f6nnen deshalb ein anderes Bild zeigen.<\/p>\n\n\n\n

Beide Perspektiven sind n\u00fctzlich und sollten nicht miteinander verwechselt werden.<\/p>\n\n\n\n

Ein einzelner Speed-Test reicht nicht<\/h2>\n\n\n\n

Performance-Messungen k\u00f6nnen schwanken.<\/p>\n\n\n\n

Cache-Zustand, Netzwerk, externe Dienste und Hintergrundprozesse beeinflussen das Ergebnis.<\/p>\n\n\n\n

Deshalb solltest du nicht aufgrund eines einzigen Tests umfangreiche \u00c4nderungen an einer Website vornehmen.<\/p>\n\n\n\n

Mehrere Messungen unter vergleichbaren Bedingungen liefern eine bessere Grundlage.<\/p>\n\n\n\n

\n

Conseil pratique :<\/strong> Dokumentiere vor gr\u00f6\u00dferen Optimierungen einen Ausgangswert. \u00c4ndere anschlie\u00dfend m\u00f6glichst nur einen relevanten Bereich und miss erneut. So kannst du feststellen, ob eine Ma\u00dfnahme tats\u00e4chlich geholfen hat.<\/p>\n<\/blockquote>\n\n\n\n

Startseite allein ist kein ausreichender Test<\/h2>\n\n\n\n

Eine WordPress-Website besteht h\u00e4ufig aus sehr unterschiedlichen Seitentypen.<\/p>\n\n\n\n

F\u00fcr eine aussagekr\u00e4ftige Analyse solltest du beispielsweise auch einen normalen Beitrag, eine wichtige Landingpage und bei WooCommerce eine Produktseite betrachten.<\/p>\n\n\n\n

Wenn ausschlie\u00dflich eine einzelne Seite langsam ist, liegt die Ursache m\u00f6glicherweise im Aufbau genau dieser Seite und nicht in der gesamten WordPress-Installation.<\/p>\n\n\n\n

Mobile Performance besonders beachten<\/h2>\n\n\n\n

Eine Website, die auf einem leistungsstarken Desktop mit schneller Internetverbindung problemlos wirkt, kann auf einem durchschnittlichen Smartphone deutlich langsamer reagieren.<\/p>\n\n\n\n

Gro\u00dfe JavaScript-Mengen und aufwendige visuelle Effekte fallen auf schw\u00e4cheren Ger\u00e4ten st\u00e4rker ins Gewicht.<\/p>\n\n\n\n

Performance sollte deshalb nicht ausschlie\u00dflich vom eigenen B\u00fcrocomputer aus beurteilt werden.<\/p>\n\n\n\n

Warum ein Performance-Score nicht das alleinige Ziel ist<\/h2>\n\n\n\n

Tools verdichten komplexe Messwerte h\u00e4ufig zu einer Punktzahl.<\/p>\n\n\n\n

Solche Scores sind hilfreich, sollten aber nicht zum Selbstzweck werden.<\/p>\n\n\n\n

Eine Website sollte schnell, stabil und f\u00fcr reale Benutzer gut bedienbar sein. Eine technische \u00c4nderung, die lediglich einen Score verbessert, daf\u00fcr aber eine wichtige Funktion besch\u00e4digt, ist keine erfolgreiche Optimierung.<\/p>\n\n\n\n

WordPress regelm\u00e4\u00dfig aufr\u00e4umen \u2013 aber gezielt<\/h2>\n\n\n\n

Im Laufe der Zeit sammeln sich auf vielen Installationen nicht mehr verwendete Plugins, Themes, Medien, Testfunktionen und alte Konfigurationen an.<\/p>\n\n\n\n

Nicht alles davon macht die Website unmittelbar langsam. Unn\u00f6tige Komponenten erh\u00f6hen aber die Komplexit\u00e4t und k\u00f6nnen Wartung sowie Fehlersuche erschweren.<\/p>\n\n\n\n

Nicht mehr ben\u00f6tigte Erweiterungen sollten deshalb nach vorheriger Pr\u00fcfung sauber entfernt werden.<\/p>\n\n\n\n

Updates k\u00f6nnen Performance-Probleme l\u00f6sen<\/h2>\n\n\n\n

Aktuelle WordPress-, Plugin- und Theme-Versionen enthalten nicht nur neue Funktionen und Sicherheitskorrekturen. Entwickler verbessern teilweise auch Performance und Kompatibilit\u00e4t.<\/p>\n\n\n\n

Eine dauerhaft veraltete Installation ist deshalb keine sinnvolle Performance-Strategie.<\/p>\n\n\n\n

Updates sollten bei wichtigen Websites kontrolliert und mit einer funktionierenden Backup- beziehungsweise Wiederherstellungsstrategie durchgef\u00fchrt werden.<\/p>\n\n\n\n

Quand un plugin doit \u00eatre remplac\u00e9<\/h2>\n\n\n\n

Wenn eine Erweiterung dauerhaft unverh\u00e4ltnism\u00e4\u00dfig viele Ressourcen ben\u00f6tigt und keine Konfigurations- oder Update-L\u00f6sung existiert, kann ein Ersatz sinnvoll sein.<\/p>\n\n\n\n

Entscheidend ist dabei nicht, welches Plugin in irgendeiner Bestenliste als \u201eschnellstes\u201c bezeichnet wird, sondern welche Funktionen deine Website tats\u00e4chlich ben\u00f6tigt und wie die Alternative in deiner konkreten Umgebung arbeitet.<\/p>\n\n\n\n

Wann mehr Hosting-Ressourcen sinnvoll sind<\/h2>\n\n\n\n

Optimierung bedeutet nicht, dass jede Website mit minimalen Ressourcen betrieben werden muss.<\/p>\n\n\n\n

Wenn eine technisch sauber aufgebaute Website aufgrund echten Traffics oder legitimer dynamischer Prozesse dauerhaft hohe Ressourcen ben\u00f6tigt, kann mehr Rechenleistung die richtige L\u00f6sung sein.<\/p>\n\n\n\n

Vorher sollte jedoch ausgeschlossen werden, dass die Last haupts\u00e4chlich durch einen Fehler, Bots, einen au\u00dfer Kontrolle geratenen Cronjob oder eine ineffiziente Erweiterung entsteht.<\/p>\n\n\n\n

Performance-Probleme systematisch eingrenzen<\/h2>\n\n\n\n

Beginne mit dem konkreten Symptom. Ist die gesamte Website langsam oder nur eine Seite? Betrifft es das Frontend, wp-admin<\/code> oder beides? Ist bereits die Serverantwort langsam oder entstehen die Verz\u00f6gerungen erst beim Laden und Verarbeiten der Frontend-Ressourcen?<\/p>\n\n\n\n

Pr\u00fcfe danach, ob das Problem dauerhaft oder nur zu bestimmten Zeiten auftritt. Ein wiederkehrendes Zeitmuster kann auf Backups, Cronjobs, Scans oder andere geplante Prozesse hindeuten.<\/p>\n\n\n\n

Betrachte anschlie\u00dfend die letzten \u00c4nderungen. Wenn die Website direkt nach Installation eines Plugins, einem Update oder einer PHP-\u00c4nderung langsam geworden ist, besitzt du bereits einen wichtigen Anhaltspunkt.<\/p>\n\n\n\n

Erst danach solltest du gezielt Plugins, Datenbankabfragen, externe Requests, Cache, PHP und Hosting-Ressourcen untersuchen.<\/p>\n\n\n\n

Was du bei einer langsamen WordPress-Website besser nicht tun solltest<\/h2>\n\n\n\n

Installiere nicht f\u00fcnf Performance-Plugins gleichzeitig. Mehrere Systeme, die gleichzeitig Cache, CSS, JavaScript und Datenbank optimieren wollen, k\u00f6nnen neue Konflikte erzeugen und die Diagnose erschweren.<\/p>\n\n\n\n

L\u00f6sche nicht wahllos Datenbanktabellen oder Optionen, nur weil ein Optimierungstool sie als gro\u00df markiert. Gr\u00f6\u00dfe allein beweist kein Performance-Problem.<\/p>\n\n\n\n

Wechsle au\u00dferdem nicht gleichzeitig Theme, PHP-Version, Cache-System und mehrere Plugins. Wenn die Website danach schneller ist, wei\u00dft du nicht, welche Ma\u00dfnahme tats\u00e4chlich geholfen hat.<\/p>\n\n\n\n

Und erh\u00f6he Serverressourcen nicht automatisch, bevor du gepr\u00fcft hast, warum die vorhandenen Ressourcen ausgesch\u00f6pft werden.<\/p>\n\n\n\n

\n

R\u00e8gle de base :<\/strong> Erst messen, dann Ursache eingrenzen, anschlie\u00dfend gezielt optimieren und danach erneut messen. Performance-Optimierung ohne Vergleichswerte ist h\u00e4ufig nur Vermutung.<\/p>\n<\/blockquote>\n\n\n\n

Quelles informations aident le support de CURIAWEB ?<\/h2>\n\n\n\n

Wenn eine WordPress-Website bei CURIAWEB ungew\u00f6hnlich langsam ist, hilft eine m\u00f6glichst genaue Beschreibung des Problems wesentlich mehr als die allgemeine Aussage \u201eWordPress ist langsam\u201c.<\/p>\n\n\n\n

Teile beispielsweise mit, welche URL betroffen ist, ob das Problem auch im Adminbereich auftritt und seit wann du die Ver\u00e4nderung bemerkst. Wenn die Performance nur zu bestimmten Zeiten schlecht ist, ist auch der ungef\u00e4hre Zeitpunkt wichtig.<\/p>\n\n\n\n

Hilfreich ist au\u00dferdem zu wissen, ob unmittelbar zuvor Plugins, Themes, WordPress, PHP oder andere Einstellungen ver\u00e4ndert wurden.<\/p>\n\n\n\n

Bei auff\u00e4lligen Ressourcenwerten oder Fehlermeldungen k\u00f6nnen wir anschlie\u00dfend gezielt pr\u00fcfen, ob beispielsweise PHP, Datenbank, Prozesse oder Account-Ressourcen beteiligt sind.<\/p>\n\n\n\n

N'envoyez pas de mots de passe non sollicit\u00e9s.<\/p>\n\n\n\n

R\u00e9sum\u00e9<\/h2>\n\n\n\n

Eine langsame WordPress-Website hat selten nur eine m\u00f6gliche Ursache. Serverantwort, PHP, Datenbank, Plugins, Theme, Cache, Bilder, JavaScript, CSS, externe Dienste und Hosting-Ressourcen beeinflussen unterschiedliche Teile der Ladezeit.<\/p>\n\n\n\n

Deshalb sollte die Optimierung nicht mit dem Installieren eines beliebigen Performance-Plugins beginnen, sondern mit einer Messung und Eingrenzung des Problems.<\/p>\n\n\n\n

Ist bereits die dynamische Serverantwort langsam, solltest du insbesondere PHP-Verarbeitung, Datenbankabfragen, Plugins, externe API-Aufrufe, Cronjobs und Hosting-Ressourcen untersuchen. Antwortet der Server schnell, w\u00e4hrend die Seite im Browser langsam aufgebaut wird, r\u00fccken Bilder, JavaScript, CSS, Fonts und Drittanbieter-Ressourcen st\u00e4rker in den Fokus.<\/p>\n\n\n\n

Page Cache und persistenter Object Cache k\u00f6nnen WordPress erheblich entlasten, l\u00f6sen aber unterschiedliche Aufgaben und ersetzen keine saubere Anwendung. Auch mehr Serverleistung ist nur dann die richtige L\u00f6sung, wenn tats\u00e4chlich Ressourcen fehlen und nicht lediglich ein fehlerhafter Prozess unn\u00f6tig Last erzeugt.<\/p>\n\n\n\n

Eine nachhaltige WordPress-Optimierung folgt deshalb immer demselben Prinzip: messen, Ursache bestimmen, gezielt ver\u00e4ndern und erneut messen.<\/strong><\/p>","protected":false},"excerpt":{"rendered":"

Eine langsame WordPress-Website kann viele Ursachen haben. Gro\u00dfe Bilder, zu viele oder schlecht programmierte Plugins, langsame Datenbankabfragen, externe Dienste, fehlendes Caching, WP-Cron, PHP-Prozesse oder ausgelastete Hosting-Ressourcen k\u00f6nnen die Ladezeit einzeln oder gemeinsam beeinflussen. Deshalb gibt es keine seri\u00f6se Universall\u00f6sung nach dem Muster \u201eInstalliere dieses eine Performance-Plugin und WordPress ist schnell\u201c. Bevor du optimierst, solltest du […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_joinchat":[],"footnotes":""},"doc_category":[80],"doc_tag":[],"class_list":["post-22434","docs","type-docs","status-publish","hentry","doc_category-wordpress"],"year_month":"2026-09","word_count":4960,"total_views":"5","reactions":{"happy":"0","normal":"0","sad":"0"},"author_info":{"name":"Silvio Mazenauer","author_nicename":"admin-curia","author_url":"https:\/\/www.curiaweb.ch\/fr\/author\/admin-curia\/"},"doc_category_info":[{"term_name":"WordPress","term_url":"https:\/\/www.curiaweb.ch\/fr\/hilfe-kategorie\/wordpress\/"}],"doc_tag_info":[],"knowledge_base_info":[],"knowledge_base_slug":[],"_links":{"self":[{"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/docs\/22434","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/comments?post=22434"}],"version-history":[{"count":1,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/docs\/22434\/revisions"}],"predecessor-version":[{"id":22436,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/docs\/22434\/revisions\/22436"}],"wp:attachment":[{"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/media?parent=22434"}],"wp:term":[{"taxonomy":"doc_category","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/doc_category?post=22434"},{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/doc_tag?post=22434"}],"curies":[{"name":"Bien jou\u00e9","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}