Funktionsrichtlinien-HTTP-Header- und Webbrowser-Steuerung

Es gibt eine völlig unvergleichliche Technik, mit der Sie die Leistung eines Webprojekts unter Kontrolle halten können. Es besteht darin, Mechanismen in den Entwicklungsprozess einzuführen, deren Ergebnisse deutlich sichtbar sind. Diese Mechanismen sollen den Programmierer immer an die Bedeutung der Leistung erinnern. In diesem Zusammenhang gibt es etwas, das ich wirklich mag. Dies ist der Feature-Policy- HTTP-Header . Dieser Titel ist eine relativ neue Funktion, mit der ein Entwickler bestimmte Browserfunktionen beim Surfen auf seiner Website ein- und ausschalten kann. Sie können dem Browser beispielsweise mitteilen, dass die Verwendung der Geolocation-API nicht zulässig sein soll, indem Sie ihm den folgenden Header übergeben:







Feature-Policy: geolocation 'none'

Die Verwendung eines Headers Feature-Policybietet viele Vorteile in Bezug auf Sicherheit und Leistung. Aber ich mag jetzt besonders, wie Feature-PolicySie es verwenden können, um Probleme mit der Website-Leistung, die normalerweise leicht zu übersehen sind, deutlicher zu machen. Dies kann mit so etwas wie "Performance Flusen" verglichen werden. Insbesondere geht es darum, Probleme mit Bildern zu identifizieren, die in Webprojekten verwendet werden.

Richtlinie für übergroße Bilder


Wenn das Bild in einem von ihm unterstützten Format an den Browser übertragen wird, wird ein solches Bild angezeigt. Dies ist das Standardverhalten des Browsers. Der Browser, der versucht, denjenigen zu helfen, die die Seite anzeigen, skaliert solche Bilder ebenfalls automatisch. Daher sehen sie auch dann gut aus, wenn sie durch riesige Grafikdateien dargestellt werden. Wenn Sie Bilder verwenden, die größer sind als die von der Seite benötigten Größen, ist dies auf den ersten Blick unsichtbar.

Politik ( Richtlinie )oversized-imagesteilt dem Browser mit, dass die Verwendung von Bildern, deren Größe die Größe ihrer Container um eine bestimmte Anzahl überschreitet, nicht zulässig sein soll. Das Bild darf gemäß der Standardbeschränkung nicht mehr als das Zweifache des Containers betragen. Dieser Wert kann jedoch bei Bedarf neu definiert werden.

Wenn der Browser den nächsten Header empfängt, können Sie keine Bilder anzeigen, die aus Quellen stammen (dies wird dank festgelegt none), deren Abmessungen mehr als das Zweifache der Größe ihrer Container (in Breite oder Höhe) betragen.

Feature-Policy: oversized-images 'none';

Wenn Sie mehr Flexibilität benötigen, können Sie dem Browser mitteilen, dass keine Bilder angezeigt werden sollen, die mehr als dreimal größer als die Container sind:

Feature-Policy: oversized-images *(3) 'none';

In jedem Fall wird anstelle des Bildes ein Stub angezeigt und eine Fehlermeldung an die Konsole gesendet, wenn das Bild nicht den angegebenen Grenzen entspricht.


Wenn die Site die Richtlinie für übergroße Bilder verwendet, werden große Bilder hochgeladen, aber stattdessen wird ein Stub angezeigt und eine Fehlermeldung in der Konsole angezeigt

Nicht optimierte Bilder


Ein weiteres häufiges Problem bei Grafiken ist die Verwendung nicht optimierter Bilder. Sehr oft kann man auf Bilder stoßen, die nicht ausreichend komprimiert wurden. Ihre Größe kann jedoch korrekt ausgewählt werden. Daher können Dateien mit Fotos beim Aufnehmen und Erstellen viele unnötige Metadaten hinzugefügt werden, die häufig in Dateien verbleiben und in Browsern verwendet werden. Ein besonders ärgerliches Beispiel hierfür sind Bilder, deren Metadaten eigene Miniaturansichten zur Vorschau enthalten. Oft habe ich gesehen, wie das in das Bild eingebettete Miniaturbild (dessen Anwesenheit Designer und Entwickler nicht einmal wussten) mehr „wog“ als das Bild selbst!

Hier können Sie sich unter anderem an die übliche Bildkomprimierung erinnern, die von vielen Formaten unterstützt wird und die es Ihnen ermöglicht, das perfekte Gleichgewicht zwischen Bildqualität und Dateigröße zu erreichen.

