PHP propulse encore près de 77% du web. Pourtant, à chaque conférence tech, quelqu'un annonce sa mort. Trop vieux, trop lent, pas assez moderne. Nous avons voulu vérifier en gardant un site 100% PHP et en visant les meilleurs scores Lighthouse possibles en une journée de boulot. Pas de migration vers un framework JavaScript à la mode, pas de réécriture complète : juste du PHP, du bon sens et quelques optimisations ciblées. Spoiler : les résultats ont de quoi surprendre, et ils remettent en question pas mal d'idées reçues sur ce qu'il faut pour faire un site rapide en 2026.
"PHP est Mort" (depuis 10 ans parait-il): vraiment ?
Pendant que la hype pousse vers React, Vue, Svelte ou encore Angular, PHP continue de tourner sous WordPress, Magento, Laravel, Symfony et des millions de sites à travers le monde. Le langage évolue en silence : PHP 8.5 apporte des performances natives impressionnantes, un typage plus strict et des fonctionnalités modernes qui n'ont rien à envier aux langages "cool". La vraie question n'est pas "quel framework est tendance" mais "est-ce que mon site est rapide, accessible et bien référencé ?". Et là, PHP a encore beaucoup à dire. Le problème n'a jamais été le langage, mais la façon dont on l'utilise.
De 61 à 90+ au Lighthouse
Le score Lighthouse, c'est la note que Google attribue à votre site sur 100. Plus il est haut, mieux votre site est perçu par les moteurs de recherche et par vos visiteurs. Nous sommes partis d'un score de 68 en performances, ce qui est plutôt moyen. Après un cycle d'optimisation méthodique : 99. Le TTFB (temps de réponse du serveur) est tombé à 32ms, ce qui signifie que le serveur répond quasi instantanément. Le LCP (temps d'affichage du contenu principal) est passé de 12.7 secondes à 0.9 seconde, soit plus de dix fois plus rapide. Le premier rendu visible est passé de 5.1s à 0.5s. Côté CSS, nous avons retiré 59% de code inutilisé qui ralentissait le chargement pour rien. Côté JS, jQuery a été supprimé et remplacé par du JavaScript natif, plus léger et plus rapide. Tout ça sans changer de stack, sans toucher à l'architecture, sans réécrire une seule page.
SWUP : le feeling SPA sans framework JS
SWUP, c'est une petite librairie JavaScript qui transforme la navigation de votre site. Concrètement, quand un visiteur clique sur un lien, SWUP intercepte le clic, charge le nouveau contenu en arrière-plan et l'injecte dans la page avec une transition fluide. Résultat : zéro flash blanc, la navbar reste en place, la navigation semble instantanée. Le visiteur a l'impression d'utiliser une application React ou une appli mobile, avec des transitions élégantes entre les pages. Sauf que derrière, c'est du PHP classique qui sert les pages. Pas de Node.js, pas de build complexe, pas de SSR à configurer. SWUP précharge même les liens au survol, ce qui donne une sensation de vitesse encore plus marquée. C'est tout le confort d'une SPA, sans la complexité d'une SPA.
Le grand ménage : moins de code, plus de vitesse
Plutôt que de tout reconstruire depuis zéro (le réflexe classique du développeur), nous avons choisi la voie du pragmatisme : nettoyer l'existant. jQuery a été supprimé et chaque interaction réécrite en JavaScript natif. PurgeCSS a analysé chaque page du site et supprimé le CSS inutile : de 828 Ko à 339 Ko, soit presque 500 Ko de code en moins à télécharger. Les images situées sous le fold chargent en lazy loading, tandis que l'image hero passe en priorité haute pour accélérer le LCP. Le reCAPTCHA du formulaire de contact ne se charge que quand l'utilisateur interagit avec le formulaire, évitant ainsi des requêtes inutiles au chargement. La compression Brotli a été ajoutée côté serveur, les durées de cache optimisées. La performance web, c'est souvent une histoire de soustraction : retirer ce qui est inutile plutôt qu'ajouter de nouvelles couches.
Redis, sécurité et le dernier kilomètre
Côté serveur, Redis met en cache les pages complètes pour un temps de réponse de ~3 millisecondes. La page est servie depuis la mémoire avant même que PHP n'ait besoin de s'exécuter. Brotli compresse les assets texte pour réduire encore le poids sur le réseau. Les headers de sécurité sont en place : HSTS pour forcer le HTTPS, CSP pour bloquer les scripts malveillants, X-Frame-Options pour empêcher l'intégration non autorisée. L'accessibilité est passée de 76 à 96, grâce à un audit ARIA et des corrections sur la navigation clavier.
Monolithique et fier de l'être
Alors, faut-il passer à React pour un site vitrine, un blog, un catalogue ? Probablement pas. Les frameworks JavaScript ont leur place pour des applications complexes avec beaucoup d'interactions. Mais pour afficher du contenu, guider un visiteur et convertir, PHP fait le travail aussi bien, souvent plus vite, et avec une fraction de la complexité. Et il y a un avantage souvent sous-estimé : un monolithe PHP, c'est un seul dépôt, un seul déploiement, un seul serveur à surveiller. Pas de pipeline CI/CD à orchestrer entre un front et un back séparés, pas de builds Node de 3 minutes, pas d'API intermédiaire à versionner. Un [git push + webhook] et c'est live en prod. La simplicité du déploiement, c'est aussi du temps gagné, moins de points de défaillance et une maintenance que n'importe quel développeur peut reprendre sans lire 40 pages de documentation DevOps. Choisissez votre stack selon votre besoin réel, pas selon la hype du moment.
Petite note méthodologique : les scores Lighthouse présentés ici ont été mesurés sans scripts marketing tiers (GTM, analytics, pixels) afin d'isoler la performance réelle du code. En production, ces scripts impactent inévitablement les métriques, c'est le prix à assumer pour réaliser un tracking appronfondi 💀.
