Heute ist es für viele Menschen eine häufige Bedingung, online zu sein. Wir alle kaufen, kommunizieren, lesen Artikel und suchen nach Informationen zu verschiedenen Themen. Das Netzwerk verbindet uns mit der ganzen Welt, aber vor allem verbindet es Menschen. Ich benutze das Internet seit 20 Jahren selbst und meine Beziehung dazu hat sich vor acht Jahren geändert, als ich Webentwickler wurde.
Entwickler verbinden Menschen.
Entwickler helfen Menschen.
Entwickler geben Menschen Möglichkeiten.
Entwickler können ein Netzwerk für alle erstellen, diese Fähigkeit muss jedoch verantwortungsbewusst eingesetzt werden. Am Ende ist es wichtig, Dinge zu schaffen, die Menschen helfen und sie befähigen. In diesem Artikel möchte ich darüber sprechen, wie Sie mithilfe von HTTP-Headern bessere Produkte für die beste Arbeit aller Benutzer im Internet erstellen können.
HTTP - Hypertext Transfer Protocol
Lassen Sie uns zuerst über HTTP sprechen. HTTP ist ein Protokoll, mit dem Computer Daten über das Internet anfordern und senden.
Wenn der Browser eine Ressource vom Server anfordert, verwendet er HTTP. Diese Anforderung enthält eine Reihe von Schlüssel-Wert-Paaren, die Informationen wie die Browserversion oder die von ihr verstandenen Dateiformate enthalten. Diese Paare werden Anforderungsheader genannt.
Der Server antwortet mit der angeforderten Ressource, sendet jedoch auch Antwortheader mit Informationen zur Ressource oder zum Server selbst.
Request: GET https://the-responsible.dev/ Accept: text/html,application/xhtml+xml,application/xml Accept-Encoding: gzip, deflate, br Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,de;q=0.7 ... Response: Connection: keep-alive Content-Type: text/html; charset=utf-8 Date: Mon, 11 Mar 2019 12:59:38 GMT ... Response Body
Heute ist HTTP die Grundlage des Internets und bietet viele Möglichkeiten zur Optimierung der Benutzererfahrung. Lassen Sie uns sehen, wie Sie mithilfe von HTTP-Headern ein sicheres und zugängliches Netzwerk erstellen können.
Das Netzwerk muss sicher sein
Ich habe mich nie in Gefahr gefühlt, als ich im Internet nach etwas gesucht habe. Aber je mehr ich über das World Wide Web erfuhr, desto mehr machte ich mir Sorgen. Sie können lesen, wie
Hacker globale CDN-Bibliotheken ändern ,
zufällige Websites die Kryptowährung im Browser ihrer Besucher abbauen und wie
Menschen durch Social Engineering regelmäßig Zugriff auf erfolgreiche Open Source-Projekte erhalten . Das ist nicht gut. Aber warum sollte es dich interessieren?
Wenn Sie heute für das Web entwickeln, schreiben Sie nicht nur Code. In der Webentwicklung arbeiten heute viele Leute an einer Site. Sie können auch viel Open Source verwenden. Darüber hinaus können Sie zu Marketingzwecken mehrere Skripte von Drittanbietern einfügen. Hunderte von Menschen stellen Code bereit, der auf Ihrer Website ausgeführt wird. Und Entwickler müssen in solchen Realitäten arbeiten.
Können all diesen Personen und dem gesamten Quellcode vertraut werden?
Ich denke nicht, dass einem Code von Drittanbietern vertraut werden sollte. Glücklicherweise gibt es Möglichkeiten, Ihre Website zu schützen und sicherer zu machen. Darüber hinaus können Werkzeuge wie der
Helm beispielsweise für Expressanwendungen nützlich sein .
Wenn Sie analysieren möchten, wie viel Code von Drittanbietern auf Ihrer Site ausgeführt wird, können Sie im Entwicklerfenster nachsehen oder den Map Generator anfordern.HTTPS und HSTS - Stellen Sie sicher, dass Ihre Verbindung sicher ist
Eine sichere Verbindung ist die Grundlage für ein sicheres Internet. Ohne verschlüsselte Anforderungen,
die über HTTPS gesendet werden , können Sie nicht sicher sein, dass sich zwischen Ihrer Website und den Besuchern niemand anderes befindet. Eine Person kann schnell ein öffentliches Wi-Fi-Netzwerk einrichten und
einen Mann mitten im Angriff auf jeden
starten , der eine
Verbindung zu diesem Netzwerk herstellt . Wie oft nutzen Sie öffentliches WLAN? Wie oft überprüfen Sie auch, ob es vertrauenswürdig ist?
Glücklicherweise sind
TLS-Zertifikate heute kostenlos . HTTPS ist zum Standard geworden, und Browser bieten erweiterte Funktionen nur für sichere Verbindungen und markieren sogar Nicht-HTTPS-Websites als unsicher, was die Implementierung dieses Protokolls erleichtert. Leider sind wir im Internet nicht immer sicher. Wenn jemand eine Site öffnen möchte, gibt er das Protokoll nicht in die Adressleiste ein (und warum sollte er das tun?). Dies führt zu einer unverschlüsselten HTTP-Anforderung. Sicher ausgeführte Sites leiten den Benutzer zu HTTPS um. Aber was ist, wenn jemand die erste unsichere Anfrage abfängt?
Sie können die
HSTS-Antwortheader (HTTP Strict Transport Security) verwenden, um Browsern mitzuteilen, dass Ihre Site nur über HTTPS funktioniert.
Strict-Transport-Security: max-age=1000; includeSubDomains; preload
Dieser Header teilt dem Browser mit, dass Sie keine HTTP-Anforderungen verwenden möchten, und wendet dann automatisch dieselben Anforderungen mit einer sicheren Verbindung auf dieselbe Quelle an. Wenn Sie versuchen, dieselbe URL über HTTP zu öffnen, verwendet der Browser erneut HTTPS und leitet den Benutzer weiter.
Sie können konfigurieren, wie lange diese Option aktiv bleiben soll (
max-age in Sekunden), wenn Sie HTTP später erneut verwenden möchten. Wenn Sie Subdomains aktivieren möchten, können Sie dies mit
includeSubDomains konfigurieren.
Wenn Sie alles Mögliche tun möchten, damit der Browser Ihre Site niemals über HTTP anfordert, können Sie auch den
preload Zeiger setzen und
Ihre Site an die globale Liste
senden . Wenn die HSTS-Konfiguration Ihrer Site dem Mindestalter von einem Jahr entspricht und für Subdomains aktiv ist, kann sie in die interne Browserliste für Sites aufgenommen werden, die nur über HTTPS funktionieren.
Haben Sie sich jemals gefragt, warum Sie lokale Umgebungsvariablen wie
my-site.dev nicht mehr über HTTP in Ihrem Browser verwenden können? Der Grund liegt genau in dieser internen Liste -
.dev automatisch in diese Liste aufgenommen, da es im Februar 2019 zu einer echten Top-Level-Domain wurde.
Der HSTS-Header macht Ihre Site nicht nur ein wenig sicherer, sondern beschleunigt auch die Arbeit. Stellen Sie sich vor, jemand greift auf eine langsame mobile Verbindung zu. Wenn die erste Anforderung über HTTP nur zum Empfang einer Umleitung gestellt wurde, wird dem Benutzer möglicherweise mehrere Sekunden lang nichts auf dem Bildschirm angezeigt. Mit HSTS können Sie diese Sekunden speichern, und der Browser verwendet automatisch HTTPS.
CSP - Geben Sie deutlich an, was auf Ihrer Website zulässig ist
Jetzt, da Ihre Site über eine sichere Verbindung ausgeführt wird, kann es zu Problemen kommen, wenn Browser Anfragen blockieren, die aufgrund von Richtlinien für gemischte Inhalte eine unsichere Adresse erreichen. Der
CSP- Header
(Content Security Policy) bietet eine hervorragende Möglichkeit, mit diesen Situationen umzugehen. Sie können Ihren CSP-Regelsatz mithilfe von Metaelementen im bereitgestellten HTML-Code oder über HTTP-Header festlegen.
Content-Security-Policy: upgrade-insecure-requests
Der
upgrade-insecure-requests Zeiger für
upgrade-insecure-requests bewirkt, dass der Browser alle HTTP-Anforderungen auf magische Weise in HTTPS-Anforderungen konvertiert.
CSP ist jedoch nicht auf das verwendete Protokoll beschränkt. Es bietet detaillierte Möglichkeiten, um festzustellen, welche Ressourcen und Aktivitäten auf Ihrer Website zulässig sind. Sie können beispielsweise angeben, welche Skripte ausgeführt werden sollen oder von wo Bilder heruntergeladen werden sollen. Wenn etwas nicht zulässig ist, blockiert der Browser diese Aktion und verhindert mögliche Angriffe auf Ihre Website.
Zum Zeitpunkt des Schreibens gab es 24 verschiedene Konfigurationsoptionen für CSP. Sie reichen von Skripten über Stylesheets bis hin zu Servicemitarbeitern.
Die vollständige Rezension finden Sie auf MDN.Mit CSP können Sie festlegen, was Ihre Site enthalten soll und was nicht.
Content-Security-Policy: default-src 'self'; script-src 'self' just-comments.com www.google-analytics.com production-assets.codepen.io storage.googleapis.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: images.contentful.com images.ctfassets.net www.gravatar.com www.google-analytics.com just-comments.com; font-src 'self' data:; connect-src 'self' cdn.contentful.com images.contentful.com videos.contentful.com images.ctfassets.net videos.ctfassets.net service.just-comments.com www.google-analytics.com; media-src 'self' videos.contentful.com videos.ctfassets.net; object-src 'self'; frame-src codepen.io; frame-ancestors 'self'; worker-src 'self'; block-all-mixed-content; manifest-src 'self' 'self'; disown-opener; prefetch-src 'self'
Die oben genannten Regeln gelten für meine persönliche Website. Wenn Sie der Meinung sind, dass dieses Beispiel für die CSP-Definition sehr kompliziert ist, haben Sie absolut Recht. Ich habe dieses Kit bei meinem dritten Versuch implementiert und es erneut bereitgestellt und zurückgesetzt, da es die Site mehrmals beschädigt hat. Aber es gibt einen besseren Weg.
Um ein Hacken Ihrer Website zu vermeiden, bietet CSP auch einen Nur-Berichterstellungsmodus.
Content-Security-Policy-Report-Only: default-src 'self'; ... report-uri https://stefanjudis.report-uri.com/r/d/csp/reportOnly
Im Modus "
Content-Security-Policy-Report-Only zeichnen Browser einfach Ressourcen auf, die blockiert würden, anstatt sie tatsächlich zu blockieren. Mit diesem Berichtsmechanismus können Sie Ihren Regelsatz überprüfen und konfigurieren.
Beide Header,
Content-Security-Policy und
Content-Security-Policy-Report-Only , bieten auch eine Möglichkeit, den Endpunkt für das Senden eines Verstoßberichts und der Protokollierungsinformationen (
report-uri ) zu bestimmen. Sie können den Protokollserver konfigurieren und die gesendeten Protokollinformationen verwenden, um die CSP-Regeln zu konfigurieren, bis sie zum Senden bereit sind.
Der empfohlene Prozess lautet wie folgt: Führen Sie CSP zuerst im Berichtsmodus aus, analysieren Sie eingehende Verstöße mit echtem Datenverkehr und aktivieren Sie es, wenn keine Verstöße gegen Ihre kontrollierten Ressourcen festgestellt werden.
Wenn Sie nach einem Service suchen, der Ihnen beim Umgang mit diesen Magazinen helfen kann, empfehle ich die Berichts-URI , die mir sehr hilft.Allgemeine Implementierung von CSP
Heutzutage unterstützen Browser CSP
gut , aber leider verwenden es nicht viele Websites. Um zu sehen, wie viele Websites Inhalte mithilfe von CSP
bereitstellen , habe ich eine Anfrage an
HTTParchive gesendet und festgestellt, dass nur 6% der angezeigten Websites diese Richtlinie verwenden. Ich denke, wir können das Internet sicherer machen und unsere
Benutzer vor dem
unbeabsichtigten Abbau von Kryptowährungen schützen.
Das Netzwerk muss zugänglich sein.
Während ich diesen Artikel schreibe, sitze ich mit einer schnellen WLAN-Verbindung zu Hause vor dem relativ neuen MacBook. Entwickler vergessen oft, dass diese Situation für die meisten unserer Benutzer nicht Standard ist. Besucher unserer Websites verwenden alte Telefone und zweifelhafte Verbindungen. Schwere und überlastete Websites mit Hunderten von Anfragen hinterlassen einen schlechten Eindruck.
Und es geht nicht nur um den Eindruck.
Die Menschen zahlen je nach Wohnort unterschiedliche Beträge für den Verkehr . Stellen Sie sich vor, Sie erstellen eine Website für ein Krankenhaus. Die Informationen darüber können entscheidend sein und Leben retten. Wenn die Seite auf der Website des Krankenhauses 5 MB groß ist, funktioniert sie nicht nur langsam, sondern ist möglicherweise zu teuer für diejenigen, die sie am dringendsten benötigen. Der Preis von fünf Megabyte Verkehr in Europa oder den Vereinigten Staaten ist im Vergleich zum Preis in Afrika vernachlässigbar. Entwickler sind dafür verantwortlich, Webseiten für alle zugänglich zu machen. Diese Verantwortung umfasst die Bereitstellung der richtigen Ressourcen, die Auswahl der richtigen Tools (benötigen Sie wirklich ein JS-Framework für die Landung?) Und die Vermeidung von Anfragen.
Cache-Kontrolle - Vermeiden Sie Anfragen nach unveränderlichen Ressourcen
Heutzutage kann eine Site Hunderte von Ressourcen enthalten, von CSS bis zu Skripten und Bildern.
Cache-Control können Entwickler festlegen, wie lange die Ressource als "frisch" betrachtet und aus dem Browser-Cache zurückgegeben werden soll.
Cache-Control: max-age=30, public
Bei richtiger Konfiguration von
Cache-Control bleibt die Datenübertragung erhalten und Dateien können für eine bestimmte Anzahl von Sekunden (
max-age ) aus dem Browser-Cache verwendet werden. Browser müssen zwischengespeicherte Ressourcen nach diesem Zeitraum erneut überprüfen.
Wenn Besucher die Seite jedoch
aktualisieren, überprüfen die Browser sie trotzdem erneut, einschließlich Links zu Ressourcen, um sicherzustellen, dass die zwischengespeicherten Daten weiterhin gültig sind. Die Server antworten mit einem Header 304, der signalisiert, dass die zwischengespeicherten Daten noch gültig sind, oder einem Header 200, wenn aktualisierte Daten übertragen werden. Auf diese Weise können Sie die übertragenen Daten speichern, aber nicht unbedingt Anfragen stellen.
Hier kommt die
immutable Funktion ins Spiel.
Unveränderlich - fordern Sie niemals zweimal eine Ressource an
In modernen Frontend-Anwendungen haben CSS- und Skriptdateien normalerweise eindeutige Namen, z. B.
styles.123abc.css . Der Name dieser Datei hängt vom Inhalt ab. Und wenn Sie den Inhalt von Dateien ändern, ändern sich auch deren Namen.
Diese eindeutigen Dateien können möglicherweise für immer zwischengespeichert werden, auch wenn ein Benutzer eine Seite aktualisiert.
immutable kann verhindern, dass der Browser die Ressource in einem bestimmten Zeitintervall erneut überprüft. Dies ist sehr wichtig für Objekte mit Prüfsummen und hilft, wiederholte Validierungsanforderungen zu vermeiden.
Cache-Control: max-age=31536000, public, immutable
Das Implementieren eines optimalen Cachings ist sehr schwierig, und insbesondere das Browser-Caching ist nicht sehr intuitiv, da es verschiedene Konfigurationen aufweist. Ich empfehle Ihnen, die folgenden Materialien zu lesen:
Accept-Encoding - maximale Komprimierung (auf ein Minimum)
Mithilfe der
Cache control wir Anforderungen speichern und die Datenmenge reduzieren, die wiederholt über das Netzwerk übertragen wird. Wir können nicht nur Anfragen speichern, sondern auch reduzieren, was übertragen wird.
Entwickler sollten Ressourcen bereitstellen und darauf achten, so wenig Daten wie möglich zu senden. Bei Textressourcen wie HTML, CSS und JavaScript spielt die Komprimierung eine wichtige Rolle beim Speichern übertragener Daten.
Die heute beliebteste Komprimierungsmethode ist GZIP. Server verfügen über genügend Leistung, um Textdateien im laufenden Betrieb zu komprimieren und auf Anfrage komprimierte Daten bereitzustellen. Aber GZIP ist nicht mehr die beste Option.
Wenn Sie sich die vom Browser generierten Anforderungen für Textdateien wie HTML, CSS und JavaScript ansehen und die Header analysieren, finden Sie unter ihnen eine
accept-encoding .
Accept-Encoding: gzip, deflate, br
Dieser Header teilt dem Server mit, welche Komprimierungsalgorithmen er versteht. Der wenig bekannte
br Parameter steht für
Brotli-Komprimierung und wird auf stark frequentierten Websites wie Google und Facebook verwendet. Um Brotli nutzen zu können, muss Ihre Site über HTTPS funktionieren.
Dieser Komprimierungsalgorithmus wurde unter Berücksichtigung der geringen Dateigröße erstellt. Wenn Sie versuchen, die Datei manuell auf Ihrem lokalen Gerät zu komprimieren, werden Sie feststellen, dass Brotli wirklich besser komprimiert als GZIP.
Sie haben vielleicht gehört, dass die Brotli-Komprimierung langsamer ist. Der Grund dafür ist, dass Brotli über 11 Komprimierungsmodi verfügt und standardmäßig derjenige ausgewählt wird, der die kleinsten Dateien auswählt, wodurch die Prozedur verlängert wird. GZIP hingegen verfügt über 9 Modi. Standardmäßig ist einer ausgewählt, der sowohl die Komprimierungsgeschwindigkeit als auch die Dateigröße berücksichtigt. Daher ist der Brotli-Modus standardmäßig nicht für die direkte Komprimierung geeignet. Wenn Sie jedoch den Modus ändern, können Sie kleine Dateien mit der gleichen Geschwindigkeit wie GZIP komprimieren. Sie können es für die direkte Komprimierung verwenden und es als potenziellen Ersatz für GZIP zur Unterstützung von Browsern betrachten.
Wenn Sie Dateien so weit wie möglich speichern möchten, können Sie außerdem die dynamische Komprimierung vergessen und
optimierte GZIP-Dateien mit zopfli- und Brotli-
Dateien für die statische Wartung vorab generieren.
Wenn Sie mehr über die Brotli-Komprimierung und ihren Vergleich mit GZIP erfahren möchten, haben die Mitarbeiter von Akamai umfangreiche Untersuchungen zu diesem Thema durchgeführt .
Accept and Accept-CH - Bereitstellung individueller Ressourcen für den Benutzer
Die Optimierung von Textressourcen ist sehr wichtig, um Kilobyte zu sparen. Wie steht es jedoch mit schwereren Ressourcen wie Bildern, um noch mehr Daten zu speichern?
Akzeptieren - Bilder im richtigen Format warten
Browser zeigen uns nicht nur, welche Komprimierungsalgorithmen sie verstehen. Wenn der Browser ein Bild anfordert, liefert er auch Informationen darüber, welche Dateiformate er versteht.
Accept: image/webp, image/apng, image/*,*/*;q=0.8
Mehrere Jahre lang wurde um ein neues Bildformat gekämpft, aber Webp gewonnen.
Webp ist ein von Google erfundenes Bildformat , und die
Unterstützung für dieses Format ist jetzt sehr relevant.
Mit diesem Anforderungsheader können Entwickler ein
webp Bild senden, auch wenn der Browser
image.jpg angefordert
image.jpg , was zu einer kleineren Dateigröße führt. Dean Hume hat eine
gute Anleitung geschrieben, wie man dies anwendet. Sehr cool!
Accept-CH - Bilder in der richtigen Größe bereitstellen
Sie können auch
Client-Eingabeaufforderungen für Browser aktivieren, die diese Funktion unterstützen. Client-Hinweise sind eine Möglichkeit, Browser anzuweisen, zusätzliche Informationen über die Breite des Anzeigebereichs, die Breite des Bildes und sogar Netzwerkbedingungen wie RTT (Übertragungs- und Bestätigungszeit) und die Art der Verbindung zu senden, z. B.
2g .
Sie können die Hinweise aktivieren, indem Sie ein Metaelement hinzufügen:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink"> <meta http-equiv="Accept-CH-Lifetime" content="86400">
Oder indem Sie Header in der ursprünglichen HTML-Anforderung festlegen:
Accept-CH: Width, Viewport-Width Accept-CH-Lifetime: 100
Bei nachfolgenden Anforderungen senden Browser für einen bestimmten Zeitraum zusätzliche Informationen (
Accept-CH-Lifetime in Sekunden), mit denen Entwickler Bilder an Benutzerbedingungen anpassen können, ohne den HTML-Code zu ändern.
Für weitere Informationen, z. B. die Breite des Bilds auf der Serverseite, können Sie Ihren Bildern beispielsweise das
sizes hinzufügen, um dem Browser zusätzliche Informationen zum Aussehen dieser Bilder zu geben.
<!-- this images is laid over the full width | 100 viewport width --> <img class="w-100" src="/img/header.jpg" alt="" sizes="100vw">
Mit dem empfangenen
Accept-CH Antwortheader und Bildern mit dem
sizes Browser die Header für
viewport-width und
width in die Bildanforderungen auf und zeigen Ihnen, welches Bild am besten geeignet ist.
Mit einem unterstützten Format und einer unterstützten Bildgröße können Sie angepasste Daten senden, ohne unzuverlässige Bildelemente aufzeichnen zu müssen, und nur auf das Dateiformat und die Dateigröße achten, wie unten gezeigt.
<pictur> <!-- serve WebP to Chrome, Edge, Firefox and Opera --> <source media="(min-width: 50em)" sizes="50vw" srcset="/image/thing-200.webp 200w, /image/thing-400.webp 400w, /image/thing-800.webp 800w, /image/thing-1200.webp 1200w, /image/thing-1600.webp 1600w, /image/thing-2000.webp 2000w" type="image/webp"> <source sizes="(min-width: 30em) 100vw" srcset="/image/thing-crop-200.webp 200w, /image/thing-crop-400.webp 400w, /image/thing-crop-800.webp 800w, /image/thing-crop-1200.webp 1200w, /image/thing-crop-1600.webp 1600w, /image/thing-crop-2000.webp 2000w" type="image/webp"> <!-- serve JPEG to others --> <surce media="(min-width: 50em)" sizes="50vw" srcset="/image/thing-200.jpg 200w, /image/thing-400.jpg 400w, /image/thing-800.jpg 800w, /image/thing-1200.jpg 1200w, /image/thing-1600.jpg 1600w, /image/thing-2000.jpg 2000w"> <surce sizes="(min-width: 30em) 100vw" srcset="/image/thing-crop-200.jpg 200w, /image/thing-crop-400.jpg 400w, /image/thing-crop-800.jpg 800w, /image/thing-crop-1200.jpg 1200w, /image/thing-crop-1600.jpg 1600w, /image/thing-crop-2000.jpg 2000w"> <!-- fallback for browsers that don't support picture --> <img src="/image/thing.jpg" width="50%"> </pictur>
Wenn Sie Zugriff auf die Breite des Ansichtsfensters und die Bildgröße haben, können Sie die Logik der Größenänderung von Ressourcen auf Ihren Servern in den Vordergrund stellen.
Beachten Sie jedoch, dass Sie keine Bilder für eine beliebige Breite erstellen sollten, nur weil Sie die genaue Breite des Bildes haben. Das Senden von Bildern für einen bestimmten Größenbereich (
image-200 ,
image-300 ,
... ) hilft bei der Verwendung des CDN-Caching und spart Rechenzeit.
Darüber hinaus können Sie mit modernen Technologien wie Servicemitarbeitern Anforderungen direkt im Client abfangen und ändern, um die besten Bilddateien bereitzustellen. Wenn Client-Tooltips aktiviert sind, erhalten Servicemitarbeiter Zugriff auf Layoutinformationen. In Kombination mit der Image-API, z. B.
Cloudinary, können Sie die Image-URL direkt im Browser so konfigurieren, dass Bilder mit der richtigen Größe empfangen werden.
Wenn Sie detailliertere Informationen zu Kundentipps suchen, können Sie Artikel von Jeremy Wagner oder Ilya Grigorik zu diesem Thema lesen.Das Netzwerk muss vorsichtig sein
Da jeder von uns viele Stunden am Tag im Netzwerk verbringt, gibt es den letzten Aspekt, den ich für sehr wichtig halte - das Netzwerk muss vorsichtig sein.
Vorladen - Wartezeit reduzieren
Als Entwickler schätzen wir die Zeit unserer Benutzer. Niemand will Zeit verschwenden. , . , , .
: , , . , HTML . , , . .
Rel=preload , .
HTML-:
<link rel="preload" href="/font.woff2" as="font" type="font/woff2" crossorigin="anonymous">
:
Link: </font.woff2>; rel=preload; as=font; no-push
, , , , . .
:
- , .
- preload , prefetch preconnect.
Feature-Policy —
, .
.
. , . . , , — .
, , ? , ?
Feature-Policy. , , , , .
Feature-Policy: vibrate 'none'; geolocation 'none'
. , , , .
<iframe allow="camera 'none'; microphone 'none'">
Feature-Policy , , , . , . .
MDN., — push-. ,
Feature-Policy push- , . ,
GitHub.feature policy ,
, , , .
, . ,
«HTTP- — » .
, — . , , , … . , , , -, , - .