Die Richtlinien für nicht optimierte verlustbehaftete Bilder und nicht optimierte verlustfreie Bilder teilen dem Browser mit, dass die Dateigröße und die Bildgröße in Pixel übereinstimmen.

Feature-Policy: unoptimized-lossy-images 'none';
Feature-Policy: unoptimized-lossless-images 'none';

Wenn die Anzahl der Bytes pro Pixel (Byte pro Pixel, BPP) zu hoch ist, zeigt der Browser anstelle des Bildes einen Stub an und zeigt eine Fehlermeldung in der Konsole an.


Durch das Anwenden von nicht optimierten * Richtlinien wird ein Stub anstelle von unangemessenen Bildern angezeigt. Genau wie bei der Richtlinie

für übergroße Bilder beträgt die empfohlene BPP-Stufe für verlustbehaftete komprimierte Bilder 0,5 und 1 für verlustfreie komprimierte Bilder. Außerdem ist bei der Analyse von Bildern eine geringfügige Abweichung ihrer Gesamtgröße von diesen Ebenen zulässig. Diese Abweichung für verlustkomprimierte Bilder beträgt nun 1 KB, für verlustkomprimierte Bilder 10 KB.

Angenommen, wir haben ein JPEG-Bild mit 200 x 200 Pixel. JPEG ist ein verlustbehaftetes Bildkomprimierungsformat, das zu einem empfohlenen BPP-Wert von 0,5 führt. Gleichzeitig kann die Gesamtbildgröße die empfohlene Größe nur um 1 KB überschreiten. Um herauszufinden, welche Größe ein ähnliches Bild für einen Browser geeignet sein sollte, müssen Sie die Abmessungen der Bildseiten in Pixel miteinander und mit BPP multiplizieren und dann die zulässige Abweichung zu dem, was passiert, hinzufügen.

(200 x 200 x .5) + 1024 = 21,024Byte oder 20.5Kb

Wenn das Bild ohne Verlust komprimiert wird, ist eine Abweichung von der „idealen“ Größe von 10 Kb zulässig, während der BPP eines solchen Bildes 1 beträgt. Andernfalls sehen die Berechnungen genau gleich aus:

(200 x 200 x 1) + 10,240 = 50,240Byte oder 49.1Kb

Die Größe der zulässigen Abweichung wird sich voraussichtlich in Zukunft ändern. Obwohl Blink diesen Indikator standardmäßig für verlustfrei komprimierte Bilder von 10 KB verwendet, laufen bereits Experimente mit einer Richtlinie unoptimized-lossless-images-strict, mit der dieser Indikator geändert und auf 1 KB gesenkt wird.

Medien nicht angegeben


Das Neue ist das gut vergessene Alte.

Für eine lange Zeit Attribute der Verwendung von Bild heightund widthwar mehr oder weniger verbreitet. Ohne diese Attribute wusste der Browser bis zum Laden des Bildes nicht, wie viel Speicherplatz das Bild einnehmen sollte. Dies führte zu Verschiebungen im Seitenlayout. Die Seite wurde angezeigt, und nachdem das Bild angekommen war, verschob sich der Inhalt. Der Browser musste das Layout erneut nachzählen, um Platz für das Bild zu schaffen.

Als die Zeit für Layouts kam, in denen die Bildgröße mithilfe von CSS flexibel angepasst werden musste, spielte das Vorhandensein oder Fehlen dieser Attribute keine besondere Rolle mehr. Infolgedessen haben viele einfach aufgehört, diese Attribute zu verwenden.

Aber dank der jüngsten ArbeitVon Jen Simmons initiiert, können Firefox und Chrome das Seitenverhältnis von Bildern anhand ihrer Attribute heightund berechnen width. Wenn dieser Ansatz mit den auf Bilder angewendeten Stilen kombiniert wird, stellt sich heraus, dass Browser während des ersten Durchlaufs des Layouts Platz für Bilder reservieren können.

Die Richtlinie für nicht dimensionierte Medien teilt dem Browser mit, dass alle Medienelemente Attribute haben müssen, die die Größe dieser Elemente angeben. Wenn keine solchen Attribute vorhanden sind, sollte der Browser die Standardwerte verwenden. Tatsächlich ist alles etwas komplizierter, aber unter dem Strich verwendet der Browser den Standardpixelwert, wenn das Bild nicht die entsprechenden Attribute aufweist 300x150.

Feature-Policy: unsized-media 'none';

Wenn diese Richtlinie angewendet wird, werden Bilder angezeigt. Wenn ihre Größe jedoch nicht in HTML angegeben ist, stellt der Entwickler schnell fest, dass die Bilder in der Standardgröße angezeigt werden. Und wie üblich wird eine Fehlermeldung an die Konsole gesendet.


