Vendredi dernier, l’équipe des thèmes WordPress a annoncé la sortie de sa nouvelle Projet Webfonts Loader. Il s’agit d’un script drop-in qui permet aux auteurs de thèmes de charger des polices Web à partir du site de l’utilisateur au lieu d’un CDN tiers. Le message secondaire inclus dans l’annonce de l’équipe est qu’elle ne prévoit plus d’autoriser les thèmes à créer un lien direct avec les polices Google à l’avenir.

Tout au long de la majeure partie de l’histoire de l’équipe, elle n’a pas autorisé les thèmes à créer des liens hypertexte ou à utiliser des CDN pour héberger des ressources de thème, telles que CSS, JavaScript et polices. Celui exception à cette règle était l’utilisation de Google Fonts. Cela a permis aux thèmes de disposer d’options de typographie plus riches à partir de ce que l’équipe a généralement déclaré une source fiable.

«L’exception a été faite parce qu’il n’y avait aucun moyen pratique de ne pas avoir l’exception à l’époque», a déclaré Aria Stathopoulos, une représentante de l’équipe Themes et développeur derrière le projet Webfonts Loader. «L’exception pour Google Fonts a été faite par nécessité. Maintenant qu’il existe un autre moyen, l’exception ne sera plus nécessaire. »

En effet, refuser le CDN Google Fonts ne constituerait pas une nouvelle interdiction. Ce serait la suppression d’une exception à l’interdiction actuelle.

Google Fonts est devenu si intégré dans l’ensemble d’outils de développement de thèmes au fil des ans, il était impossible pour l’équipe de simplement retirer la prise et d’interdire l’utilisation du CDN du jour au lendemain. Si les membres de l’équipe des thèmes voulaient se concentrer davantage sur la confidentialité, ils auraient besoin de créer un outil qui le rendrait extrêmement simple à utiliser pour les auteurs de thèmes.

Il n’y a pas de date limite pour que l’équipe supprime l’exception pour Google Fonts, et ce n’est pas figé à ce stade. Stathopoulos a déclaré que sa suppression était l’objectif depuis le début, interdisant tous les CDN. Cependant, il a fallu un certain temps pour trouver un moyen efficace de gérer cela. Avec une alternative viable en place, ils peuvent discuter de l’avenir.

Chargeur de polices Web pour les thèmes

Le projet Webfonts Loader reste simple pour les auteurs de thèmes. Il introduit un nouveau wptt_get_webfont_styles() fonction que les développeurs peuvent insérer dans une URL de feuille de style. Une fois qu’une page est chargée avec cet appel de fonction, elle téléchargera les polices localement sur un /fonts dossier de l’utilisateur /wp-content annuaire. De cette façon, les polices seront toujours servies à partir du site de l’utilisateur.

Le système ne se limite pas non plus à Google Fonts. Toute URL qui sert du CSS avec un @font-face {} la règle fonctionnera. Il n’inclut actuellement pas l’authentification pour les CDN qui nécessitent des clés API, telles que Adobe Fonts. Cependant, c’est quelque chose que l’équipe pourrait ajouter à l’avenir.

«Pour les utilisateurs finaux, s’éloigner des CDN et héberger localement des polices Web améliorera les performances (moins d’allers-retours de négociation pour SSL) et constitue le choix soucieux de la confidentialité», a déclaré Stathopoulos. «Le seul ‘problème de confidentialité valable’ est que le CDN des polices Web ne divulgue pas les informations fondamentales du RGPD: quelles informations sont enregistrées, combien de temps ces journaux restent-ils, comment ils sont traités, s’il y a des renvois avec toutes les autres richesses d’informations que l’entreprise a des utilisateurs, etc. Le problème est un manque de divulgation et d’information. Si un propriétaire de site ne sait pas quel type d’informations un tiers enregistre pour ses visiteurs, il ne devrait pas appliquer cela à ses visiteurs. Avec ce package, le CDN est supprimé de l’équation et la police est toujours servie rapidement, sinon plus rapidement. »

Un chemin vers le cœur de WordPress

Aujourd’hui, l’accent est désormais davantage mis sur les problèmes de confidentialité liés aux ressources tierces, en particulier avec les géants de la technologie comme Google. Ces préoccupations s’étendent à savoir si des tiers suivent les utilisateurs ou collectent des données. D’autres préoccupations concernent la question de savoir si les sites divulguent l’utilisation de ressources tierces, ce qui peut être requis dans certaines juridictions. Les propriétaires de sites qui sont souvent incapables de travailler sur le Web des problèmes potentiels sont coincés au milieu.

Jono Alderson a ouvert un billet pour créer une API pour le chargement des polices Web localement dans le noyau de WordPress en février 2019. Il s’agit d’une proposition longue et détaillée, mais elle n’a pas encore vu beaucoup d’acceptation en dehors d’une poignée de développeurs.

«Si un tel script est standardisé et inclus dans le cœur de WordPress, l’un des principaux avantages serait un plus grand respect de la vie privée de l’utilisateur final», a déclaré Stathopoulos. «En fin de compte, tout est question de confidentialité: respecter les utilisateurs.»

Une API standard comme celle proposée par Alderson pourrait résoudre certains problèmes. À savoir, cela éliminerait pratiquement tout problème de confidentialité. Cependant, le chargement de polices localement pourrait permettre à WordPress d’optimiser le chargement des polices et créerait un système partagé dans lequel les plugins et les thèmes ne chargeraient pas les actifs en double en raison des limitations actuelles du système de mise en file d’attente. Une API standard placerait également la responsabilité de charger efficacement les polices sur les épaules de WordPress au lieu des développeurs de thèmes et de plugins.

Le nouveau projet de l’équipe des thèmes est un bon départ et renforce la proposition actuelle.

«Si nous voulons vraiment que WordPress devienne une plate-forme rapide et respectueuse de la vie privée, nous ne pouvons pas compter sur les développeurs de thèmes pour ajouter et gérer des polices sans fournir un cadre pour les prendre en charge», a écrit Alderson dans le ticket.


Source link