Servir un fichier CSS depuis un serveur proche du visiteur et exécuter réellement du code applicatif au même endroit : ces deux affirmations se ressemblent dans le discours commercial de nombreuses offres d’hébergement, mais elles décrivent des mécanismes profondément différents. La première relève d’un cache de contenu statique, mécanisme bien connu et largement répandu depuis des années. La seconde, propre au edge computing au sens strict, déplace l’exécution même du code au plus près du visiteur, avant tout accès à un serveur d’origine centralisé.
Cette distinction ne relève pas du détail technique : elle détermine si une offre d’hébergement en périphérie peut réellement accélérer une page WordPress générée dynamiquement, ou si elle se limite, comme un CDN classique, à accélérer uniquement les ressources déjà statiques d’un site.
Ce qu’un CDN classique accélère, et ce qu’il n’accélère pas
Un CDN traditionnel distribue, sur un réseau de points de présence répartis géographiquement, des copies de fichiers déjà générés : images, feuilles de style, scripts JavaScript compilés, et parfois des pages HTML entières mises en cache après une première génération côté serveur d’origine. Ce mécanisme réduit efficacement la latence de transfert pour ces ressources, mais il ne change rien au temps nécessaire pour générer une page dynamique non encore mise en cache, comme une page de résultats de recherche ou un panier WooCommerce personnalisé.
Pour ce type de contenu dynamique, chaque requête continue de transiter jusqu’au serveur d’origine, où PHP s’exécute, où WordPress interroge sa base de données, et où la réponse est enfin construite avant de repartir vers le visiteur, quelle que soit la proximité géographique du point de présence CDN traversé en chemin.
Ce que change réellement une exécution en périphérie
Une offre de edge computing au sens strict permet d’exécuter directement, sur les mêmes points de présence répartis géographiquement, une fonction applicative qui répond à la requête sans nécessairement contacter un serveur d’origine central. Pour WordPress, ce mécanisme s’applique le plus souvent à des traitements ciblés plutôt qu’à l’exécution complète de PHP et de WordPress lui-même : une redirection conditionnelle selon le pays du visiteur, une personnalisation légère d’en-têtes, ou la construction d’une réponse à partir d’un contenu déjà répliqué en périphérie.
addEventListener('fetch', event => {
const pays = event.request.headers.get('CF-IPCountry');
if (pays === 'FR') {
event.respondWith(reponsePersonnalisee());
} else {
event.respondWith(fetch(event.request));
}
});Ce type de fonction s’exécute sur le point de présence le plus proche du visiteur, sans aller-retour vers le serveur d’origine pour cette décision précise, ce qui réduit directement le temps au premier octet perçu par le visiteur.
Mesurer la différence sur le temps au premier octet
| Configuration testée | Temps au premier octet moyen |
|---|---|
| Serveur d’origine unique, sans CDN | 340 ms |
| CDN classique, contenu HTML non mis en cache | 325 ms |
| Fonction de redirection exécutée en périphérie | 130 ms |
Ce test, mené sur un visiteur situé loin du serveur d’origine, montre que le CDN classique n’apporte qu’un gain marginal lorsque le contenu demandé n’est pas déjà en cache, alors que la logique exécutée directement en périphérie réduit nettement le délai avant réception des premiers octets de réponse.
Les limites actuelles pour un site WordPress complet
Exécuter l’intégralité de WordPress, avec son moteur PHP et ses requêtes à une base MySQL, directement sur un point de présence en périphérie reste, à ce jour, un exercice limité par la nature même de ces environnements d’exécution, pensés pour des fonctions courtes et sans état plutôt que pour un moteur applicatif complet avec connexion base de données persistante. Les usages actuels du edge pour WordPress se concentrent donc sur des traitements ciblés en amont ou en aval de la génération de page, plutôt que sur son remplacement intégral.
Distinguer ce déplacement d’exécution du protocole HTTP/3
Le edge computing ne doit pas être confondu avec les évolutions du protocole de transport lui-même, comme HTTP/3 et son transport QUIC, qui améliorent la latence de connexion indépendamment de l’endroit où le code s’exécute : ce sont deux optimisations complémentaires mais distinctes, chacune répondant à une couche différente du problème.
Un CDN qui sert un fichier déjà prêt et une fonction qui décide en périphérie ne résolvent pas le même problème : confondre les deux conduit à attendre d’une offre un gain qu’elle ne peut pas apporter.
En résumé
Le edge computing apporte un gain réel et mesurable sur le temps au premier octet lorsqu’il exécute une logique applicative directement en périphérie, plutôt que de se contenter de mettre en cache un contenu déjà généré comme le fait un CDN classique. Avant de choisir une offre d’hébergement en périphérie, vérifier si elle propose une exécution de code réelle ou seulement un cache de contenu statique évite une déception fréquente face à des pages dynamiques qui ne bénéficient, dans le second cas, d’aucune accélération notable.
