Sådan indlæses webskrifttyper for at undgå præstationsproblemer og fremskynde sideindlæsning

Brugerdefinerede webskrifttyper bruges overalt i verden, men mange (åh så mange) sider indlæser dem forkert. Dette medfører mange problemer for sideindlæsning som ydeevneproblemer, langsom indlæsningstid, blokeret gengivelse og ombyttede skrifttyper under navigation.

Jeg ser mange udviklere ignorere disse problemer eller måske lave de samme fejl igen og igen bare fordi "de altid har gjort det", men som webudviklere skal vi være i stand til at tilpasse os i et konstant skiftende miljø.

Det er tid til at bryde denne løkke og begynde at gøre det rigtige i 2019. Der er kun fire trin at overveje, når du indlæser en brugerdefineret webskrifttype:

  • Brug det korrekte skrifttypeformat
  • Forudindlæs skrifttyper
  • Brug den korrekte font-face-erklæring
  • Undgå usynlig tekst under indlæsning af skrifttype.

Lad os nedbryde disse punkter ad gangen.

Brug det korrekte skrifttypeformat

Der er mange skrifttypeformater, der kan bruges på internettet, men kun to formater er virkelig nødvendige, hvis du ikke behøver at understøtte Internet Explorer (IE) 8 eller lavere: woff og woff2 . Dette er de eneste to filtyper, du skal bruge, fordi de som standard er komprimeret i gzip-format (så de er meget små), er optimeret til internettet og understøttes fuldt ud af IE 9+ og alle andre stedsegrønne browsere.

Forudindlæs skrifttyper

Når du bruger tilpassede skrifttyper, skal du bede browseren om at indlæse dem på forhånd ved hjælp af det relevante rel=""tag og attributter:

Bemærk, at brugen af ​​crossorigin her er important; uden denne attribut ignoreres den forudindlæste skrifttype af browseren, og en ny hentning finder sted. Dette skyldes, at skrifttyper forventes hentet anonymt af browseren, og anmodningen om forudindlæsning kun gøres anonym ved hjælp af denne attribut.

I ovenstående eksempel rel="preload" as="font"beder attributter browseren om at begynde at downloade den krævede ressource så hurtigt som muligt. De fortæller også browseren, at dette er en skrifttype, så den passende kan prioritere den i dens ressourcekø. Brug af forudindlæste tip vil have en dramatisk indvirkning på webskrifttypens ydeevne og den indledende sideindlæsning. Browsere, der understøtter forudindlæsning og forudindhentningstips, begynder at downloade webfonte, så snart de har set hintet i HTML-filen og ikke længere behøver at vente på CSS.

Du kan i stedet bruge rel="prefetch"attributten til at fortælle browseren at forberede download af de ressourcer, der muligvis kræves senere under sideindlæsning eller brugerhandlinger, så den tildeler disse ressourcer en lav prioritet.

ADVARSEL:

Hvis du bruger et CDN som Google Fonts, skal du sørge for, at de skrifttypefiler, du forudindlæser, stemmer overens med dem i CSS. Skrifttyper kan også opdateres regelmæssigt, og hvis du forudindlæser en gammel version, mens du bruger CSS til en nyere, kan du ende med at downloade to versioner af den samme skrifttype og spilde dine brugers båndbredde. Overvej at bruge ??‍? instead for easier maintenance.

Correct font-face declaration

Declaring a font-face family is very simple but we must take care with certain things when we do it. Here a correct example declaring a custom font family:

@font-face { font-family: 'Custom Font'; font-weight: 400; font-style: normal; font-display: swap; /* Read next point */ unicode-range: U+000-5FF; /* Download only latin glyphs */ src: local('Custom Font'), url('/fonts/custom-font.woff2') format('woff2'), url('/fonts/custom-font.woff') format('woff');}

Here’s the Unicode range from Google Web Fundamentals.

As you can see we use only optimised fonts (woff and woff2) and we tell the browser to load only the required glyphs range (from U+000 to U+5FF), but this property doesn’t prevent browsers to download the entire font. There are also two more things to note, the local() function and the font declaration order.

The local() function allows users to use their local copy of the font if present (e.g. think about the Roboto fonts that are pre-installed on Android) instead of downloading it.

The font declaration order is also important because the browser will start fetching the resources by following the declaration order. If it supports the woff2 format it will download the font, or if it doesn’t recognise the resource format it will proceed to the next one, and so on.

If you really want to use eot and ttf fonts make sure to add them at the end of the src declaration.

Resources

  • Glyphs range generator by Eli Fitch
  • Modern Font Face generator

Avoid invisible text during font loading

Fonts are often large files that take a while to load even when gzipped. To deal with this, some browsers hide text until the font loads (the “flash of invisible text”). You can avoid the “flash” and show content to users immediately using a system font initially, then replacing it.

In the previous @font-face example you’ll notice the font-displaydeclaration. The swap value tells the browser that text using this font should be displayed immediately using a system font. Once the custom font is ready, the system font is swapped out.

If a browser does not support font-display it continues to follow its default behaviour for loading fonts.

Browser default behaviours if a font is not ready:

Edge uses a system font until the custom font is ready, then swaps out fonts.

Chrome will hide text for up to 3 seconds. If text is still not ready, it will use a system font until the custom font is ready.

Firefox will hide text for up to 3 seconds. If text is still not ready, it will use a system font until the custom font is ready.

Safari hides text until the custom font is ready.

Testing

The following links test the “standard version” against the optimised one:

  • Standard
  • Optimised

Results

Conclusion

Considering such basic optimisations will improve the general UX of your digital product. We must account for situations where the connection speed is not optimal or when people don’t have time to wait several seconds while your app/site is being completely loaded and navigable.

Such improvements, especially for large projects, are mandatory for improving overall user experience, and they really don’t require a lot of effort.

We must work together in trying to fix the web.

Follow my blog at:

Mattia Astorino

Web Developer, CSS/HTML ninja in Monza. Member of Open Source Design.equinsuocha.io