使用 ETag 进行 Web 优化：WordPress 示例

我的旧帖子 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。

Anda mungkin tertanya-tanya sama ada dialog antara penyemak imbas/pelayan menggunakan ETag adalah sama seperti yang kita lihat untuk tarikh terakhir diubah suai dan menggunakan kedua-dua kaedah adalah tidak cekap dan berlebihan. Mengapa menggunakan ETags, kemudian?

Tarikh terakhir yang diubah suai adalah mencukupi untuk permintaan HTTP untuk fail, tetapi ia adalah pendek untuk permintaan HTTP untuk halaman web (HTML). Halaman web bergantung pada banyak faktor/elemen yang saling berkaitan (kandungan, ulasan, struktur HTML, dll.) dan bukan hanya satu fail. Oleh itu, ia akan menjadi sangat rumit untuk mencari tarikh terakhir diubah suai bersatu untuk semua elemen ini. Saya tahu ini mungkin sukar untuk diikuti, jadi saya akan cuba menerangkannya secara berbeza:

Bayangkan saya menetapkan tarikh pengubahsuaian halaman web ini (HTML) kepada tarikh pengubahsuaian teks siaran. Apabila penyemak imbas anda melawat halaman, ia menyimpan cache halaman bersama-sama dengan tarikh terakhir diubah suai siaran. Jika anda melawatnya semula seminit kemudian, memandangkan siaran itu tidak berubah (dan oleh itu, tarikh pengubahsuaiannya tidak berubah), penyemak imbas anda akan menggunakan versi cache. Jika seseorang menulis ulasan dan anda melawat lagi, anda tidak akan melihat ulasan itu. Memandangkan teks siaran tidak berubah, tarikh pengubahsuaian juga tidak berubah, jadi penyemak imbas anda akan menunjukkan kepada anda versi cache sekali lagi. Perkara yang sama akan berlaku jika saya menukar HTML dan menambah fail CSS baharu. Kandungan siaran tidak berubah, mahupun tarikhnya, jadi penyemak imbas anda masih akan menunjukkan versi cache.

Jika, daripada menggunakan tarikh terakhir diubah suai untuk siaran, kami menetapkan ETag pada halaman web siaran dengan format berikut: {post_content_modification_date}_{post_last_comment_date}_{WP_theme_version_number}

Apabila penyemak imbas anda melawati siaran buat kali pertama, ia menyimpan cache halaman web (HTML) dengan ETag yang berkaitan sebagai metadata. Jika mana-mana kriteria token berubah (tarikh pengubahsuaian siaran, tarikh ulasan terakhir atau versi tema WP semasa), ETag yang dikaitkan dengan halaman web akan berbeza. Jadi, jika anda melawati siaran itu sekali lagi, pelayan saya akan memberitahu anda bahawa ETag penyemak imbas anda bukanlah yang terkini, dan ia akan menghantar semula keseluruhan halaman web bersama-sama dengan ETag baharu.

Jika tiada apa-apa yang berubah, token/ETag akan sama (dalam kedua-dua penyemak imbas dan pelayan), jadi apabila anda melawati halaman dengan penyemak imbas anda, pelayan saya akan menghantar respons 304, memberitahunya bahawa tiada apa yang berubah (dalam istilah WPO, ia masih "segar") dan ia harus menggunakan versi cache.

Faedah ETags

Sesuatu yang saya tidak nyatakan sehingga kini adalah kebaikan ETags. Berikut adalah beberapa:

• Kurang data yang dipindahkan antara pelayan dan penyemak imbas. Ini bermakna penjimatan data untuk pengguna (jadi tapak web anda lebih murah untuk pengguna anda "Berapa kos untuk melawat tapak web anda?") dan juga untuk pelayan (penting jika anda mempunyai pelan pengehosan berasaskan pemindahan data).
• Pelayan menjimatkan usaha menjana HTML, dengan semua yang membayangkan: menjimatkan memori dan CPU, dan melegakan pangkalan data kerja.
• Pemuatan tapak web anda dengan lebih pantas, meningkatkan pengalaman pengguna.

Pemalam WordPress

Semua yang telah kami bincangkan adalah pada tahap yang tinggi, jadi mari lihat pemalam kecil yang menggunakan ETags untuk halaman/siaran 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;
}

Pertama sekali, izinkan saya menyatakan bahawa pemalam ini adalah untuk tujuan pendidikan sahaja. Seperti mana-mana teknik pengoptimuman web, seperti pengurangan/gabungan sumber CSS/JS atau menggunakan caching sebelah pelayan, kajian tapak diperlukan terlebih dahulu.

Seperti yang anda lihat, ia tidak boleh menjadi lebih mudah. Pertama, ETag dari pelayar diperolehi, jika ada (baris 20). Kedua, ETag yang dikaitkan dengan siaran/halaman semasa diambil (baris 21).

Jika kedua-duanya adalah sama, kod 304 dihantar ke penyemak imbas (baris 24, iaitu kes yang ditunjukkan dalam imej utama siaran ini), dan pelaksanaan tamat. Penyemak imbas akan menerima kod 304 dan akan mengetahui bahawa ia harus menggunakan versi cache halaman.

Jika ETag berbeza (sama ada kerana penyemak imbas melawati buat kali pertama atau kerana token telah berubah), ETag dihantar ke penyemak imbas dan WordPress dibenarkan meneruskan prosesnya (menghantar kandungan semasa siaran/halaman).

ETag dijana dalam fungsi get_current_ETag (baris 31 hingga 38) berdasarkan kali terakhir siaran/halaman diubah suai, tarikh ulasan terakhir pada siaran dan versi tema semasa. Jika mana-mana parameter ini berubah, token akan berubah, memaksa penyemak imbas memuat turun versi baharu tapak web.

Itu sahaja. Saya harap anda menikmati siaran ini dan ia membantu anda menjadikan tapak web anda lebih pantas.

Tolong kongsikannya

以上是使用 ETag 进行 Web 优化：WordPress 示例的详细内容。更多信息请关注PHP中文网其他相关文章！