Les polices Google les plus rapides – CSS Wizardry – Optimisation des performances Web

Online Coding Courses for Kids

Écrit par sur CSS Wizardry.

Table des matières
  1. Essai
  2. Par défaut / hérité
  3. font-display: swap;
  4. CSS asynchrone
  5. preload
  6. preconnect
  7. Prime: font-display: optional;
  8. Comparaisons et visualisations
  9. Résultats
  10. Extrait Google Fonts Async

Pour la plupart, les polices Web sont aujourd’hui plus rapides que jamais. Avec plus
Comportement FOUT / FOIT standardisé des fournisseurs de navigateurs aux plus récents
font-display les spécifications, les performances – et donc l’utilisateur – semblent avoir
été finalement mis au premier plan.

Il est largement admis que les polices auto-hébergées sont l’option la plus rapide: même origine
signifie une négociation réseau réduite, des URL prévisibles signifient que nous pouvons preload,
auto-hébergé signifie que nous pouvons définir notre propre cache-control

directives, et
la pleine propriété atténue les risques associés au fait de laisser des actifs statiques allumés
tierce personne
origines
.

Cela dit, la commodité d’un service comme Google Fonts ne peut pas être surestimée.
Leur capacité à servir les plus petits fichiers de polices possibles adaptés à un utilisateur spécifique
les agents et les plates-formes sont incroyables, et avec une bibliothèque aussi énorme et librement disponible
servis à partir de CDN de qualité Google… Je vois vraiment pourquoi les gens continuent de se tourner vers
il.

Sur ce site, où la performance est le seul nom du jeu, je renonce au web
polices entièrement, en optant plutôt pour utiliser la police système du visiteur. C’est
rapide, incroyablement bien adapté à l’appareil en question, et a presque zéro
frais généraux d’ingénierie. Mais, le harry.is, Je voulais vraiment
jetez la prudence au vent. Au diable avec ça! Ayons une police Web!

Cependant, j’avais encore besoin d’être rapide.

Pendant le prototypage, je me suis tourné vers Google Fonts, et avec leur capacité récente à
soutien font-display via un paramètre URL (&display=swap), Je savais que les choses
resterait assez rapide. Ensuite, j’ai eu une idée.

Tout a commencé par un tweet:

Tandis que font-display: swap; est une énorme victoire, il y a encore beaucoup de choses
me laissant mal à l’aise. Que puis-je faire d’autre pour créer des polices Google vite?

Autant dire que j’ai fini par descendre un petit terrier de lapin…

Essai

J’ai exécuté la même suite de tests contre le harry.is et
Pages d’accueil csswizardry.com. J’ai commencé avec
harry.is parce que c’est là que j’utilisais les polices Google, mais je sentais que c’était une page
trop simple pour être réaliste. Donc, j’ai cloné la page d’accueil CSS Wizardry un tas de
fois et y a mis en œuvre les différentes méthodes. Pour chacune des sections
de ce post, je vais lister les résultats pour les deux sites. Mes variantes sont:

  • Héritage: Polices Google sans font-display.
  • font-display: swap;: Utilisation de la nouvelle valeur par défaut de Google Fonts.
  • CSS asynchrone: Chargement du fichier de polices Google de manière asynchrone.
  • preload: preloaden utilisant le fichier CSS pour augmenter sa priorité.
  • preconnect: Réchauffer le fonts.gstatic.com origine moi-même.

De plus, chaque variante est additive – elle inclut la variante précédente ainsi que
ses propres ajouts. Je n’ai pas essayé juste preload ou juste async, car il
serait inutile – nous savons qu’une combinaison se comportera mieux que
posséder.

Pour chaque test, j’ai capturé les métriques suivantes:

  • Première peinture (FP): Dans quelle mesure le chemin critique est-il affecté?
  • Première peinture contentieuse (FCP): Combien de temps peut-on réellement lire quelque chose,
    que ce soit une police Web ou non?
  • Première police Web (FWF): À quel moment la première police Web a-t-elle été chargée?
  • Visuellement complet (VC): Quand tout s’est-il installé (un proxy, mais pas
    équivalent à, Dernière police Web)?
  • Score du phare: Est-ce que ça compte même si ce n’était pas sur Lighthouse?

