Version anglaise de mon ancien article Optimización web con ETags. Exemple avec WordPress
Cela fait un moment que je n'ai pas écrit sur l'optimisation. Ceux qui me connaissent savent pourquoi cela s’est produit. Cependant, je ne peux pas laisser les soi-disant experts WPO (Web Performance Optimization) m'empêcher d'écrire sur quelque chose que j'aime. Alors voici un nouveau post pour vous.
Je suis sûr que cela vous est déjà arrivé. Vous arrivez sur votre lieu de travail, allumez votre ordinateur, ouvrez votre email, et après l'avoir vérifié, ouvrez un terminal et tapez : git pull. Le terminal répond rapidement : Déjà à jour..
Vous êtes-vous déjà demandé ce qui se passe derrière ce git pull ? J'ai. Si je devais deviner, je dirais que lorsque vous effectuez un git pull, vous envoyez de manière transparente au serveur la date de la dernière modification apportée. Le référentiel vérifie la date de la dernière modification que vous envoyez par rapport à la date de la dernière modification dont il dispose, donc :
Ce processus, qui me paraissait le plus logique, n'est pas le vrai. Le vrai est similaire mais pas exact. Chaque fois qu'un push est effectué, le référentiel associe un jeton (un code d'identification alphanumérique, quelque chose comme ae3d9735f280381d0d97d3cdb26066eb16f765a5) au dernier commit. Lorsque vous effectuez un git pull, il compare le dernier jeton dont vous disposez avec la liste des jetons dont il dispose. Si votre token est ancien, il envoie les modifications depuis lors avec leurs tokens correspondants. Si le jeton était le plus récent, il vous indique que vous êtes à jour.
À ce stade, vous pourriez dire : Manuel, cet article n'était-il pas censé porter sur l'optimisation des sites Web avec WordPress ? En effet, c’est le cas. Le premier cas présenté (celui avec la date) et le second (celui avec le jeton) sont des manières de travailler dans le protocole HTTP. Regardons de plus près.
Imaginez que votre navigateur envoie une requête à mon serveur pour télécharger le favicon de mon site Web. Dans la réponse de mon serveur à votre navigateur, il y aura une chaîne (ou en-tête HTTP) : Last-Modified : Thu, 29 Dec 2016 11:55:29 GMT. Cela indique à votre navigateur la dernière modification du favicon. Ainsi, une fois que votre navigateur aura téléchargé l'image, il la stockera dans son cache avec les métadonnées "Last-Modified" et la valeur jeu. 29 décembre 2016 11:55:29 GMT.
Si, après quelques secondes, jours ou mois, vous décidez de visiter à nouveau mon site Web, votre navigateur aura à nouveau besoin du favicon de mon site. Cependant, il se souvient qu'il dispose également d'une copie de l'image dans son cache. Comment sait-il si le favicon dans son cache est le plus récent ou s'il doit le télécharger à nouveau ? Simple, il effectue un "git pull". Autrement dit, le navigateur envoie une nouvelle demande de favicon à mon serveur, indiquant qu'il dispose d'une version de l'image à partir d'une date spécifique. Il y a deux réponses possibles de mon serveur :
Si vous vous souvenez, au début de l'article, j'ai mentionné que Git utilise des jetons pour déterminer quand les modifications ont été apportées. HTTP, en plus de la date de dernière modification, permet de travailler avec des tokens appelés ETags (Entity Tags). Un ETag est un code alphanumérique (tel que 5864f9b1-47e) sans format prédéterminé (la norme HTTP ne précise pas, ou à peine, quel format doit avoir le token). Le propriétaire du site détermine le format.
Par défaut, les serveurs web comme Apache créent l'ETag pour chaque fichier en fonction de sa date de modification (et parfois aussi de la taille du fichier). Ceci est redondant (l'en-tête HTTP de la date de dernière modification est basé sur les mêmes critères) et pas optimal (car il ajoute plus d'informations aux requêtes qui ne servent à rien). Dans ce cas, il est conseillé de configurer votre serveur web pour ne pas utiliser d'ETags pour les fichiers. Par exemple, pour désactiver les fichiers ETags (ou FileETags) dans Apache, ajoutez le code suivant à votre fichier .htaccess : FileETag Aucun.
Vous vous demandez peut-être si le dialogue entre le navigateur/serveur utilisant un ETag est le même que celui que nous avons vu pour la date de dernière modification et si l'utilisation des deux méthodes est inefficace et redondante. Pourquoi utiliser les ETags, alors ?
La date de dernière modification est suffisante pour les requêtes HTTP de fichiers, mais elle est insuffisante pour les requêtes HTTP de pages Web (HTML). Une page Web dépend de nombreux facteurs/éléments interdépendants (contenu, commentaires, structure HTML, etc.) et pas seulement d'un seul fichier. Il serait donc très compliqué de trouver une date de dernière modification unifiée pour tous ces éléments. Je sais que cela peut être difficile à suivre, alors je vais essayer de l'expliquer différemment :
Imaginez que j'attribue la date de modification de cette page web (HTML) à la date de modification du texte du post. Lorsque votre navigateur visite la page, il met en cache la page ainsi que la date de dernière modification de la publication. Si vous le visitez à nouveau une minute plus tard, puisque le message n'a pas changé (et donc sa date de modification n'a pas changé), votre navigateur utilisera la version mise en cache. Si quelqu'un écrit un commentaire et que vous revenez, vous ne verrez pas le commentaire. Étant donné que le texte du message n'a pas changé, la date de modification non plus, votre navigateur vous montrera donc à nouveau la version mise en cache. La même chose se produirait si je modifiais le HTML et ajoutais un nouveau fichier CSS. Le contenu de la publication n'a pas changé, ni la date, donc votre navigateur affichera toujours la version en cache.
Si, au lieu de travailler avec les dates de dernière modification de la publication, nous attribuons un ETag à la page Web de la publication avec le format suivant : {post_content_modification_date}_{post_last_comment_date}_{WP_theme_version_number}
Lorsque votre navigateur visite la publication pour la première fois, il met en cache la page Web (HTML) avec son ETag associé en tant que métadonnées. Si l'un des critères du token change (la date de modification de la publication, la date du dernier commentaire ou la version actuelle du thème WP), l'ETag associé à la page Web sera différent. Ainsi, si vous visitez à nouveau la publication, mon serveur vous informera que l'ETag de votre navigateur n'est pas le plus récent et il renverra la page Web entière avec le nouvel ETag.
Si rien n'a changé, le token/ETag serait le même (dans le navigateur et le serveur), donc lorsque vous visitez la page avec votre navigateur, mon serveur enverrait une réponse 304, l'informant que rien n'a changé (en termes WPO, c'est encore "frais") et qu'il doit utiliser la version mise en cache.
Ce que je n'ai pas mentionné jusqu'à présent, ce sont les avantages des ETags. En voici quelques-uns :
Tout ce que nous avons couvert est à un niveau élevé, alors regardons un petit plugin qui utilise des ETags pour les pages/articles WordPress.
# etags.php
<?php
namespace trasweb\webperf\ETags;
/*
* Plugin Name: ETags en posts
* Plugin URI: https://trasweb.net/webperf/optimizacion-web-con-etags
* Description: Usa el cache en navegador para tus posts.
* Version: 0.0.1
* Author: Manuel Canga / Trasweb
* Author URI: https://trasweb.net
* License: GPL
*/
add_action('wp', function () {
if (is_admin() || ! is_singular()) {
return;
}
$etag_from_navigator = $_SERVER[ 'HTTP_IF_NONE_MATCH' ]??'';
$current_ETag = get_current_ETag();
if ($etag_from_navigator === $current_ETag) {
status_header(304);
exit;
}
header('ETag: ' . $current_ETag);
});
function get_current_ETag()
{
$last_modified_time_of_content = (int)get_post_time();
$date_of_last_comment = get_date_of_last_comment();
$theme_version = wp_get_theme()[ "Version" ]??'0.0.0';
return md5("{$last_modified_time_of_content}_{$date_of_last_comment}_{$theme_version}");
}
function get_date_of_last_comment()
{
$query = [
'post_id' => get_the_ID() ?: 0,
'orderby' => ['comment_date_gmt'],
'status' => 'approve',
'order' => 'DESC',
'number' => 1,
];
$last_comment = get_comments($query)[ 0 ]??null;
return $last_comment->comment_date_gmt??0;
}
Tout d'abord, permettez-moi de mentionner que ce plugin est uniquement à des fins éducatives. Comme pour toute technique d'optimisation Web, telle que la minification/combinaison de ressources CSS/JS ou l'utilisation de la mise en cache côté serveur, une étude du site est requise au préalable.
Comme vous pouvez le constater, cela ne pourrait pas être plus simple. Tout d'abord, l'ETag du navigateur est obtenu, s'il existe (ligne 20). Deuxièmement, l'ETag associé à la publication/page actuelle est récupéré (ligne 21).
Si les deux sont identiques, un code 304 est envoyé au navigateur (ligne 24, ce qui est le cas illustré dans l'image principale de cet article), et l'exécution se termine. Le navigateur recevra le code 304 et saura qu'il doit utiliser la version mise en cache de la page.
Si les ETags sont différents (soit parce que le navigateur visite pour la première fois, soit parce que le token a changé), l'ETag est envoyé au navigateur et WordPress est autorisé à poursuivre son processus (envoi du contenu de l'ETag actuel message/page).
L'ETag est généré dans la fonction get_current_ETag (lignes 31 à 38) en fonction de la dernière fois que la publication/la page a été modifiée, de la date du dernier commentaire sur la publication et de la version du thème actuel. Si l'un de ces paramètres change, le jeton changera, obligeant le navigateur à télécharger la nouvelle version du site Web.
C'est tout. J'espère que vous avez apprécié cet article et qu'il vous aidera à rendre votre site Web plus rapide.
Partagez-le, s'il vous plaît
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
