Das ist eine meiner Lieblingsfunktionen von Netlify. Sagen wir, Sie arbeiten an einer Website und ändern eine Asset-Datei wie CSS, JavaScript oder ein Bild. Wissen Sie, so machen wir eben unseren Job. Auf Netlify müssen Sie nicht darüber nachdenken, wie sich das auf Deployment, Browser und Cache auswirkt. Netlify erledigt das einfach für Sie.
Netlify nennt dies Instant Cache Invalidation, Teil des „Raketentreibstoffs“ von Netlify.
Bei allen Websites, an denen ich arbeite, die *nicht* auf Netlify laufen, muss ich *darüber* nachdenken (igitt). Wenn Sie sich den Quellcode dieser Website ansehen, sehen Sie einen Link zu einer Stylesheet-Datei, der ungefähr so aussieht:
<link href="https://css-tricks.de/wp-content/themes/CSS-Tricks-17/style.css?cache_bust=1594590986788" rel="stylesheet">
Sehen Sie die `?cache_bust=`-Zeichenfolge am Ende der Stylesheet-URL? Das sind einfach zufällige Zeichen, die ich manuell in diese URL eingefügt habe (basierend auf einem `Date()`-Aufruf), damit beim Hochladen einer Änderung an der Datei sowohl der CDN als auch der Browser-Cache der Benutzer unterbrochen werden und sie die neue Datei erhalten. Wenn ich das nicht täte, würden die Änderungen, die ich hochlade, erst gesehen werden, wenn der gesamte Cache abläuft oder manuell von Benutzern entfernt wird, was… schlecht ist. Ich behebe vielleicht einen Fehler! Oder veröffentliche ein neues Feature! Es ist besonders schlecht, da dieses CSS möglicherweise zusammen mit HTML ausgeliefert wird, das nicht so aggressiv gecacht wird, und dies zu einer Diskrepanz zwischen HTML und erwartetem CSS führen könnte.
Ich arbeite an einigen Websites, bei denen ich diesen Cache-Busting-String *von Hand* ändere, weil ich zu faul bin, ihn zu automatisieren. Normalerweise automatisiere ich ihn aber. Ich habe kürzlich meine Gulpfile geteilt, die ich von Hand geschrieben habe, und ein Teil davon befasst sich mit diesem Cache-Busting. Es ist Arbeit, sie zu schreiben, sie zu pflegen und sie während der Entwicklung zu verwenden. Sie können sogar die Kommentare zu diesem Beitrag lesen und die Strategien anderer Leute sehen, die dasselbe tun, aber anders als ich. Jeder macht Cache-Busting.
Nicht auf Netlify.
Nochmal, Sie ändern eine Asset-Datei, laden sie hoch, Netlify erkennt, dass sie sich geändert hat, und erledigt das gesamte Cache-Busting für Sie. So kann Ihre Stylesheet-Datei verknüpft werden:
<link href="dont-even-worry-about-it.css" rel="stylesheet" />
Großartig!
Aber irgendwie endet der Artikel unerwartet. Sie erklären nicht, WIE der Browser-Cache mit der URL in Ihrem letzten Codebeispiel gebrochen wird…
Wie funktioniert das?
Viele Grüße,
Matthias
Netlify bereinigt auch Ihren `public/dist`-Ordner vor einem neuen Build oder einer neuen Kompilierung (z. B. mit einem SSG). Normalerweise schreibt Ihr Build/Kompilierungsprozess nur Dateien, lokal müssen Sie ihn selbst bereinigen.
Eine einfache Funktion reicht aus, um dieses Problem zu umgehen.
Und die Verwendung ist auch einfach.
Sie können dasselbe für kritische Styles verwenden.
Mehr dazu, aber ich warne nur vor der polnischen Version :)
http://kody.wig.pl/javascript/pobranie-do-wordpressa-js-i-css-z-hash/
Sicher, aber das ist für mich nicht einfach. ♀️ Ich meine, in dieser Funktion sind hartcodierte Dateipfade enthalten. Das ist nichts unglaublich Schwieriges, aber es ist technische Schuld. Und es ist eine weitere Sache, die eine Datei von der Festplatte liest, was nicht leistungsneutral ist.
Deshalb muss (CSS Tricks) sich Netlify anschließen!
Das klingt einfach nach herkömmlicher ETtag-basierter Cache-Invalidierung. Sie müssen lediglich Ihren Webserver so konfigurieren, dass er die richtigen Cache-Header ausliefert, und das können Sie auch ohne Netlify (oder einen anderen Drittanbieter) tun.
Sie können das tun!
Ich… würde eine Woche damit kämpfen, bevor ich aufgeben würde ;)
Cloudflare kümmert sich ebenfalls um die ETtag-basierte Cache-Validierung!
Sendet die alte Datei, während es nach einer neuen Version sucht, um sicherzustellen, dass sie sich nicht geändert hat.
Wenn sie sich geändert hat, sendet es die aktualisierte Kopie an die nächste Person, die die Datei anfordert, wenn ich mich richtig erinnere.
Der große Haken hier ist, dass jede Ressource jedes Mal mit dem Server neu validiert werden muss, wenn Sie diese Seite besuchen. Wenn Sie fingerprinting betreiben und ein Jahr lang cachen, erhalten Sie weniger Roundtrips.
Das ist in der Tat viel einfacher für Entwicklung und Deployment, aber ein Rückschritt für die Leistung, da dieselbe Ressource (CSS, JS, Bilder usw.) beim Durchsuchen der Website mehrmals heruntergeladen wird…
Haben Sie dazu mehr Details? Ich wäre ziemlich überrascht, wenn das bedeuten würde, dass „Netlify überhaupt keine Caching betreibt“. Ich denke, es ist vielleicht ETtag-basiert, sodass ein Server-Ping erfolgen muss, um zu sehen, ob es eine neue Kopie der Datei gibt. Meinen Sie das?
Genau das. Ich habe mich gefragt, ob wir diese Netlify-Cache-Invalidierung optimieren könnten, um die Leistung zu verbessern. Zum Beispiel benenne ich ein Bild um, wenn ich eines ersetzen muss. Das ist mit Netlify nicht nötig, aber ich würde lieber die Bild-Cache-Invalidierung deaktivieren, um die Bildladeleistung zu verbessern.
Das stimmt und es funktioniert großartig. Spricht man über Caching auf dem CDN. Bei Netlify überhaupt kein Problem.
Aber was ist mit Browser-Caching? Ich stelle fest, dass ich Benutzer anweisen muss, die Seite hart zu aktualisieren, um Änderungen am statischen Anwendungs-Skript zu übernehmen.
Ich denke, ich muss genau das tun, was oben beschrieben ist, um den Endbenutzer-Cache bei einem Software-Update zu brechen, richtig?