Die Anwendung der Richtlinie für nicht dimensionierte Medien führt dazu, dass Bilder und Videos ohne die Attribute für Höhe und Breite angezeigt werden, der Browser ihre Größe jedoch auf 300 x 150 Pixel festlegt.

Wahrscheinlich ist eine Funktion erwähnenswert, die mir zunächst ungewöhnlich erschien. Sie zeigt sich beim Teilen von Richtlinienunsized-mediaundoversized-images. In dieser Situation sollte man sich nicht über das Auftreten von mehr als zuvor der Anzahl von Nachrichten über zu große Bilder wundern. Tatsache ist, dass derunsized-mediaBrowseraufgrund der Anwendung der Richtlinie dieGröße von Bildern ohne Attributeheightundwidthbis zu300x150Pixeländert. Danach verwendet der Browser diese Größe als Referenzpunkt, um festzustellen, ob das Bild mit seinem Container übereinstimmt.

Aufmerksamkeit auf weniger sichtbare Probleme lenken


In bildbezogenen Richtlinien gefällt mir die Tatsache, dass sie bei der Entwicklung von Projekten ermöglichen, sichtbar zu machen, was normalerweise verborgen ist. Infolgedessen erfährt der Entwickler, dass er sich nicht um die Optimierung der Bilder gekümmert hat oder dass er vergessen hat, ihre Attribute heightund festzulegen width. All diese Fehler spiegeln sich sofort im Erscheinungsbild der Seiten wider. Tatsächlich besteht der Hauptvorteil der Verwendung der oben genannten Richtlinien darin, dass der Entwickler schnell Probleme mit den Bildern feststellen kann. Während der Politikunsized-mediaDies kann zu einer Verringerung der Anzahl von Situationen führen, in denen „Verschiebungen“ von Seitenlayouts auftreten. Die Verwendung anderer Richtlinien verhindert nicht das Laden unangemessener Bilder. Daher besteht die einzige Stärke der Anwendung dieser Richtlinien darin, dass sie die Entwickler auf Probleme aufmerksam machen.

Es gibt mehrere weitere Richtlinien, die nützlich sein können, um Seiten auf die Auswirkungen von etwas auf ihre Leistung zu analysieren. Hier kommen Richtlinien wie Sync-Script in den Sinn (diese Richtlinie blockiert die Ausführung synchroner Skripte), sync-xhr(blockiert synchrone AJAX-Anforderungen) und document-write(blockiert Aufrufe document.write).

Diese Richtlinien eignen sich hervorragend zur Steuerung bestimmter Aspekte der Seitenleistung. Sie selbst bieten Entwicklern jedoch nicht das gleiche spürbare Feedback, das viele der oben genannten Richtlinien in Form fehlender Bilder bieten. Wenn die Seite über ein synchrones Skript verfügt, ohne das es nicht angezeigt wird, ist dies natürlich nicht leicht zu übersehen (und solche Seiten sind nicht so schwer zu finden). Diese Richtlinien weisen jedoch normalerweise auf Fehler in Form von Nachrichten hin, die auf der Konsole angezeigt werden. Und um ehrlich zu sein, vermute ich, dass die meisten Entwickler der Konsole nicht viel Aufmerksamkeit schenken (ich denke, wir sollten alle vorsichtiger mit der Konsole umgehen).

Trotzdem können wir die durch die "unsichtbaren" Richtlinien erkannten Fehler mithilfe der API viel deutlicher machenReportingObserver zur Überwachung von Verstößen und zur Anzeige relevanter Benachrichtigungen auf der Seite. Solche Benachrichtigungen können sehr auffällig gemacht werden.

let reportingAlerts = document.createElement('ul');
  reportingAlerts.setAttribute('id','reportingAlerts');
  document.body.appendChild(reportingAlerts);

const alertBox = document.getElementById('reportingAlerts');

new ReportingObserver((reports, observer) => {
  let fragment = document.createDocumentFragment();
  
  Object.keys(reports).forEach(function(item) {
    let li = document.createElement('li');
    li.textContent = reports[item].body.message + ': ' + reports[item].body.featureId;
    fragment.appendChild(li);
  });
  
  alertBox.appendChild(fragment)
}, {types: ['feature-policy-violation'], buffered: true}).observe();

Ich habe in CodePen ein Beispiel skizziert, wie dies aussehen könnte.


Ein Beispiel dafür, wie Sie Benachrichtigungen über Richtlinienverletzungen anzeigen können, die im Feature-Policy-Header angegeben sind. Solche Benachrichtigungen sind für die Ausgabe in der Entwicklungsumgebung oder dort vorgesehen, wo das Projekt für die Ausgabe an die Produktion vorbereitet ist.

