En-tête HTTP et contrôle du navigateur Web

Il existe une technique totalement incomparable qui vous permet de contrôler les performances d'un projet Web. Elle consiste à introduire dans le processus de développement des mécanismes dont les résultats sont clairement visibles. Ces mécanismes sont conçus pour toujours rappeler au programmeur l'importance des performances. Il y a quelque chose dans ce contexte que j'aime beaucoup. Il s'agit de l'en - tête HTTP Feature-Policy . Ce titre est une fonctionnalité relativement nouvelle qui permet à un développeur d'activer et de désactiver certaines fonctionnalités du navigateur lors de la navigation sur son site. Par exemple, vous pouvez indiquer au navigateur qu'il ne doit pas autoriser l'utilisation de l'API de géolocalisation en lui passant l'en-tête suivant:







Feature-Policy: geolocation 'none'

L'utilisation d'un en-tête Feature-Policyprésente de nombreux avantages en termes de sécurité et de performances. Mais j'aime maintenant particulièrement comment Feature-Policyvous pouvez l'utiliser pour rendre plus visibles les problèmes de performances des sites Web qui sont généralement faciles à ignorer. Cela peut être comparé à quelque chose comme "linting performance". En particulier, nous parlons d'identifier les problèmes avec les images utilisées dans les projets Web.

Politique d'images surdimensionnées


Si l'image est transmise au navigateur dans un format qu'il prend en charge, une telle image sera affichée. Il s'agit d'un comportement de navigateur standard. Le navigateur, essayant d'aider ceux qui consultent la page, redimensionne également automatiquement ces images. Par conséquent, ils ont l'air bien même s'ils sont représentés par d'énormes fichiers graphiques. Par conséquent, si vous utilisez des images plus grandes que les tailles requises par la page, cela est, à première vue, invisible.

Politique ( directive )oversized-imagesindique au navigateur qu'il ne doit pas autoriser l'utilisation d'images dont la taille dépasse, d'un nombre de fois spécifié, la taille de leurs conteneurs. L'image, conformément à la restriction standard, ne peut pas dépasser 2 fois le conteneur. Mais cette valeur, si nécessaire, peut être redéfinie.

Donc, si le navigateur reçoit l'en-tête suivant, il ne vous permettra pas d'afficher des images prises à partir de n'importe quelles sources (c'est réglé grâce none), dont les dimensions sont plus de 2 fois la taille de leurs conteneurs (en largeur ou en hauteur).

Feature-Policy: oversized-images 'none';

Si vous avez besoin de plus de flexibilité, vous pouvez indiquer au navigateur qu'il ne doit pas afficher d'images qui sont plus de 3 fois plus grandes que les conteneurs:

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

Dans tous les cas, si l'image ne correspond pas aux limites spécifiées, un talon sera affiché à la place de l'image et un message d'erreur sera envoyé à la console.


Si le site utilise la politique d'images surdimensionnées, de grandes images seront téléchargées, mais un talon s'affichera à la place et un message d'erreur s'affichera dans la console.

Images non optimisées


Un autre problème courant avec les graphiques est l'utilisation d'images non optimisées. Très souvent, vous pouvez rencontrer des images qui n'ont pas été correctement compressées. Cependant, leur taille peut être sélectionnée correctement. Ainsi, aux fichiers contenant des photos, lors de la prise de vue et de leur création, de nombreuses métadonnées inutiles peuvent être ajoutées, qui restent souvent dans les fichiers lorsqu'elles sont utilisées dans les navigateurs. Un exemple particulièrement ennuyeux de cela est les images, dont les métadonnées contiennent leurs propres miniatures pour l'aperçu. Plusieurs fois, j'ai vu comment la vignette intégrée à l'image (dont les concepteurs et développeurs ne savaient même pas la présence) «pesait» plus que l'image elle-même!

Entre autres choses, vous pouvez ici rappeler la compression d'image habituelle, prise en charge par de nombreux formats, qui vous permet d'atteindre l'équilibre parfait entre la qualité de l'image et la taille du fichier.

Les politiques d'images non optimisées avec perte et d' images non optimisées sans perte indiquent au navigateur qu'il correspond à la taille du fichier et à la taille de l'image en pixels.

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

Si le nombre d'octets par pixel (octet par pixel, BPP) est trop élevé, le navigateur affichera un talon à la place de l'image et affichera un message d'erreur dans la console.


L'application de stratégies non optimisées * entraîne l'affichage d'un stub au lieu d'images inappropriées - tout comme l'utilisation de la stratégie d'images surdimensionnées, le

niveau BPP recommandé pour les images compressées avec perte est de 0,5 et 1 pour les images compressées sans perte. De plus, lors de l'analyse des images, une légère déviation de leur taille totale par rapport à ces niveaux est autorisée. Or, cet écart pour les images compressées avec perte est de 1 Ko, pour les images compressées sans perte - 10 Ko.

