Web Optimization with ETags: An Example with WordPress-PHP Tutorial-php.cn

English version of my old post Optimización web con ETags. Ejemplo con WordPress

Web Optimization with ETags: An Example with WordPress

It's been a while since I last wrote about optimization. Those who know me are aware of why that happened. However, I can't let so-called WPO (Web Performance Optimization) experts stop me from writing about something I enjoy. So, here's a new post for you.

I'm sure this has happened to you. You arrive at your workplace, turn on your computer, open your email, and after checking it, open a terminal and type: git pull. The terminal quickly responds: Already up-to-date..

Have you ever wondered what happens behind that git pull? I have. If I had to guess, I'd say that when you do a git pull, you're transparently sending the server the date of the last change you have. The repository checks the date of the last change you send against the date of the last change it has, so:

If your date is older, it sends you all the pushes/changes that have occurred since then. It will also send you, along with those changes, the date they were made. So, if you typed git pull again, you would send the date of the last of those changes, and everything would start again.
If your date matches the date the repository has for the last change, it will tell you that everything is up-to-date.

This process, which seemed the most logical to me, is not the real one. The real one is similar but not exact. Every time a push is made, the repository associates a token (an alphanumeric identification code, something like ae3d9735f280381d0d97d3cdb26066eb16f765a5) with the latest commit. When you do a git pull, it compares the last token you have with the list of tokens it has. If your token is an old one, it sends the changes since then with their corresponding tokens. If the token was the latest, it tells you you're up-to-date.

At this point, you might say: Manuel, wasn't this post supposed to be about optimizing websites with WordPress? Indeed, it is. Both the first case presented (the one with the date) and the second one (the one with the token) are ways of working in the HTTP protocol. Let's take a closer look.

Last-Modified

Imagine your browser sends a request to my server to download the favicon of my website. In the response from my server to your browser, there will be a string (or HTTP header): Last-Modified: Thu, 29 Dec 2016 11:55:29 GMT. This tells your browser when the favicon was last modified. So, once your browser downloads the image, it will store it in its cache with the metadata "Last-Modified" and the value Thu, 29 Dec 2016 11:55:29 GMT.

If, after a few seconds, days, or months, you decide to visit my website again, your browser will need the favicon from my site again. However, it remembers it also has a copy of the image in its cache. How does it know if the favicon in its cache is the latest or if it needs to download it again? Simple, it performs a "git pull." That is, the browser sends a new request for the favicon to my server, indicating that it has a version of the image from a specific date. There are two possible responses from my server:

The current favicon on my website is newer, so my server will send the new image to your browser, along with the new last-modified date of this image.
The current favicon on my website matches the date indicated by your browser. That is, both the server's image and the browser's cached image are the same. Then, my server informs your browser that the image has not been modified (with the HTTP 304 Not Modified code). Your browser then uses the cached image, saving itself from having to download the image again (thus saving many bytes of your data plan).

ETags

If you remember, at the beginning of the post, I mentioned that Git uses tokens to determine when changes were made. HTTP, in addition to the last modified date, allows working with tokens called ETags (Entity Tags). An ETag is an alphanumeric code (such as 5864f9b1-47e) with no predetermined format (the HTTP standard does not specify, or barely specifies, what format the token should have). The site owner determines the format.

By default, web servers like Apache create the ETag for each file based on its modification date (and sometimes also the file size). This is redundant (the HTTP header for the last modified date is based on the same criteria) and not optimal (because it adds more information to requests that is of no use). In this case, it's advisable to configure your web server not to use ETags for files. For example, to disable file ETags (or FileETags) in Apache, add the following code to your .htaccess file: FileETag None.

Sie fragen sich vielleicht, ob der Dialog zwischen dem Browser/Server, der einen ETag verwendet, derselbe ist, den wir für das Datum der letzten Änderung gesehen haben, und ob die Verwendung beider Methoden ineffizient und redundant ist. Warum dann ETags verwenden?

Das Datum der letzten Änderung reicht für HTTP-Anfragen für Dateien aus, reicht jedoch für HTTP-Anfragen für Webseiten (HTML) nicht aus. Eine Webseite hängt von vielen miteinander verbundenen Faktoren/Elementen (Inhalt, Kommentare, HTML-Struktur usw.) ab und nicht nur von einer einzelnen Datei. Daher wäre es sehr kompliziert, für alle diese Elemente ein einheitliches Datum der letzten Änderung zu finden. Ich weiß, dass es schwierig sein könnte, dem zu folgen, deshalb versuche ich es anders zu erklären:

Stellen Sie sich vor, ich ordne das Änderungsdatum dieser Webseite (HTML) dem Änderungsdatum des Beitragstextes zu. Wenn Ihr Browser die Seite besucht, speichert er die Seite zusammen mit dem Datum der letzten Änderung des Beitrags im Cache. Wenn Sie den Beitrag eine Minute später erneut aufrufen, verwendet Ihr Browser die zwischengespeicherte Version, da sich der Beitrag nicht geändert hat (und sich somit auch sein Änderungsdatum nicht geändert hat). Wenn jemand einen Kommentar schreibt und Sie ihn erneut besuchen, wird Ihnen der Kommentar nicht angezeigt. Da sich der Text des Beitrags nicht geändert hat, hat sich auch das Änderungsdatum nicht geändert, sodass Ihr Browser Ihnen erneut die zwischengespeicherte Version anzeigen würde. Das Gleiche würde passieren, wenn ich den HTML-Code ändere und eine neue CSS-Datei hinzufüge. Der Inhalt des Beitrags hat sich nicht geändert, ebenso wenig wie das Datum, daher würde Ihr Browser immer noch die zwischengespeicherte Version anzeigen.

Wenn wir, anstatt mit dem Datum der letzten Änderung für den Beitrag zu arbeiten, der Webseite des Beitrags einen ETag mit dem folgenden Format zuweisen: {post_content_modification_date}_{post_last_comment_date}_{WP_theme_version_number}

Wenn Ihr Browser den Beitrag zum ersten Mal besucht, speichert er die Webseite (HTML) mit dem zugehörigen ETag als Metadaten zwischen. Wenn sich eines der Token-Kriterien ändert (das Änderungsdatum des Beitrags, das Datum des letzten Kommentars oder die aktuelle WP-Theme-Version), würde der mit der Webseite verknüpfte ETag anders sein. Wenn Sie den Beitrag also erneut besuchen, benachrichtigt Sie mein Server, dass der ETag Ihres Browsers nicht der neueste ist, und sendet die gesamte Webseite zusammen mit dem neuen ETag erneut.

Wenn sich nichts geändert hat, wäre das Token/ETag dasselbe (sowohl im Browser als auch auf dem Server). Wenn Sie also die Seite mit Ihrem Browser besuchen, würde mein Server eine 304-Antwort senden und ihn darüber informieren, dass sich nichts geändert hat (in WPO-Begriffen ist es noch „frisch“) und dass es die zwischengespeicherte Version verwenden sollte.

Vorteile von ETags

Etwas, das ich bisher noch nicht erwähnt habe, sind die Vorteile von ETags. Hier sind einige:

Weniger Daten werden zwischen dem Server und dem Browser übertragen. Dies bedeutet Dateneinsparungen für den Benutzer (damit Ihre Website für Ihre Benutzer kostengünstiger ist „Wie viel kostet der Besuch Ihrer Website?“) und auch für den Server (wichtig, wenn Sie ein Hosting-Paket haben, das auf Datenübertragung basiert).
Der Server erspart Ihnen den Aufwand für die HTML-Generierung, mit allem, was dazu gehört: Speicher und CPU sparen und die Datenbank entlasten.
Viel schnelleres Laden Ihrer Website, was das Benutzererlebnis verbessert.

WordPress-Plugin

Alles, was wir behandelt haben, ist auf hohem Niveau, also schauen wir uns ein kleines Plugin an, das ETags für WordPress-Seiten/-Beiträge verwendet.

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

Copy after login

Zunächst möchte ich erwähnen, dass dieses Plugin nur zu Bildungszwecken dient. Wie bei jeder Weboptimierungstechnik, wie etwa der Minimierung/Kombination von CSS/JS-Ressourcen oder der Verwendung von serverseitigem Caching, ist zunächst eine Site-Studie erforderlich.

Wie Sie sehen, einfacher geht es nicht. Zunächst wird der ETag vom Browser abgerufen, sofern vorhanden (Zeile 20). Zweitens wird der mit dem aktuellen Beitrag/der aktuellen Seite verknüpfte ETag abgerufen (Zeile 21).

Wenn beide identisch sind, wird ein 304-Code an den Browser gesendet (Zeile 24, was im Hauptbild dieses Beitrags der Fall ist) und die Ausführung endet. Der Browser erhält den 304-Code und weiß, dass er die zwischengespeicherte Version der Seite verwenden soll.

Wenn die ETags unterschiedlich sind (entweder weil der Browser zum ersten Mal zugreift oder weil sich das Token geändert hat), wird das ETag an den Browser gesendet und WordPress darf seinen Prozess fortsetzen (Senden des Inhalts des aktuellen Beitrag/Seite).

Der ETag wird in der Funktion get_current_ETag (Zeilen 31 bis 38) basierend auf dem letzten Zeitpunkt der letzten Änderung des Beitrags/der Seite, dem Datum des letzten Kommentars zum Beitrag und der Version des aktuellen Themes generiert. Wenn sich einer dieser Parameter ändert, ändert sich auch das Token, wodurch der Browser gezwungen wird, die neue Version der Website herunterzuladen.

Das ist alles. Ich hoffe, Ihnen hat dieser Beitrag gefallen und er hilft Ihnen, Ihre Website schneller zu machen.

Teilen Sie es bitte

The above is the detailed content of Web Optimization with ETags: An Example with WordPress. For more information, please follow other related articles on the PHP Chinese website!