Englische Version meines alten Beitrags Optimización web con ETags. Beispiel mit WordPress
Es ist schon eine Weile her, seit ich das letzte Mal über Optimierung geschrieben habe. Wer mich kennt, weiß, warum das passiert ist. Allerdings kann ich mich von sogenannten WPO-Experten (Web Performance Optimization) nicht davon abhalten lassen, über etwas zu schreiben, das mir Spaß macht. Hier ist also ein neuer Beitrag für Sie.
Ich bin sicher, dass dir das passiert ist. Sie kommen an Ihrem Arbeitsplatz an, schalten Ihren Computer ein, öffnen Ihre E-Mails, und nachdem Sie sie überprüft haben, öffnen Sie ein Terminal und geben Folgendes ein: git pull. Das Terminal antwortet schnell: Schon aktuell..
Haben Sie sich jemals gefragt, was hinter diesem Git-Pull passiert? Ich habe. Wenn ich raten müsste, würde ich sagen, dass Sie dem Server beim Ausführen eines Git-Pulls transparent das Datum der letzten Änderung senden, die Sie vorgenommen haben. Das Repository vergleicht das Datum der letzten von Ihnen gesendeten Änderung mit dem Datum der letzten Änderung, also:
Dieser Prozess, der mir am logischsten erschien, ist nicht der echte. Das Original ist ähnlich, aber nicht exakt. Jedes Mal, wenn ein Push durchgeführt wird, ordnet das Repository dem letzten Commit ein Token (einen alphanumerischen Identifikationscode, etwa ae3d9735f280381d0d97d3cdb26066eb16f765a5) zu. Wenn Sie einen Git-Pull ausführen, wird der letzte Token, den Sie haben, mit der Liste der vorhandenen Token verglichen. Wenn es sich bei Ihrem Token um einen alten handelt, werden die seitdem vorgenommenen Änderungen mit den entsprechenden Token gesendet. Wenn das Token das aktuellste war, zeigt es Ihnen an, dass Sie auf dem neuesten Stand sind.
An dieser Stelle könnte man sagen: Manuel, sollte es in diesem Beitrag nicht um die Optimierung von Websites mit WordPress gehen? Tatsächlich ist es so. Sowohl der erste dargestellte Fall (der mit dem Datum) als auch der zweite (der mit dem Token) sind Arbeitsweisen im HTTP-Protokoll. Schauen wir genauer hin.
Stellen Sie sich vor, Ihr Browser sendet eine Anfrage an meinen Server, um das Favicon meiner Website herunterzuladen. In der Antwort meines Servers an Ihren Browser wird eine Zeichenfolge (oder ein HTTP-Header) enthalten sein: Letzte Änderung: Do, 29. Dezember 2016 11:55:29 GMT. Dadurch wird Ihrem Browser mitgeteilt, wann das Favicon zuletzt geändert wurde. Sobald Ihr Browser das Bild herunterlädt, speichert er es in seinem Cache mit den Metadaten „Zuletzt geändert“ und dem Wert Do, 29 Dec 2016 11:55:29 GMT.
Wenn Sie sich nach einigen Sekunden, Tagen oder Monaten dazu entschließen, meine Website erneut zu besuchen, benötigt Ihr Browser erneut das Favicon von meiner Website. Es merkt sich jedoch, dass sich auch eine Kopie des Bildes in seinem Cache befindet. Woher weiß es, ob das Favicon in seinem Cache das neueste ist oder ob es erneut heruntergeladen werden muss? Ganz einfach: Es führt einen „Git Pull“ durch. Das heißt, der Browser sendet eine neue Anfrage für das Favicon an meinen Server und zeigt an, dass er über eine Version des Bildes von einem bestimmten Datum verfügt. Es gibt zwei mögliche Antworten von meinem Server:
Wenn Sie sich erinnern, habe ich am Anfang des Beitrags erwähnt, dass Git Token verwendet, um zu bestimmen, wann Änderungen vorgenommen wurden. HTTP ermöglicht zusätzlich zum Datum der letzten Änderung die Arbeit mit Token, die ETags (Entity Tags) genannt werden. Ein ETag ist ein alphanumerischer Code (z. B. 5864f9b1-47e) ohne vorgegebenes Format (der HTTP-Standard gibt nicht oder kaum an, welches Format das Token haben soll). Der Websitebesitzer bestimmt das Format.
Standardmäßig erstellen Webserver wie Apache den ETag für jede Datei basierend auf ihrem Änderungsdatum (und manchmal auch der Dateigröße). Dies ist redundant (der HTTP-Header für das Datum der letzten Änderung basiert auf denselben Kriterien) und nicht optimal (da es den Anfragen weitere Informationen hinzufügt, die keinen Nutzen haben). In diesem Fall empfiehlt es sich, Ihren Webserver so zu konfigurieren, dass er keine ETags für Dateien verwendet. Um beispielsweise Datei-ETags (oder FileETags) in Apache zu deaktivieren, fügen Sie den folgenden Code zu Ihrer .htaccess-Datei hinzu: FileETag None.
You might be wondering if the dialog between the browser/server using an ETag is the same as we've seen for the last-modified date and using both methods is inefficient and redundant. Why use ETags, then?
The last-modified date is sufficient for HTTP requests for files, but it falls short for HTTP requests for web pages (HTML). A web page depends on many interrelated factors/elements (content, comments, HTML structure, etc.) and not just a single file. Therefore, it would be very complicated to find a unified last modified date for all these elements. I know this might be difficult to follow, so I'll try to explain it differently:
Imagine I assign the modification date of this web page (HTML) to the modification date of the text of the post. When your browser visits the page, it caches the page along with the post's last-modified date. If you visit it again a minute later, since the post has not changed (and thus, its modification date hasn't changed), your browser will use the cached version. If someone writes a comment and you visit again, you wouldn't see the comment. Since the post's text hasn't changed, the modification date hasn't either, so your browser would show you the cached version again. The same would happen if I change the HTML and add a new CSS file. The post content hasn't changed, nor has the date, so your browser would still show the cached version.
If, instead of working with last-modified dates for the post, we assign an ETag to the web page of the post with the following format: {post_content_modification_date}_{post_last_comment_date}_{WP_theme_version_number}
When your browser visits the post for the first time, it caches the web page (HTML) with its associated ETag as metadata. If any of the token criteria change (the post's modification date, the last comment date, or the current WP theme version), the ETag associated with the web page would be different. So, if you visit the post again, my server will notify you that your browser's ETag is not the latest, and it will resend the entire web page along with the new ETag.
If nothing has changed, the token/ETag would be the same (in both the browser and the server), so when you visit the page with your browser, my server would send a 304 response, notifying it that nothing has changed (in WPO terms, it's still "fresh") and that it should use the cached version.
Something I haven't mentioned until now are the benefits of ETags. Here are a few:
Everything we've covered is at a high level, so let's look at a small plugin that uses ETags for WordPress pages/posts.
# 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;
}
First of all, let me mention that this plugin is for educational purposes only. As with any web optimization technique, such as minification/combination of CSS/JS resources or using server-side caching, a site study is required first.
As you can see, it couldn't be simpler. First, the ETag from the browser is obtained, if there is one (line 20). Second, the ETag associated with the current post/page is retrieved (line 21).
If both are the same, a 304 code is sent to the browser (line 24, which is the case shown in the main image of this post), and execution ends. The browser will receive the 304 code and will know that it should use the cached version of the page.
If the ETags are different (either because the browser is visiting for the first time or because the token has changed), the ETag is sent to the browser, and WordPress is allowed to continue its process (sending the content of the current post/page).
The ETag is generated in the function get_current_ETag (lines 31 to 38) based on the last time the post/page was modified, the date of the last comment on the post, and the version of the current theme. If any of these parameters change, the token will change, forcing the browser to download the new version of the website.
That's all. I hope you enjoyed this post and that it helps you make your website faster.
Share it, please
Das obige ist der detaillierte Inhalt vonWeboptimierung mit ETags: Ein Beispiel mit WordPress. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
Gängige Linux-Download- und Installationstools
Detaillierte Erklärung von method_exists
Verwendung des Embed-Tags
Was tun, wenn das eingebettete Bild nicht vollständig angezeigt wird?
Was sind die kostenlosen Crawler-Tools?
Der Unterschied zwischen verteilten und Microservices
Tutorial zu Datenstruktur und Algorithmus
Verwendung von „distinct' in SQL