Par exemple, supposons que nous ayons une image JPEG de 200x200 pixels. JPEG est un format de compression d'image avec perte, ce qui donne un niveau BPP recommandé de 0,5. Dans le même temps, la taille totale de l'image peut dépasser la taille recommandée de seulement 1 Ko. Pour savoir quelle taille une image similaire devrait convenir à un navigateur, vous devez multiplier les dimensions des côtés de l'image en pixels par l'autre et par BPP, puis ajouter l'écart autorisé à ce qui se passe.

(200 x 200 x .5) + 1024 = 21,024octet, ou 20.5Ko

Si l'image est compressée sans perte, un écart par rapport à la taille «idéale» de 10 Ko est autorisé, tandis que le BPP d'une telle image sera de 1. Sinon, les calculs sont exactement les mêmes:

(200 x 200 x 1) + 10,240 = 50,240octet ou 49.1Ko

L'ampleur de l'écart autorisé est susceptible de changer à l'avenir. En fait, bien que Blink, par défaut, utilise cet indicateur pour des images compressées sans perte, égal à 10 Ko, des expériences sont déjà en cours avec une politique unoptimized-lossless-images-strictqui modifie cet indicateur, le ramenant au niveau de 1 Ko.

Média non spécifié


Le nouveau est l'ancien bien oublié.

Pendant longtemps, l'utilisation des attributs d'image height, et a widthété plus ou moins courante. Sans ces attributs, le navigateur ne savait pas combien d'espace l'image devait occuper jusqu'au moment où l'image a été chargée. Cela a entraîné des changements dans les mises en page. La page a été affichée, puis, une fois l'image arrivée, son contenu a changé. Le navigateur a de nouveau dû recomposer la mise en page afin d'allouer de l'espace à l'image.

Lorsque le moment est venu de disposer de mises en page dans lesquelles les tailles d'image devaient être redimensionnées de manière flexible à l'aide de CSS, la présence ou l'absence de ces attributs ne jouait plus un rôle particulier. En conséquence, beaucoup ont simplement cessé d'utiliser ces attributs.

Mais grâce à des travaux récentsinitié par Jen Simmons, Firefox et Chrome peut calculer le rapport d'aspect des images en fonction de leurs attributs heightet width. Lorsque cette approche est combinée avec les styles appliqués aux images, il s'avère que les navigateurs peuvent réserver de l'espace pour les images lors du passage initial de la mise en page.

La stratégie de média non dimensionné indique au navigateur que tous les éléments multimédias doivent avoir des attributs qui spécifient les tailles de ces éléments. S'il n'y a pas de tels attributs, le navigateur doit utiliser les valeurs par défaut. En fait, tout est un peu plus compliqué, mais l'essentiel est que si l'image n'a pas les attributs appropriés, le navigateur utilise la valeur de 300x150pixel standard .

Feature-Policy: unsized-media 'none';

Lorsque cette stratégie est appliquée, les images seront affichées, mais si leur taille n'est pas spécifiée en HTML, le développeur remarquera rapidement que les images sont affichées dans la taille par défaut. Et, comme d'habitude, un message d'erreur sera envoyé à la console.


L'application de la politique relative aux médias non dimensionnés conduit au fait que les images et les vidéos sans les attributs de hauteur et de largeur sont affichées, mais le navigateur définit leur taille à 300x150 pixels.

Probablement, il convient de mentionner une fonctionnalité qui m'a d'abord semblé inhabituelle. Elle se montre lorsqu'elle partage des politiquesunsized-mediaetoversized-images. Dans cette situation, il ne faut pas s'étonner de l'apparition de plus qu'avant, du nombre de messages sur des images trop grandes. Le fait est qu'en raison de l'application de la politique, leunsized-medianavigateur redimensionne les images qui n'ont pas d'attributsheightetwidthjusqu'à300x150pixels. Après quoi, c'est cette taille que le navigateur utilise comme point de référence pour déterminer si l'image correspond à son conteneur.

Attirer l'attention sur des problèmes moins visibles


Dans les politiques liées à l'image, j'aime le fait qu'elles, dans le processus de développement de projets, permettent de rendre visible ce qui est habituellement caché. En conséquence, le développeur apprend qu'il n'a pas pris soin d'optimiser les images, ou qu'il a oublié de définir leurs attributs heightet width. Toutes ces erreurs se reflètent immédiatement dans l'apparence des pages. En fait, le principal avantage de l'utilisation des politiques ci-dessus est qu'elles permettent au développeur de trouver rapidement des problèmes avec les images. Alors que la politiqueunsized-mediapeut entraîner une diminution du nombre de situations dans lesquelles des «changements» de mise en page se produisent, l'utilisation d'autres politiques n'empêche pas le chargement d'images inappropriées. Par conséquent, le seul point fort de l'application de ces politiques est qu'elles attirent l'attention des développeurs sur les problèmes.