Weniger Verwendung des Feature-Policy-Headers


Das große Minus bei der Verwendung des Headers Feature-Policyist die Unterstützung durch Browser. Anscheinend wird es jetzt nur noch von Blink-basierten Browsern (Opera, Edge, Chrome, Samsung) unterstützt. Firefox- und Safari-Browser unterstützen das Attribut allowfür Elemente iframe. Aber selbst wenn es Feature-Policyunterstützt wird, müssen Sie das Flag aktivieren, um den Zustand vieler Richtlinien zu gewährleisten Experimental Web Platform features(Sie finden es unter der Adresse about:flags).

Wie ich den Feature-Policy-Header verwende


Das Feature-Policyoben erwähnte Minus des Titels ist für mich persönlich kein besonderes Problem. Ich bevorzuge es, die in diesem Header definierten Richtlinien als browserbasierte Seitenprüfung zu verwenden. Daher muss ich mich nicht bemühen, mich Feature-Policyin der Produktion zu bewerben oder sicherzustellen, dass Richtlinien für alle meine Benutzer funktionieren. Sie werden nur von mir sowie von denen benötigt, die die Site entwickeln. Ich verwende auf jeden Fall Chrome als Hauptbrowser im Entwicklungsprozess. Um die Leistung Feature-Policein meiner Arbeitsumgebung sicherzustellen, muss daher das entsprechende Flag aktiviert werden. Danach arbeiten die Politiker ohne zusätzliche Intervention meinerseits.

Ich fand, dass der einfachste Weg, den Header Feature-Policyzu verwenden, eine Browser-Erweiterung istModHeader . Mit dieser Erweiterung können Sie Ihre eigenen Überschriften festlegen, die beim Anzeigen an Seiten übergeben werden.


Mit der ModHeader-Erweiterung können Sie Feature-Policy-Header-Optionen konfigurieren. Sie können auf Wunsch ein- und ausgeschaltet werden

. Ich habe drei Sätze von Header-WertenFeature-Policy, die ich regelmäßig verwende:

  • oversized-images 'none'; unoptimized-lossy-images 'none'; unoptimized-lossless-images 'none';
  • unsized-media 'none'; oversized-images 'none'; unoptimized-lossy-images 'none'; unoptimized-lossless-images 'none';
  • script-sync 'none'; unsized-media 'none'; oversized-images 'none'; unoptimized-lossy-images 'none'; unoptimized-lossless-images 'none';

Ich halte oft den ersten eingeschaltet. Es ist sehr aufregend, durch Webseiten zu reisen, für die die darin verwendeten Richtlinien gelten. Es ist beängstigend zu sehen, wie groß einige Bilder sind. Es gibt viele Dinge im modernen Web, die verbessert werden könnten.

Politik wird also sehr oft auf den Seiten ausgelöst unsized-media(und ich sündige auch dadurch), so dass ihre Verwendung während der normalen Arbeit im Internet unpraktisch ist. Deshalb habe ich es in einer separaten Richtlinie hervorgehoben, die ich ein- und ausschalten kann. Gleiches gilt für Richtlinien sync-scripts, deren Anwendung viele Websites "kaputt macht".

Einige der Teams, mit denen ich zusammengearbeitet habe, haben begonnen, die Richtlinien zu verwenden, die ich während der Entwicklung beschrieben habe. Dadurch können sie schnell auf bisher unsichtbare Probleme achten. Natürlich empfehle ich, alle Richtlinien Feature-Policyin die Entwicklungsumgebung aufzunehmen, damit Sie Fehler schnell identifizieren und korrigieren können.

Zusammenfassung


Ich hoffe, dass die Unterstützung Feature-Policynicht nur in Chrome angezeigt wird. Obwohl dies mein Hauptbrowser ist, muss ich auch andere Browser verwenden. Es wäre hilfreich, wenn sie unterstützen würden Feature-Policy. Hier sehen wir jedoch diese seltene Situation, in der selbst die experimentelle Unterstützung einer bestimmten Gelegenheit ausreicht, um von wirklichem Nutzen zu sein.

Subtile Leistungsprobleme sind ebenfalls Probleme. Die Fähigkeit, solche Probleme sichtbarer zu machen, ist eine der besten Methoden, mit denen ein Entwickler sie identifizieren und beheben kann.

Liebe Leser! Planen Sie, die Überschrift Feature-Policy zu verwenden, um unauffällige Probleme in Webprojekten zu identifizieren?


All Articles