Trois clics, un gain immédiat
PHP produit du HTML côté serveur : Googlebot reçoit une page complète, sans rendu JavaScript à attendre. Le seul vrai sujet est le temps de réponse, et il se règle dans cet ordre : version de PHP, cache de pages, OPcache, requêtes SQL, hébergement. En août 2026, seules PHP 8.4 et 8.5 sont en support actif, et plus d'un site PHP sur trois tourne encore sur une branche morte.
Pourquoi PHP n'est pas un problème de SEO
La question revient à chaque audit, en général posée par un développeur qui aimerait refaire le site avec autre chose : est-ce que PHP nous pénalise ? Non. Il est même dans la position la plus confortable qui soit vis-à-vis d'un moteur de recherche.
Un serveur PHP renvoie du HTML déjà assemblé. Le robot reçoit la page entière au premier appel, avec son texte, ses liens et ses balises, et il n'a rien d'autre à faire. Une application JavaScript rendue côté client renvoie, elle, un squelette vide que Google doit mettre en file d'attente pour un second passage de rendu. C'est ce décalage qui produit les pages indexées sans contenu qu'on retrouve régulièrement en audit, sujet que je traite dans JavaScript et SEO.
Au 23 août 2026, PHP fait tourner 70,2 % des sites dont on connaît le langage serveur. WordPress, PrestaShop, Drupal, Magento et la quasi-totalité des sites français à contenu sont dans ce cas. Si le langage posait un problème de classement, il se verrait.
La version, le levier le moins cher qui existe
C'est mon premier réflexe sur un site lent, avant même de regarder le code, parce que c'est la seule optimisation qui se fait en trois clics dans un panneau d'hébergement et qui produit un gain mesurable sans toucher une ligne.
Voici le calendrier officiel de support, tel qu'il se lit aujourd'hui.
| Branche | Sortie | Support actif jusqu'au | Correctifs de sécurité jusqu'au | État en août 2026 |
|---|---|---|---|---|
| PHP 8.5 | 20 nov. 2025 | 31 déc. 2027 | 31 déc. 2029 | Support actif |
| PHP 8.4 | 21 nov. 2024 | 31 déc. 2026 | 31 déc. 2028 | Support actif |
| PHP 8.3 | 23 nov. 2023 | 31 déc. 2025 | 31 déc. 2027 | Sécurité seule |
| PHP 8.2 | 8 déc. 2022 | 31 déc. 2024 | 31 déc. 2026 | Sécurité seule, et pour quatre mois |
| PHP 8.1 et antérieures | Non applicable | Non applicable | Non applicable | Fin de vie, plus aucun correctif |
Le chiffre qui devrait inquiéter plus qu'il ne le fait. Parmi les sites en PHP, 63,2 % sont en PHP 8, 28,9 % en PHP 7, 7,9 % en PHP 5 et 0,1 % en PHP 4. Autrement dit, 36,9 % des sites PHP tournent sur une branche qui ne reçoit plus aucun correctif de sécurité, et le compte réel est plus élevé encore puisque PHP 8.0 et 8.1 sont également en fin de vie tout en étant comptés dans les 63,2 %. Le sujet est d'abord la sécurité : un site piraté et injecté de liens sortants perd ses positions bien plus vite qu'un site lent.
Sur le gain de vitesse, méfiez-vous des chiffres qui circulent. Les comparaisons du type « PHP 8 est deux à trois fois plus rapide que PHP 7 » viennent de bancs d'essai synthétiques et ne se transposent pas telles quelles. Sur un site réel, le gain dépend surtout de la quantité de code exécutée à chaque page, et la seule valeur qui vous concerne est la vôtre : relevez le TTFB de trois URL avant la bascule, refaites la mesure après. Sans ce relevé, personne ne peut vous dire ce que vous avez gagné.
Le TTFB, et ce qu'il est vraiment
Le TTFB, time to first byte, mesure le temps entre la requête du navigateur et le premier octet de réponse. C'est là que le travail de PHP se voit : exécuter le code, interroger la base, assembler le HTML.
La confusion est partout sur ce point. Le TTFB n'est pas un signal Web essentiel, c'est une métrique de diagnostic. Il compte pour une raison décisive, celle de conditionner le LCP, qui en est un. Un serveur qui répond en 1,5 seconde rend mathématiquement impossible un LCP sous 2,5 secondes, quelle que soit la qualité du reste.
| TTFB | Lecture | Ce qu'il faut regarder ensuite |
|---|---|---|
| 0,8 s ou moins | Bon | Le serveur n'est pas votre problème. Regardez les images et le rendu. |
| 0,8 à 1,8 s | À améliorer | Le LCP devient difficile à tenir. Priorité au cache de pages. |
| Plus de 1,8 s | Mauvais | Rien d'autre ne servira tant que ce n'est pas réglé. |
Un repère de terrain, en complément : ce site, servi en HTML pré-généré, répond sous 100 ms. Sur un WordPress mutualisé correctement mis en cache, entre 200 et 500 ms est un objectif réaliste. Au-delà de 800 ms, il y a toujours une cause identifiable, et c'est presque toujours l'une des cinq de la section suivante.
Les cinq leviers, dans l'ordre de rentabilité
L'ordre compte autant que la liste. Chacun de ces leviers coûte plus cher que le précédent et rapporte moins.
- 1. Monter de version
Trois clics dans le panneau d'hébergement, aucun code à toucher, un gain immédiat sur la totalité des pages. Le seul risque est la compatibilité des extensions, voir plus bas.
- 2. Mettre en cache les pages entières
C'est le levier le plus puissant, et de loin. Une page mise en cache n'exécute plus aucun code PHP ni aucune requête SQL : le serveur envoie un fichier. Sur WordPress, une extension de cache suffit. Sur un site sur mesure, un fichier HTML écrit sur disque fait le même travail sans dépendance.
- 3. Activer OPcache
PHP compile chaque script à chaque appel. OPcache garde le résultat compilé en mémoire et supprime cette étape. C'est un réglage serveur, souvent déjà actif chez les hébergeurs sérieux, à vérifier plutôt qu'à installer.
- 4. Regarder les requêtes SQL
Quand un site reste lent malgré tout, la cause est presque toujours ici, dans une requête sans index sur une table qui a grossi, ou dans une extension qui interroge la base à chaque chargement. C'est le seul levier qui demande un développeur, et c'est aussi celui qui règle les cas désespérés.
- 5. Changer d'hébergement
En dernier, et pas en premier comme on le fait souvent. Un serveur plus puissant qui exécute le même code non optimisé achète du temps, il ne résout rien. Sur un site déjà en cache, le gain est marginal.
Générer du statique depuis PHP
C'est l'architecture que j'utilise sur mes propres sites, et elle est aussi simple que peu répandue. Le principe : PHP sert à produire les pages, pas à les servir. Le résultat est écrit en HTML sur le disque, et c'est ce fichier que le serveur envoie aux visiteurs.
Ce qu'on y gagne : un temps de réponse qui ne dépend plus ni de la base de données ni de la charge, une résistance à peu près totale aux pics de trafic, et une surface d'attaque réduite puisqu'il n'y a plus de code exécuté à la demande. Ce site fonctionne ainsi, avec un TTFB systématiquement sous 100 ms.
Ce qu'on y perd : le contenu ne se met plus à jour tout seul. Il faut relancer une génération après chaque modification, ce qui convient parfaitement à un site éditorial et pas du tout à un catalogue dont le stock change toutes les heures.
| Architecture | TTFB typique | Pour qui | Le coût caché |
|---|---|---|---|
| PHP dynamique sans cache | 200 ms à plusieurs secondes | Personne, en production | Chaque visiteur paie le temps de génération |
| PHP dynamique avec cache de pages | Comparable au statique sur les pages en cache | La grande majorité des sites | Gérer la purge du cache, et les pages jamais mises en cache |
| HTML pré-généré depuis PHP | Sous 100 ms | Sites éditoriaux, vitrines, documentations | Relancer la génération à chaque publication |
| HTML écrit à la main | Sous 100 ms | Très petits sites figés | Toute modification est manuelle et se répète page par page |
Changer de version sans casser le site
C'est la crainte qui bloque la plupart des mises à jour, et elle est fondée : le code qui tournait sur l'ancienne version, lui, peut casser. Une extension WordPress abandonnée en 2019 utilise des fonctions supprimées depuis. La procédure que j'applique tient en cinq étapes.
- 1. Inventorier
Lister les extensions et le thème, et vérifier pour chacun la version de PHP déclarée compatible et la date de dernière mise à jour. Une extension sans mise à jour depuis trois ans pose un problème que le changement de version ne fera que révéler.
- 2. Dupliquer
Copier le site en préproduction, sur un sous-domaine bloqué à l'indexation. Voir la préproduction et le référencement pour ne pas se retrouver avec une copie indexée.
- 3. Basculer et parcourir
Changer la version sur la copie, puis parcourir les pages critiques, le tunnel de commande s'il y en a un, et le back-office. Les erreurs fatales se voient tout de suite ; les avertissements se lisent dans les journaux.
- 4. Passer en production hors trafic
Et mesurer le TTFB avant et après, sur les mêmes URL. Sans mesure avant, le gain est invérifiable.
- 5. Savoir revenir
Sur un mutualisé, le retour à la version précédente prend une minute dans le panneau. Le savoir avant de commencer change complètement le niveau de stress de l'opération.
Ce que je vérifie en premier sur un site lent
Trois choses, dans cet ordre, et elles prennent dix minutes. La version de PHP, lisible dans le panneau d'hébergement ou dans les en-têtes de réponse. La présence d'un cache de pages, vérifiable en comparant le TTFB d'un premier appel et d'un second sur la même URL : s'il ne change pas, il n'y a pas de cache. Et le TTFB d'une page de contenu comparé à celui d'un simple fichier d'image sur le même serveur : si l'image répond en 60 ms et la page en 1,2 seconde, le problème est bien dans l'exécution, pas dans le réseau.
Questions fréquentes
Sources
- php.net, « Supported Versions » : dates de sortie, de fin de support actif et de fin de support sécurité de chaque branche, consulté le 23 août 2026.
- W3Techs, « Usage statistics of PHP » : part de PHP parmi les langages serveur et répartition par version majeure, relevé du 23 août 2026.
- web.dev, « Time to First Byte (TTFB) » : seuils de référence et statut de métrique de diagnostic.