ホームページ  >  記事  >  バックエンド開発  >  ETag を使用した Web の最適化。 WordPress の例

ETag を使用した Web の最適化。 WordPress の例

WBOY
WBOYオリジナル
2024-09-09 16:30:41538ブラウズ

使用 ETag 進行網頁最佳化。 WordPress 範例

這篇文章最初發表於 2014 年,2019 年發表在《Web Optimization with ETags》。 WordPress 範例

Optimización web con ETags. Ejemplo con WordPress

我有一段時間沒有寫關於最佳化的文章了。你已經知道你認識我了,為什麼會這樣。但是,我不能讓所謂的WPO小販阻止我寫一些我喜歡的東西。所以,這裡有一個新帖子。

我確信這件事發生在你身上。有一天,您到達工作場所,打開計算機,打開電子郵件,查看後打開終端並輸入: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 ヘッダーは同じ基準に基づいています)、最適ではありません (役に立たない情報がリクエストに追加されるため)。この場合、ファイルで ETag を使用しないように Web サーバーを構成することをお勧めします。たとえば、Apache のファイル ETag (または FileETags) を無効にするには、次のコードを tú.htacess に追加します。 FileETag None

ETag を使用したブラウザーとサーバー間のダイアログは、最終変更日について確認したものと同じであり、両方の形式を使用するのは最適ではなく冗長であるのではないかと疑問に思われていることと思います。 ETag を使用する理由

ファイルへの HTTP リクエストには変更日で十分ですが、Web ページ (HTML) への HTTP リクエストでは不十分です。 Web ページは、単一のファイルではなく、相互に関連する多くの要素/要素 (コンテンツ、コメント、HTML 構造など) に依存します。したがって、これらすべての要素の統一された最終変更日を見つけることは非常に困難です。私の言っていることは理解するのが難しいと思います。別の方法で説明してみます:

このエントリの Web ページ (HTML) の変更日として、エントリのテキストの変更日を割り当てると想像してください。入力すると、ブラウザはこのページを投稿の最終更新日とともにキャッシュします。 1 分後に再度ログインすると、投稿は変更されていないため (したがって、その更新日も)、ブラウザはキャッシュされたバージョンの使用に戻ります。誰かが私にコメントを書いて、あなたが戻ってきたとしても、そのコメントは表示されません。投稿のテキストは変更されていないため、最終更新日も変更されていないため、ブラウザにはキャッシュからのバージョンが再度表示されます。 HTMLを変更して新しいCSSを追加した場合も同じことが起こります。投稿の内容や日付は変更されておらず、ブラウザには引き続きキャッシュ バージョンが表示されます。

投稿の最終変更日を扱う代わりに、投稿の Web ページに次の形式の ETag を割り当てます: {fecha_modificacion_contenido_post}_{date_last_commentario_post}_{number_version_del_tema_WP}

ブラウザが初めて投稿にアクセスすると、関連する ETag をメタデータとして含む Web ページ (HTML) がキャッシュされます。いずれかのトークン基準 (変更後の日付、最終コメントの日付、または現在の WP テーマのバージョン) を変更した場合、Web ページに関連付けられた ETag は異なります。そのため、投稿を再度入力すると、サーバーはブラウザの ETag が最新ではないことを通知し、Web ページ全体と新しい ETag を再度送信します。

何も変更されていない場合、トークン/ETag は (ブラウザーとサーバーの両方で) 同じになるため、ブラウザーでページにアクセスすると、サーバーは何も変更されていないことを知らせる 304 を送信します。変更されたため (WPO の用語ではまだ新しいと言われます)、キャッシュのバージョンを使用します。

Etag のメリット

これまで述べてこなかったのは、ETag の利点です。以下にその一部を示します:

  • サーバー/ブラウザ間で転送されるデータが少なくなります。これは、Web サイトのユーザーとサーバーのコストがそれほどかからないよう、ユーザーのデータを保存することを意味します (転送データ量の支払いに基づいてホスティングを契約している場合は重要です)。
  • サーバーは HTML を生成する必要がなくなり、メモリと CPU が節約され、作業データベースが解放されます。
  • Web サイトの読み込みが大幅に高速化され、ユーザー エクスペリエンスが向上します。

WordPress プラグイン

これまで見てきたものはすべて高レベルであり、WordPress ページ/投稿に ETag を使用する小さなプラグインを見ていきます。

# 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;
}

まず最初に、このプラグインはトレーニングのみであると言ってください。 CSS/JS リソースの縮小/統合やサーバー側キャッシュの使用など、他の Web 最適化手法と同様に、最初にサイトを調査する必要があります。

ご覧のとおり、これ以上に簡単なことはありません。まず、ブラウザの ETag があれば取​​得します (20 行目)。次に、現在の投稿/ページに関連付けられた Etag が取得されます (21 行目)。

両方が同じ場合、304 コードがブラウザに送信され (24 行目、これはこの投稿のメイン画像に示されているケースです)、実行は終了します。ブラウザはコード 304 を受け取り、キャッシュ内のページのバージョンを使用する必要があることを認識します。

Etag が異なる場合 (ブラウザーが初めてアクセスしたため、またはトークンが変更されたため)、ETag がブラウザーに送信され、WP はそのコース (現在の投稿のコンテンツを送信する) を続行できます。 /ページ ).

Etag は、投稿/ページが最後に変更された時刻、投稿に対する最後のコメントの日付、および現在のトピックのバージョンに基づいて、get_current_ETag 関数 (行 31 ~ 38) で生成されます。これらのパラメーターのいずれかが変更されると、トークンが変更され、ブラウザーに Web サイトの新しいバージョンのダウンロードが強制されます。

これですべてです。気に入っていただければ幸いです。ウェブサイトの高速化に役立ちます。


シェアしてください

以上がETag を使用した Web の最適化。 WordPress の例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。