Il existe plusieurs autres politiques qui peuvent être utiles en termes d'analyse des pages pour l'impact de quelque chose sur leurs performances. C'est là que les politiques comme sync-script viennent à l'esprit (cette politique bloque l'exécution des scripts synchrones), sync-xhr(bloque les requêtes AJAX synchrones) et document-write(bloque les appels document.write).

Ces politiques sont d'excellents outils pour contrôler certains aspects des performances des pages, mais elles ne fournissent pas aux développeurs les mêmes commentaires notables que la plupart des politiques ci-dessus fournissent sous la forme d'images manquantes. Bien sûr, si la page a un script synchrone, sans lequel il n'est pas affiché, ce n'est pas facile à manquer (et ces pages ne sont pas si difficiles à trouver). Mais ces politiques indiquent généralement des erreurs sous la forme de messages affichés sur la console. Et pour être honnête, je soupçonne que la plupart des développeurs ne prêtent pas beaucoup d'attention à la console (je pense que nous devrions tous faire plus attention à la console).

Mais, néanmoins, nous pouvons rendre les erreurs détectées par les politiques "invisibles" beaucoup plus visibles en utilisant l'APIReportingObserver pour surveiller les violations et afficher les notifications pertinentes sur la page. Ces notifications peuvent être très visibles.

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();

J'ai esquissé un exemple dans CodePen de ce à quoi cela pourrait ressembler.


Un exemple de la façon dont vous pouvez afficher les notifications des violations de stratégie spécifiées par l'en-tête Feature-Policy. Ces notifications sont conçues pour une sortie dans l'environnement de développement ou lorsque le projet est préparé pour une sortie en production.

Moins d'utilisation de l'en-tête Feature-Policy


Le gros inconvénient de l'utilisation de l'en-tête Feature-Policyest sa prise en charge par les navigateurs. Apparemment, il n'est désormais pris en charge que par les navigateurs basés sur Blink (Opera, Edge, Chrome, Samsung). Les navigateurs Firefox et Safari prennent en charge l'attribut allowpour les éléments iframe. Mais même là où il est Feature-Policypris en charge, pour garantir l'intégrité de la plupart des stratégies, vous devez activer l'indicateur Experimental Web Platform features(vous pouvez le trouver à l'adresse about:flags).

Comment j'utilise l'en-tête de stratégie de fonctionnalité


Ce moins du titre Feature-Policy, qui est mentionné ci-dessus, pour moi personnellement n'est pas un problème particulier. Je préfère utiliser les politiques définies par cet en-tête comme vérificateur de page basé sur un navigateur. Par conséquent, je n'ai pas besoin de m'efforcer de postuler Feature-Policyen production ou de m'assurer que les politiques fonctionnent pour tous mes utilisateurs. Ils ne sont nécessaires que par moi, ainsi que par ceux qui développent le site. Dans tous les cas, j'utilise Chrome comme navigateur principal dans le processus de développement. Par conséquent, garantir les performances Feature-Policedans mon environnement de travail consiste à activer l'indicateur approprié. Après cela, les politiciens travaillent sans aucune intervention supplémentaire de ma part.

J'ai trouvé que la façon la plus simple d'utiliser l'en-tête est Feature-Policyavec une extension de navigateurModHeader . Cette extension vous permet de définir vos propres en-têtes qui sont transmis aux pages lors de leur affichage.


L'extension ModHeader vous permet de configurer les options d'en-tête Feature-Policy. Ils peuvent être activés et désactivés, si vous le souhaitez

. J'ai trois ensembles de valeurs d'en-têteFeature-Policyque j'utilise périodiquement:

  • 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';

Je garde souvent le premier allumé. Il est très excitant de parcourir les pages Web auxquelles s'appliquent les politiques qui y sont utilisées. Il est effrayant de voir la taille de certaines images. Il y a beaucoup de choses sur le web moderne qui pourraient être améliorées.

Donc, la politique est très souvent déclenchée sur les pages unsized-media(et je pèche aussi), donc son utilisation pendant le travail normal sur Internet est gênante. C'est pourquoi je l'ai mis en évidence dans une politique distincte, que je peux activer et désactiver. Il en va de même pour les politiques sync-scriptsdont l'application "casse" de nombreux sites.

Certaines des équipes avec lesquelles j'ai travaillé ont commencé à utiliser les politiques que j'ai décrites pendant le développement. Cela leur permet de prêter rapidement attention aux problèmes auparavant invisibles. Bien sûr, je recommande d'inclure toutes les politiques Feature-Policydans l'environnement de développement, ce qui vous permet d'identifier rapidement et de corriger les erreurs.

Sommaire


J'espère que le support Feature-Policyapparaîtra, par conséquent, non seulement dans Chrome. Bien que ce soit mon navigateur principal, je dois également utiliser d'autres navigateurs. Il serait utile qu'ils soutiennent Feature-Policy. Mais ici, cependant, nous voyons cette situation rare où même le soutien expérimental d'une certaine opportunité est suffisant pour qu'elle soit réellement bénéfique.

Les problèmes de performances subtils sont également des problèmes. Et la possibilité de rendre ces problèmes plus visibles est l'une des meilleures méthodes qu'un développeur peut utiliser pour les identifier et les résoudre.

Chers lecteurs! Envisagez-vous d'utiliser l'en-tête Feature-Policy pour identifier les problèmes discrets dans les projets Web?


All Articles