Passer au contenu 
J'optimise la vitesse de wordpress sans plugins avec des interventions manuelles qui réduisent visiblement les temps de chargement et ciblent de manière fiable les Core Web Vitals. Je garde ainsi le contrôle sur RequêtesLes ressources et les effets secondaires, et l'élimination des déchets à la source.
Points centraux
- photos compresser systématiquement avant le téléchargement et convertir au format WebP
- Chargement paresseux nativement par attribut HTML au lieu d'extensions surchargées
- Mise en cache via .htaccess/serveur et stratégie d'en-tête propre
- Code minimiser, regrouper et éviter les bloqueurs de rendu
- Ballast dans WordPress, supprimer la base de données et les thèmes
Pourquoi j'optimise sans plugins
Les plug-ins semblent pratiques, mais ils ajoutent des requêtes, des scripts et des styles qui bloquent les chemins de rendu initiaux et qui ne permettent pas à mon utilisateur d'accéder au site. TTFB se détériorent. Chaque dépendance supplémentaire augmente la surface d'erreur et rend plus difficile l'analyse des causes en cas de chute des performances. Avec des mesures manuelles, je réduis les chaînes de chargement et je maintiens le nombre de composants actifs au minimum. Je réduis ainsi les frais généraux, je reste flexible et je réagis plus rapidement aux nouvelles exigences. Cette approche permet d'éviter les effets secondaires des chaînes de mise à jour et de maintenir la maintenance. mince.
Rendre les images plus légères : Formats, tailles, compression
Les grandes images ne tuent pas le time-to-first-byte, mais elles dominent le temps de transfert et le LCP, c'est pourquoi je réduis chaque asset à l'avance. J'exporte les photos au format JPEG ou WebP et n'utilise le PNG que pour les vraies transparences. Je mets les dimensions à l'échelle exacte des largeurs de viewport nécessaires, au lieu de charger 4000px quand 800px suffisent. Ensuite, je compresse systématiquement avec Squoosh, ImageOptim ou Photoshop et je vérifie les artefacts visibles. Pour les variantes responsives, je mise sur srcset/sizes et j'utilise volontiers cette courte description. Guide des images responsivespour que le navigateur charge automatiquement la plus petite source utile et mon Transfert de données diminue.
Utiliser le lazy loading de manière native
Je ne charge les images et les iFrames que lorsqu'elles arrivent dans le viewport, et ce nativement par HTML5, au lieu d'inclure des scripts supplémentaires qui ne respectent pas mon Fil de discussion principal ne doit pas être chargé. L'attribut loading="lazy" est largement suffisant dans les navigateurs modernes. Je réduis ainsi le nombre d'octets initiaux et j'atténue la phase critique de rendu. En même temps, le contrôle reste transparent et je décide quels éléments above-the-fold je charge délibérément avec précipitation. Les images Hero critiques reçoivent loading="eager", tout le reste se charge. décalé.
<img src="beispiel.jpg" alt="Exemple d'image" loading="lazy">
<iframe src="video.html" title="Vidéo" loading="lazy"></iframe>Accélérer le LCP de manière ciblée : Priorités et caractères génériques
Pour améliorer la stabilité de Largest Contentful Paint, je marque explicitement mon plus grand élément Above-the-Fold. Les images reçoivent fetchpriority="high" et des dimensions définies pour que le navigateur les préfère et CLS évite d'avoir à le faire. J'ajoute un Preload si nécessaire, si le chemin est clair.
<!-- LCP-Image priorisieren -->
<link rel="preload" as="image" href="/assets/hero.webp" imagesrcset="/assets/hero-800.webp 800w, /assets/hero-1200.webp 1200w" imagesizes="(min-width: 800px) 1200px, 100vw">
<img src="/assets/hero-800.webp"
srcset="/assets/hero-800.webp 800w, /assets/hero-1200.webp 1200w"
sizes="(min-width: 800px) 1200px, 100vw"
width="1200" height="700"
fetchpriority="high"
loading="eager"
decoding="async"
alt="Hero">Pour les images et les conteneurs, je mets largeur/hauteur ou aspect-ratiopour éviter les sauts de mise en page. Pour les zones non critiques, j'utilise content-visibility : auto et contain-intrinsic-sizePour que le navigateur rende ultérieurement les zones situées en dehors du viewport sans déplacer la mise en page.
/* Réserver Above-the-Fold */
.hero { aspect-ratio : 12 / 7 ; }
/* Mettre en page les sections non visibles plus tard */
.section { content-visibility : auto ; contain-intrinsic-size : 1000px ; }
Configurer la mise en cache du navigateur de manière ciblée
Les visiteurs récurrents doivent charger des assets statiques à partir du cache, c'est pourquoi je définis des temps d'expiration directement au niveau du serveur par .htaccess ou dans le vHost. Des TTL longs pour les images, modérés pour CSS/JS, et des paramètres par défaut courts pour HTML me donnent l'équilibre entre actualité et vitesse. Je veille à la cohérence du versionnement des fichiers afin que les mises à jour prennent effet immédiatement malgré les TTL longs. Combiné avec des ETags ou des en-têtes Last Modified, le trafic diminue drastiquement. J'économise ainsi de la bande passante et raccourcis le temps de téléchargement perçu. Temps de chargement.
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "accès plus 1 an"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "accès plus 1 an"
ExpiresByType text/css "accès plus 1 mois"
ExpiresByType application/pdf "access plus 1 mois"
ExpiresByType text/javascript "accès plus 1 mois"
ExpiresByType application/x-javascript "access plus 1 mois"
ExpiresDefault "accès plus 2 jours"Stratégie de mise en cache, versionnement et revalidation
Je combine les longs TTL avec le hachage des noms de fichiers, afin que les clients puissent mettre en cache les données pendant une durée inchangée (style.9c2a.css) et les mises à jour sont immédiates. Pour les bundles fréquemment modifiés, je mets Contrôle du cache : public, max-age=31536000, immutabletandis que HTML court no-cache-des stratégies de recherche. Pour les réponses dynamiques, je préfère Demandes conditionnelles via ETag ou Dernière modificationpour que les clients effectuent des révisions avec parcimonie :
Header set Cache-Control "public, max-age=31536000, immutable"
Header set Cache-Control "no-cache, no-store, must-revalidate".Pour les contenus avec des variantes de format (par ex. WebP vs JPEG), je vérifie que Vary : Accept est correctement défini sur l'Edge ; ainsi, les mauvaises versions ne se retrouvent pas dans le cache. Je maintiens la cohérence des versions via des pipelines de construction, afin qu'aucun actif ne devienne obsolète sans contrôle.
Épurer CSS et JavaScript
Je minifie CSS/JS localement dans mon processus de construction et je supprime les commentaires, les espaces et les caractères inutilisés. Sélecteurs. Je mets les styles critiques pour Above-the-Fold en ligne, je charge le reste de manière asynchrone ou en tant que fichier différé. Je déplace les scripts bloquant le rendu à la fin, je leur ajoute defer/async et je limite le nombre de bibliothèques externes. Pour les frameworks, je vérifie le tree-shaking et les scopes d'importation afin de ne pas charger tout ce que j'utilise rarement. Lorsque c'est possible, je regroupe les fichiers afin de réduire les requêtes sans mettre en cache derrière. se détériorent.
Améliorer l'INP : Décharger le fil de discussion principal
Pour une faible interaction avec la prochaine peinture, je découpe les longues tâches en petits morceaux, j'évite le thrashing de mise en page et je découple les gestionnaires complexes des interactions. J'utilise defer pour les modules, définir des écouteurs d'événements passifs et planifier le travail non critique pendant les périodes d'inactivité :
document.addEventListener('touchstart', onTouch, { passive : true }) ;
const expensiveInit = () => { /* ... */ } ;
requestIdleCallback(expensiveInit, { timeout : 1500 }) ;
// Fractionner les longues tâches
function chunkedWork(items) {
const batch = items.splice(0, 50) ;
// traiter...
if (items.length) requestAnimationFrame(() => chunkedWork(items)) ;
}Je mesure les tâches longues dans DevTools, je supprime les bibliothèques en double et je remplace les utilitaires jQuery par des API natives. Je résume les mises à jour du DOM, j'utilise des transform au lieu de top/left et maintenir les reflux au minimum.
Se débarrasser du poids de WordPress
Je n'ai pas besoin de beaucoup de fonctionnalités WP sur les pages de production, donc je désactive les emojis, les oEmbeds et certaines parties de l'API REST et j'économise Requêtes. Ainsi, le head se rétrécit et moins de scripts bloquent First Paint. Je vérifie également les pingbacks, les liens RSD et le manifeste WLW et les désactive. Je désactive également les trackbacks et les XML-RPC lorsqu'ils ne jouent aucun rôle. Je réduis ainsi la surface d'attaque et préserve la phase de démarrage. facile.
// désactiver les emojis
remove_action( 'wp_head', 'print_emoji_detection_script', 7 ) ;
remove_action( 'wp_print_styles', 'print_emoji_styles' ) ;
// réduire les oEmbeds et l'API REST
remove_action( 'wp_head', 'wp_oembed_add_host_js' ) ;
add_filter('rest_enabled', '_return_false') ;
add_filter('rest_jsonp_enabled', '_return_false') ;Dompter les scripts tiers
Le code tiers est souvent le plus gros frein. Je l'initialise avec un certain retard, je n'intègre que le strict nécessaire et je ne le charge qu'après une interaction ou un consentement. Analytics/Tracking arrive async après le First Paint, je remplace les widgets sociaux par des liens statiques. Pour les iFrames, j'utilise loading="lazy" (chargement paresseux) et sandboxpour limiter les effets secondaires. Les embeds YouTube reçoivent une image d'aperçu et ne chargent le lecteur qu'au moment du clic - cela permet d'économiser plusieurs requêtes au moment du démarrage.
Gestion de la base de données sans aide
Je supprime les révisions superflues, vide les transients et nettoie les commentaires de spam via phpMyAdmin, afin que les requêtes soient plus rapides. répondre. Je vérifie que les options autoloaded n'ont pas une taille excessive, car elles se retrouvent dans chaque requête. Dans les petites installations, quelques instructions SQL ciblées suffisent pour optimiser les tables. Je contrôle si des jobs Cron sont en suspens et je nettoie les post-meta laissés par d'anciens plugins. Un entretien régulier évite que les requêtes ne s'emballent et que mon backend inerte volonté.
System-Cron au lieu de WP-Cron
Pour que les tâches Cron fonctionnent de manière fiable et performante, je les dissocie de l'appel de la page. Je désactive le WP-Cron et je planifie de véritables tâches système qui fonctionnent pendant les périodes creuses.
// dans wp-config.php
define('DISABLE_WP_CRON', true) ;# crontab -e (toutes les 5 minutes)
*/5 * * * /usr/bin/php -q /path/to/wp/wp-cron.php >/dev/null 2>&1Ainsi, aucun cron ne bloque le temps de réponse d'une requête régulière et les tâches récurrentes telles que le nettoyage de transients ou la génération de plan de site se déroulent de manière planifiable.
Examiner de manière critique le thème, les plugins et les polices de caractères
Je supprime les thèmes inactifs et toutes les extensions qui font double emploi avec des fonctions ou qui sont rarement utiles, afin que le Autochargeur se charge moins. Pour les polices, je réduis les variantes à Regular/Bold et deux styles de police, je les héberge localement et j'active le Preload pour le fichier principal. Je prépare les ressources externes avec DNS Prefetch lorsque j'en ai vraiment besoin. Pour les embeds YouTube, j'utilise des images de prévisualisation pour initialiser les iFrames plus tard. Ainsi, je garde le contrôle sur les chemins de rendu et maintiens la charge utile de départ petit.
Polices de caractères : comportement de chargement, subsetting, fallbacks
Les polices web influencent fortement la vitesse perçue. J'utilise affichage des polices : swap ou en optionpour que le texte soit immédiatement visible. Je contrôle les polices variables de manière critique et je subsecte les zones Unicode pour économiser des octets. Un préchargement ciblé du fichier WOFF2 le plus important réduit le FOIT.
@font-face {
font-family : 'Brand' ;
src : url('/fonts/brand-regular.woff2') format('woff2') ;
font-weight : 400 ;
font-style : normal ;
font-display : swap ;
unicode-range : U+000-5FF ; /* ensemble de base latin */
}Je définis des retours système propres (par ex. Segoe UI, Roboto, SF Pro, Arial) dans la pile de polices afin de minimiser les sauts de mise en page. À propos de size-adjust j'adapte les différences métriques pour que le passage du fallback à la police web soit à peine visible.
Serveur, PHP et protocoles
Sans infrastructure adaptée, toute optimisation est vouée à l'échec, c'est pourquoi je veille à utiliser des disques SSD rapides, des systèmes d'exploitation actuels et des logiciels de gestion de contenu. PHP-et le support HTTP/2. OPcache, Brotli/Gzip et le multiplexage HTTP/2 accélèrent la livraison et réduisent les blocages. Dans la mesure du possible, j'envisage HTTP/3/QUIC et je vérifie soigneusement la configuration et TLS ; ce petit article sur Mettre en œuvre HTTP/3. Les tests de charge et de stress me montrent comment le site réagit sous la charge. Je m'assure ainsi que ma pile supporte l'application porte et que mes mesures ont un impact.
| Fournisseur d'hébergement | Caractéristiques | Performance | Soutien | Rapport qualité-prix |
|---|---|---|---|---|
| webhoster.de | SSD, PHP 8.*, HTTP/2 | ★★★★★ | ★★★★★ | ★★★★★ |
| Concurrent 1 | SSD, PHP 7.*, HTTP/2 | ★★★★☆ | ★★★★☆ | ★★★★☆ |
| Concurrent 2 | HDD, PHP 7.*, pas de HTTP/2 | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
Optimiser PHP-FPM, OPcache et le transport
Je configure PHP-FPM de manière à ce que les requêtes n'atterrissent pas dans des files d'attente. pm, pm.max_children et pm.max_requests je dimensionne à la charge. OPcache reçoit suffisamment de mémoire pour éviter les recompilations.
; php.ini / www.conf
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
; PHP-FPM (exemples de valeurs)
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500Au niveau de la couche de transport, j'active Brotli avant Gzip, je garde Keep-Alive ouvert et je contrôle TLS-Resumption. En HTTP/2, je contrôle la priorisation pour que CSS/écriture et l'image LCP aient la priorité. Sous HTTP/3, je surveille les pertes de paquets et j'adapte le pacing.
CDN, en-tête de cache et géographie
Pour le trafic international, j'utilise un réseau Edge afin de réduire la latence et de rapprocher les ressources statiques de l'utilisateur. à livrer. Je veille à ce que les clés de cache soient propres, les en-têtes variants (par exemple pour WebP) et le versionnement cohérent. Je mets en cache les pages HTML critiques avec précaution, les réponses API de manière sélective et les images de manière agressive. Un bref aperçu de la Optimisation du CDN m'aide à éviter les écueils comme la double compression. Ainsi, je combine la mise en cache sur le serveur et la mise en cache en périphérie et je maintiens les coûts à un niveau raisonnable. Vue.
Formats, négociation et déduplication sur le edge
Je diffuse des images dans des formats modernes (WebP, AVIF en option) et m'assure que le CDN respecte la négociation de contenu. Il est important que les Accept-et l'unicité des clés de cache. J'évite le double Gzip en ne compressant qu'une seule fois (serveur ou Edge) et en désactivant le drapeau à l'autre extrémité. Pour le HTML, je place des TTL conservateurs et des ETags forts, les assets restent mis en cache de manière agressive.
Mesure, indicateurs et priorisation
Je commence avec un budget de performance clair et je me concentre sur le LCP, le CLS et l'INP plutôt que sur chaque milliseconde. isolé à considérer. Les données de terrain sont supérieures aux valeurs de laboratoire, c'est pourquoi je compare les signaux réels des utilisateurs aux tests. Les diagrammes en cascade révèlent les actifs bloquants, les cartes des requêtes montrent les bibliothèques en double et les fichiers de polices inutiles. Je mesure chaque changement individuellement afin d'identifier rapidement les régressions. Ce n'est que lorsque les chiffres s'améliorent de manière cohérente que je les déploie plus largement. de.
Méthode de travail : déployer proprement, dérouler rapidement
J'intègre des contrôles de performance dans mon processus de déploiement : Les builds génèrent des artefacts versionnés, les tests Lighthouse/DevTools sont exécutés sur Staging, et seuls les bundles vérifiés sont mis en ligne. Les indicateurs de fonctionnalités me permettent de déployer les modifications risquées de manière contrôlée et de les désactiver immédiatement si nécessaire. Cela me permet de maintenir des performances stables tout en développant de nouvelles fonctionnalités.
En bref, je résume : Voici comment je le mets en œuvre
J'optimise d'abord le contenu avec le plus grand levier : réduire les images, activer le lazy loading, les parties CSS critiques en ligne et les scripts bloquants. déplacer. Ensuite, je sécurise les stratégies de mise en cache du côté du navigateur et du serveur, je nettoie les fonctionnalités de WordPress et la base de données et je supprime les plugins inutiles. Je vérifie l'infrastructure, HTTP/2/3, Brotli et OPcache et veille à des processus de déploiement propres avec versionnement. Si nécessaire, je complète un CDN et règle les en-têtes et les variantes. Enfin, je contrôle les indicateurs de manière itérative jusqu'à ce que LCP, CLS et INP soient stables et dans le vert. Domaines sont couchés.