N.B. Tous les tests ont été effectués à l’aide d’une instance WebPageTest privée
(WebPageTest est en panne en ce moment, je n’ai donc pas pu utiliser l’instance publique, qui
signifie que je ne peux partager aucune URL (excuses). Le profil spécifique était un Samsung
Galaxy S4 sur 3G.

Pour faciliter la lecture des extraits, je vais remplacer toutes les instances de
https://fonts.googleapis.com/css2?family=Roboto:ital,wght@0,400;0,700;1,400;1,700
avec $CSS.

Par défaut / hérité

Google Fonts a joué un très bon coup au cours de la dernière année. Par défaut, tout
le nouvel extrait de police Google vient avec le &display=swap paramètre qui
injecte font-display: swap; dans tous les @font-face at-rules. La valeur
du paramètre peut être l’un des swap, optional, fallback, ou block. Vous
pouvez en savoir plus sur
MDN
.

Pour ma ligne de base, cependant, j’allais couper le font-display recule. Cette
est le format hérité que beaucoup de sites utiliseront probablement encore, et il permet
une base de référence plus appropriée pour comparer.

Fragment:

 rel="stylesheet"
      href="$CSS" />

Il y a deux problèmes clés ici:

  1. Un fichier CSS synchrone et ergo bloquant le rendu sur une origine tierce.
  2. Un fichier contenant @font-face règles sans font-display descripteurs.

C’est synchrone en plus de synchrone – pas bon.

Résultat (s) – harry.is:

FPFCPFWFVCPhare
3.44.64.95,098

Résultat (s) – CSS Wizardry:

FPFCPFWFVCPhare
3.44.34.44.496

Bien. Voici notre référence. Le fichier Google Fonts est le seul blocage de rendu
ressource externe soit l’un des deux tests a, et nous pouvons voir qu’ils ont tous les deux la
exactement la même première peinture. Une chose qui m’a heureusement surpris lors de ces
expériences était la cohérence de Google Fonts.

À ce stade, Lighthouse donne une erreur et un avertissement:

  • (Erreur) Assurez-vous que le texte reste visible pendant le chargement de la police Web
  • (Avertissement) Élimine les ressources bloquant le rendu

Le premier est le résultat de l’absence d’une solution de chargement de polices Web (par ex.
font-display); le second est le résultat du CSS Google Fonts synchrone
fichier.

Maintenant, commençons à ajouter des changements progressifs et, espérons-le, des améliorations.

font-display: swap;

Pour ce test, j’ai ajouté le &display=swap en arrière. En fait, cela rend la
fichiers de polices eux-mêmes asynchrones: le navigateur affiche immédiatement notre solution de rechange
texte avant swapenvoyez une requête ping à la police Web chaque fois qu’elle arrive. Cela signifie que nous ne sommes pas
va laisser les utilisateurs regarder n’importe quel texte invisible (FOIT), ce qui fait à la fois
une expérience plus rapide et plus agréable.

N.B. C’est encore plus agréable si vous faites l’effort de définir un
repli à afficher dans l’intervalle — clignotant une page pleine de Times New Roman
avant de s’installer sur Open Sans serait probablement une pire expérience. Heureusement,
Monica a rendu ce processus non seulement facile,
mais étonnamment amusant. Je ne pourrais pas faire ça sans elle Le style de police
Matcher
.

Fragment:

 rel="stylesheet"
      href="$CSS&display=swap" />

Résultats – harry.is:

FPFCPFWFVCPhare
3.43.45,05.299
Changement par rapport à la référence:0-1,2+0,6+0,2+1

Résultats – CSS Wizardry:

FPFCPFWFVCPhare
3.63.64.64.695
Changement par rapport à la référence:+0,2-0,7+0,2+0,2-1

Nous n’avons supprimé aucune ressource bloquant le rendu du chemin critique.
Je ne m’attendais pas à voir des améliorations dans la première peinture. En fait, bien que
harry.is est resté identique, CSS Wizardry est devenu 200 ms plus lent. Ce que nous voyons,
cependant, une amélioration spectaculaire de la première peinture contentée—Plus d’une seconde
sur harry.is! Première police Web améliorée de 100 à 200 ms, mais visuellement complet était
200ms plus lent.

Je suis heureux de dire que, pour les mesures les plus importantes, nous sommes de 700 à 1 200 ms
plus rapide
.

Bien que cela améliore considérablement le temps de rendu de la police Web, c’est
toujours défini dans un fichier CSS synchrone – nous ne pouvons en attendre
amélioration de ce mouvement.

On pouvait s’y attendre, Lighthouse ne donne désormais qu’un seul avertissement:

  • (Avertissement) Élimine les ressources bloquant le rendu

Par conséquent, l’étape suivante consiste à résoudre le fichier CSS synchrone.

Pour citer, euh, moi-même: Si vous allez utiliser font-display pour votre Google
Polices, il est donc logique de charger de manière asynchrone toute la chaîne de demande.
Il
a été cette pensée initiale qui a conduit à mon tweet en premier lieu – si j’ai
fait efficacement le contenu du fichier CSS asynchrone, puis il suce un peu
pour laisser le fichier CSS lui-même entièrement synchrone.

font-display: swap; est une bonne idée.

CSS asynchrone

Rendre votre CSS asynchrone est l’une des techniques clés impliquées dans
CSS critique. Bien qu’il existe un certain nombre de façons d’y parvenir, j’ose dire que le
le plus simple et le plus omniprésent est Type de support d’impression de Filament Group
tour
.

Cela indiquera implicitement au navigateur de charger le fichier CSS dans un fichier non bloquant
mode, en appliquant les styles uniquement à la print le contexte. Cependant, au moment où le
arrive, nous demandons au navigateur de l’appliquer à all contextes, donc le style
le reste de la page.

Fragment:

 rel="stylesheet"
      href="$CSS&display=swap"
      media="print" onload="this.media='all'" />

Bien que l’astuce soit diaboliquement simple – c’est ce qui le rend si cool –J’ai longtemps
avait mes réserves
. Oui, une feuille de style régulière et synchrone bloque
rendu, donc un navigateur l’assignera Le plus élevé priorité. Une feuille de style d’impression
(ou toute feuille de style qui ne correspond pas au contexte actuel) se voit attribuer le
priorité à l’extrémité opposée complète du spectre: Tourner au ralenti.

Cela signifie que lorsque les navigateurs commencent à faire des demandes, le fichier CSS asynchrone
est souvent largement sous-hiérarchisée (ou plutôt, elle est correctement hiérarchisée, mais
probablement beaucoup moins que ce à quoi vous vous attendiez). Prenons par exemple Vitamix, un client pour qui
J’ai implémenté du CSS asynchrone pour leurs propres fournisseurs de polices:

Bien que Chrome puisse faire du DNS / TCP / TLS asynchrone, il sérialisera et
bloquer les demandes non critiques sur les connexions plus lentes.

Le navigateur fait exactement ce que nous lui avons dit: demandez ces fichiers CSS avec
la priorité d’une feuille de style d’impression. Ainsi, sur une connexion 3G, il prend le relais
neuf secondes pour télécharger chaque fichier. Le navigateur met presque tout le reste,
y comprisbody ressources, avant nos feuilles de style d’impression. Cela signifie que
la page en question n’a pas rendu sa police personnalisée jusqu’à ce qu’un 12.8s de eyewirring sur
3G.

Heureusement, en traitant des polices Web, ce n’est pas la fin du monde:

  • ils doivent toujours être considérés comme une amélioration de toute façon, nous devons donc être en mesure
    faire face sans eux;
  • nous pouvons et devons concevoir des solutions de rechange décentes à utiliser pendant leur absence, et;
  • si nous nous attendons à des retards d’une telle gravité, nous devons utiliser font-display: optional;.

Pour les CSS en dessous du pli, cependant, des retards de près de 10 secondes sont
inacceptable – il est presque certain à 100% qu’un utilisateur aura fait défiler
Plage de temps.

Encore! Qu’advient-il des polices Google si nous les chargeons de manière asynchrone?

Résultats – harry.is:

FPFCPFWFVCPhare
1,81,85,05.1100
Changement par rapport à la référence:-1,6-2,8+0,6+0,1+2
Changement par rapport au précédent:-1,6-1,60-0,1+1

Résultats – CSS Wizardry:

FPFCPFWFVCPhare
1,72.24.95,099
Changement par rapport à la référence:-1,7-2,1+0,5+0,6+3
Changement par rapport au précédent:-1,9-1,4+0,3+0,4+4

Ces résultats sont extraordinaires.

Je suis vraiment content de ces résultats. La première peinture était stupéfiante de 1,6 à 1,7 s
amélioration
sur notre ligne de base, et jusqu’à une amélioration de 1,9s par rapport à la précédente
une variante
dans le cas de CSS Wizardry. La première peinture enrichissante a été
jusqu’à 2,8 s
par rapport à notre ligne de base, et Les scores du phare atteignent 100 pour le
première fois.

En ce qui concerne le chemin critique, ce fut une énorme victoire.

Cependant – et c’est un grand toutefois—En raison de l’abaissement de la priorité du
Fichier CSS, notre la première police Web est jusqu’à 500 ms plus lente dans le cas de CSS
Magie contre notre ligne de base. C’est le danger du piratage de la presse écrite.

Le chargement asynchrone des polices Google est une bonne idée, mais la réduction du
la priorité du fichier CSS a en fait ralenti le rendu de notre custom
Police de caractère.

Je vais dire que le CSS asynchrone est une bonne idée globale mais je dois
atténuer en quelque sorte le problème de priorité.

preload

D’accord, donc si l’impression CSS est aussi faible priorité, ce dont nous avons besoin est une priorité élevée
extraction asynchrone. Entrer preload.

Complétant notre feuille de style astuce média avec un preload s’assure que nous obtenons le
meilleur de tous les mondes:

  1. une extraction asynchrone de haute priorité qui fonctionnera dans presque tous les modernes
    navigateurs, et;
  2. une méthode très largement prise en charge pour réappliquer CSS que nous avons chargée
    asynchrone.

N.B. On ne peut pas aller plein preload car il n’est pas suffisamment pris en charge. Dans
En effet, au moment de la rédaction de ce rapport, environ 20% des visiteurs de ce site ne
pour en faire usage. Considérez la feuille de style d’impression comme une solution de rechange.

Fragment:

 rel="preload"
      as="style"
      href="$CSS&display=swap" />

 rel="stylesheet"
      href="$CSS&display=swap"
      media="print" onload="this.media='all'" />

N.B. À l’avenir, nous devrions pouvoir utiliser les indices de priorité pour résoudre ce problème.

Résultats – harry.is:

FPFCPFWFVCPhare
1,81 .85,05.3100
Changement par rapport à la référence:-1,6-2,8+0,6+0,3+2
Changement par rapport au précédent:000+0,20

Résultats – CSS Wizardry:

FPFCPFWFVCPhare
2.02.04.34.398
Changement par rapport à la référence-1,4-2,3-0,1-0,1+2
Changement par rapport au précédent+0,3-0,2-0,6-0,7-1

Alors que la première peinture est restée la même ou est devenue plus lente, premier contentieux
la peinture est restée la même ou est devenue plus rapide
, et dans le cas de CSS Wizardry,
la première police Web était 600 ms plus rapide que l’itération précédente.

Dans le cas de harry.is, presque rien n’a changé depuis notre précédente variante.
Visuellement complet était 200 ms plus rapide, mais les premières mesures n’étaient pas modifiées.
Ce sont ces résultats qui m’ont incité à tester également contre CSS
Sorcellerie. Parce que harry.is est une page si petite et si simple, il n’y avait pas grand-chose
conflit de réseau pour une feuille de style d’impression à céder – changer sa priorité
n’a pas vraiment aidé du tout.

Dans le cas de CSS Wizardry, nous voyons d’abord peindre 300 ms plus lentement, ce qui est
inattendu mais sans rapport (il n’y a pas de CSS bloquant le rendu, donc changer le
la priorité d’un fichier CSS asynchrone ne peut avoir aucune incidence ici – je vais craquer
jusqu’à une anomalie dans les tests). Heureusement, première peinture enrichissante améliorée par
200ms
, la première police Web était 600 ms plus rapide, et visuellement complet était de 700 ms
plus rapide
.

preloadl’utilisation de Google Fonts est une bonne idée.

preconnect

La dernière pièce du puzzle que je voulais résoudre le voyage vers une autre origine.
Pendant que nous établissons un lien vers fonts.googleapis.com pour notre CSS, les fichiers de polices
eux-mêmes sont hébergés sur fonts.gstatic.com. Sur une connexion à latence élevée, cette
épelle de mauvaises nouvelles.

Les polices Google sont bonnes pour nous: elles preconnect le fonts.gstatic.com origine
à titre préventif via un en-tête HTTP attaché au fonts.googleapis.com réponse:

Bien que pas tout à fait efficace dans ces démos, je souhaite plus de tiers
les fournisseurs feraient des choses comme ça.

Cependant, l’exécution de cet en-tête est liée par le TTFB de la réponse, qui le
les réseaux à latence élevée peuvent être très, très élevés. Le TTFB médian (y compris la demande
file d’attente, DNS, TCP, TLS et heure du serveur) pour le fichier CSS Google Fonts sur
tous les tests étaient de 1406 ms. Inversement, le temps de téléchargement médian du fichier CSS était
seulement 9,5 ms – il a fallu 148 × plus de temps pour atteindre les en-têtes du fichier que pour
téléchargez le fichier lui-même.

Autrement dit: même si Google est preconnectdans le fonts.gstatic.com
d’origine pour nous, ils ne gagnent qu’une avance de 10 ms environ. Mettez un autre
façon, ce fichier est lié à la latence, non
lié à la bande passante
.

Si nous implémentons une première partie preconnect, nous devons nous tenir pour en faire de jolies
d’énormes gains. Voyons ce qui se passe.

Fragment:

 rel="preconnect"
      href="https://fonts.gstatic.com"
      crossorigin />

 rel="preload"
      as="style"
      href="$CSS&display=swap" />

 rel="stylesheet"
      href="$CSS&display=swap"
      media="print" onload="this.media='all'" />

Nous pouvons bien visualiser les avantages dans WebPageTest:

Découvrez à quel point nous pouvons faire progresser la connexion avec
preconnect.

Résultats – harry.is:

FPFCPFWFVCPhare
1,81,83.84.4100
Changement par rapport à la référence-1,6-2,8-0,6-0,6+2
Changement par rapport au précédent00-1,2-0,90

Résultats – CSS Wizardry:

FPFCPFWFVCPhare
1,91,93,53.699
Changement par rapport à la référence-1,5-2,4-0,9-0,8+3
Changement par rapport au précédent-0,1-0,1-0,8-0,7+1

Et c’est parti! La première peinture (satisfaisante) est pratiquement intacte. Tout changement
ici sont sans rapport avec notre preconnect au preconnect seulement des impacts
ressources après le chemin critique. Nous nous concentrons sur la première police Web et visuellement
complète, qui montrent tous deux une amélioration considérable. Amélioration de 800 à 1 200 ms par rapport à
première police web
et Amélioration de 700 à 900 ms visuellement complète contre notre
variante précédente, et Améliorations respectives de 600 à 900 ms et de 600 à 800 ms contre
notre référence. Les scores des phares sont plutôt bons à 100 et 99.

preconnecting fonts.gstatic.com est une bonne idée.

Prime: font-display: optional;

Utilisation de CSS asynchrone et font-display nous laisse sensibles au FOUT (ou,
si tout va bien, FOFT si nous avons conçu notre Fcorrectement). Pour essayer et
pour atténuer cela, j’ai décidé d’exécuter un test en utilisant font-display: optional;.

Cette variation indique au navigateur que les polices Web sont considérées comme facultatives, et si
nous ne pouvons pas mettre la main sur les fichiers de police pendant notre bloc extrêmement petit
période
alors nous vous proposons pas de période d’échange. Le résultat pratique est
que dans le cas où les polices Web prennent trop de temps à charger, cette page ne sera pas
l’utiliser du tout. Cela aide à empêcher le FOUT qui à son tour conduira à
une expérience plus stable pour votre utilisateur – il ne verra pas le style de texte à mi-chemin
grâce à leur page vue et un meilleur score de décalage de mise en page cumulé.

Cependant, cela s’est avéré systématiquement problématique lors de l’utilisation de CSS asynchrone. Quand
le print la feuille de style est transformée en all feuille de style, les mises à jour du navigateur
le CSSOM l’applique ensuite au DOM. En ce moment, la page lui est racontée
a besoin de quelques polices Web, et période de bloc extrêmement petite coups de pied dans,
montrant un FOIT au milieu du cycle de vie du chargement de page. Pour aggraver les choses, le
navigateur remplacera le FOIT par le même repli qu’il avait commencé, donc le
l’utilisateur ne bénéficie même pas d’une nouvelle police. Cela ressemble à un bug.

Il est beaucoup plus facile de le visualiser que de l’expliquer, alors voici une capture d’écran
de la pellicule:

Capture d'écran
montrant le texte manquant au milieu de deux chargements de page distincts.
Notez le FOIT à 3,4–3,5s et 3,2s respectivement.

Et une vidéo montrant le problème dans DevTools:

Je ne vois pas
vidéo? Cliquez ici.

Je ne recommanderais pas d’utiliser font-disply: optional; aux côtés asynchrone
CSS
; Je recommanderais d’utiliser asynchrone. Ergo, je ne recommanderais pas
font-display: optional;. Il est préférable dans l’ensemble d’avoir un CSS non bloquant avec
un FOUT que c’est d’avoir le FOIT inutile.

Comparaisons et visualisations

Dans ces vidéos au ralenti, vous pouvez voir les différences assez clairement.

harry.is

Je ne vois pas
la vidéo? Cliquez ici.
  • Async, preload, et preconnect tous commencent le rendu à 1,8 s.
    • Cela représente également leurs premières peintures riches en contenu – des informations utiles dans le
      premier rendu.
  • Héritage et swap les deux commencent le rendu à 3,4 s.
    • Bien que l’héritage manque de texte — FOIT.
  • preconnect charge sa police Web à 3,8 s.
    • Il est réputé visuellement complet à 4,4 secondes.
  • Legacy fait sa première peinture de polices Web content et première à 4,5 s.
    • Ils sont une seule et même chose car tout est synchrone.
  • Legacy est visuellement complet à 5 secondes.
  • Visuellement complet, Async arrive en 5.1s.
  • swap est réputé complet à 5.2s.
  • preload est réputé visuellement complet à 5.3s.

CSS Wizardry

Ne peut pas
voir la vidéo? Cliquez ici.

  • Async commence le rendu à 1,7 s.
  • preconnect commence le rendu à 1,9 s.
    • Sa première peinture riche en contenu est également de 1,9 s – informations utiles dans la première
      rendre.
  • preload commence le rendu à 2 s.
    • Sa première peinture contentieuse est également à 2s.
  • Async rend le contenu à 2,2 secondes.
  • Legacy commence le rendu à 3,4 s.
  • swap en fait la première et la première peinture satisfaisante à 3,6 s.
  • preconnect est réputé visuellement complet à 3,6 s.
  • Legacy fait sa première peinture content à 4.3s.
  • preload est visuellement complet à 4.3s.
  • L’héritage est considéré visuellement complet à 4.4s.
  • swap se termine à 4,6 s.
  • Async arrive en dernier à 5 secondes.

preconnect est le plus rapide sur toutes les métriques

Résultats

Bien que l’auto-hébergement de vos polices Web soit probablement la meilleure solution globale pour
problèmes de performances et de disponibilité, nous pouvons en concevoir
des mesures résistantes pour aider à atténuer un grand nombre de ces problèmes lors de l’utilisation de Google
Polices.

Une combinaison de chargement asynchrone de CSS, de chargement asynchrone de fichiers de polices,
opter pour FOFT, récupérer rapidement des fichiers CSS asynchrones et réchauffer les fichiers externes
domaines permet une expérience plusieurs secondes plus rapide que la ligne de base.

C’est quelque chose que je recommande fortement d’adopter si vous êtes un Google Fonts
utilisateur.

Si Google Fonts n’est pas votre seule ressource de blocage du rendu, si et vous êtes
violer l’un des autres principes pour rapide
CSS
(par exemple, si
tu es @importvotre fichier CSS Google Fonts), votre kilométrage variera.
Ces optimisations sont plus avantageuses sur le projet où Google Fonts pose
l’un de vos plus gros goulots d’étranglement en matière de performances.

Extrait Google Fonts Async

Il y a beaucoup de techniques combinées ici, mais le code résultant est encore mince
et suffisamment maintenable pour ne pas poser de problème. L’extrait ne fonctionne pas
besoin de se séparer et peuvent tous être maintenus ensemble dans le de votre
document.

Voici l’extrait optimal à utiliser pour les polices Google rapides:




 rel="preconnect"
      href="https://fonts.gstatic.com"
      crossorigin />


 rel="preload"
      as="style"
      href="$CSS&display=swap" />


 rel="stylesheet"
      href="$CSS&display=swap"
      media="print" onload="this.media='all'" />




☕️ Est-ce que cela a aidé? Achetez-moi un café!


Close Menu