我的舊貼文 Optimización web con ETags 的英文版。 Ejemplo 與 WordPress
自從我上次寫關於優化的文章以來已經有一段時間了。認識我的人都知道為什麼會發生這種事。然而，我不能讓所謂的 WPO（Web 效能優化）專家阻止我寫一些我喜歡的東西。所以，這是給你的新貼文。
我確信這件事發生在你身上。您到達工作場所，打開計算機，打開電子郵件，檢查後打開終端機並輸入：git pull。終端快速回覆：已經是最新的..
你有沒有想過 git pull 背後發生了什麼事？我有。如果我必須猜測，我會說當你執行 git pull 時，你會透明地向伺服器發送你最後一次更改的日期。儲存庫會根據其上次變更的日期檢查您發送的上次變更的日期，因此：
- 如果您的日期較舊，它會向您發送自那時以來發生的所有推送/更改。它還會向您發送這些更改以及更改的日期。因此，如果您再次輸入 git pull，您將發送最後一次更改的日期，然後一切都會重新開始。
- 如果您的日期與儲存庫上次更改的日期匹配，它將告訴您一切都是最新的。
這個過程對我來說似乎是最符合邏輯的，但事實並非如此。真實的很相似，但不完全一樣。每次進行推送時，儲存庫都會將一個令牌（字母數字識別碼，例如 ae3d9735f280381d0d97d3cdb26066eb16f765a5）與最新提交相關聯。當您執行 git pull 時，它會將您擁有的最後一個令牌與其擁有的令牌清單進行比較。如果您的令牌是舊令牌，它會發送此後的變更及其相應的令牌。如果令牌是最新的，它會告訴您您是最新的。
此時，您可能會說：Manuel，這篇文章不是應該是關於使用 WordPress 優化網站的嗎？確實如此。第一種情況（帶有日期的情況）和第二種情況（帶有令牌的情況）都是 HTTP 協定中的工作方式。讓我們仔細看看。
最後修改時間
想像一下您的瀏覽器向我的伺服器發送請求以下載我網站的圖示。在我的伺服器到您的瀏覽器的回應中，將有一個字串（或 HTTP 標頭）：Last-Modified: Thu, 29 Dec 2016 11:55:29 GMT。這會告訴您的瀏覽器上次修改網站圖示的時間。因此，一旦您的瀏覽器下載了映像，它將使用元資料「Last-Modified」和值 Thu, 29 Dec 2016 11:55:29 GMT 將其儲存在快取中。
如果幾秒鐘、幾天或幾個月後，您決定再次造訪我的網站，您的瀏覽器將再次需要我網站的圖示。但是，它記得它的快取中還有該圖像的副本。它如何知道快取中的圖標是否是最新的或是否需要再次下載？很簡單，它執行“git pull”。也就是說，瀏覽器向我的伺服器發送對圖標的新請求，表明它具有特定日期的圖像版本。我的伺服器有兩種可能的回應：
- 我網站上目前的圖示較新，因此我的伺服器會將新圖像以及該圖像的新的最後修改日期發送到您的瀏覽器。
- 我網站上目前的圖示與您的瀏覽器顯示的日期相符。也就是說，伺服器的圖像和瀏覽器的快取圖像是相同的。然後，我的伺服器通知您的瀏覽器映像尚未修改（使用 HTTP 304 Not Modified 程式碼）。然後，您的瀏覽器將使用快取的圖像，從而不必再次下載圖像（從而節省資料計劃的許多位元組）。
電子標籤
如果您還記得，在文章開頭，我提到 Git 使用令牌來決定何時進行更改。除了上次修改日期之外，HTTP 還允許使用稱為 ETag（實體標籤）的令牌。 ETag 是一個字母數字代碼（例如 5864f9b1-47e），沒有預先確定的格式（HTTP 標準沒有指定或幾乎沒有指定令牌應具有的格式）。網站所有者決定格式。
預設情況下，Apache 等 Web 伺服器會根據檔案的修改日期（有時會根據檔案大小）為每個檔案建立 ETag。這是多餘的（最後修改日期的 HTTP 標頭基於相同的標準）並且不是最佳的（因為它向無用的請求添加了更多資訊）。在這種情況下，建議將 Web 伺服器設定為不對檔案使用 ETag。例如，要在 Apache 中停用檔案 ETag（或 FileETag），請將以下程式碼新增至您的 .htaccess 檔案：FileETag None。
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.
Avantages des ETags
Ce que je n'ai pas mentionné jusqu'à présent, ce sont les avantages des ETags. En voici quelques-uns :
- Moins de données transférées entre le serveur et le navigateur. Cela signifie des économies de données pour l'utilisateur (votre site Web est donc moins cher pour vos utilisateurs « Combien coûte la visite de votre site Web ? ») et également pour le serveur (important si vous disposez d'un plan d'hébergement basé sur le transfert de données).
- Le serveur économise l'effort de génération du HTML, avec tout ce que cela implique : économiser de la mémoire et du CPU, et soulager la base de données du travail.
- Chargement beaucoup plus rapide de votre site Web, améliorant ainsi l'expérience utilisateur.
Plugin WordPress
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, la date du dernier commentaire sur la publication et 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
以上是使用 ETag 進行 Web 最佳化：WordPress 範例的詳細內容。更多資訊請關注PHP中文網其他相關文章！
