När du kör en webbplats genom PageSpeed Insights är en av de vanligaste diagnoserna "Ensure text remains visible during webfont load." Problemet är bekant för alla som har installerat Elementor, Astra eller anslutit Google Fonts: medan webbläsaren laddar ner teckensnittsfilen är texten på sidan helt enkelt frånvarande. En vit skärm istället för en rubrik, bråkdels sekunder av tomhet, och besökaren har redan lämnat.

Tekniskt kallas detta FOIT (Flash of Invisible Text). Roten till problemet ligger i font-display-direktivet som webbläsaren använder som standard. Utan att uttryckligen ange font-display: swap väntar webbläsaren på att teckensnittet ska laddas och visar ingen text förrän filen har tagits emot. Och om teckensnittet laddas från ett CDN via en tredjepartsdomän ackumuleras fördröjningen, och PageSpeed Insights flaggar en varning.

Detta löses med två saker: för det första behöver varje @font-face få font-display: swap tillagt, så att webbläsaren omedelbart visar text i ett systemteckensnitt och "swappar" till det anpassade när det laddas. För det andra bör kritiskt viktiga teckensnitt (det som används för rubriken i första skärmbilden) förhandsladdas via <link rel="preload">. Nedan följer en steg-för-steg-genomgång av hur du gör detta i WordPress, med hänsyn till tillägg som Elementor och teman som Astra.

💡 Snabb översikt:

• Öppna PageSpeed Insights-rapporten och notera de problematiska teckensnitten från diagnostiken
• Inaktivera tilläggs- och temastilar via wp_dequeue_style i functions.php
• Kopiera teckensnittsfiler till en lokal mapp och återskapa font-face med font-display: swap
• Lägg till preload för ett eller två teckensnitt i första skärmbilden
• För Elementor-anpassade teckensnitt, ändra sökvägen till lokal och bygg om CSS

Steg 1: hitta de problematiska teckensnitten i rapporten

Kör en granskning på PageSpeed Insights, vänta på resultatet och hitta diagnostiksektionen. Vi letar efter punkten "Ensure text remains visible during webfont load."

Expandera listan för att se de specifika teckensnitts-URL:er som saknar font-display: swap. Vanligtvis är dessa:

• fontawesome-webfont.woff2, Font Awesome från Elementor;
• eicons.woff2, Elementors ikonteckensnitt;
• Google Fonts (Open Sans, Roboto, Montserrat), om temat hämtar dem via CDN.

Skriv ner filnamnen; de kommer att behövas för de följande stegen. Huvudsaken nu är att förstå vilket tillägg eller tema som är ansvarigt för varje teckensnitt. Font Awesome och eicons kommer från Elementor. Google Fonts ansluts oftast av temat; i Astra är detta astra-google-fonts-hooken.

Steg 2: inaktivera stilarna som laddar teckensnitt

Nu är uppgiften att ta bort standardanslutningen av dessa teckensnitt så att vi sedan kan ta tillbaka dem med rätt inställningar. Gå till barntemats functions.php (eller ett kodsnippets-tillägg som Code Snippets) och lägg till:

1
/**
2
 * Disable styles that load problematic fonts
3
 */
4
function sdstudio_dequeue_font_styles()
5
{
6
    // Astra — Google Fonts
7
    wp_dequeue_style('astra-google-fonts');
8
    wp_deregister_style('astra-google-fonts');
9
 
10
    // Elementor — Font Awesome 4
11
    wp_dequeue_style('font-awesome');
12
    wp_deregister_style('font-awesome');
13
 
14
    // Elementor — eicons
15
    wp_dequeue_style('elementor-icons');
16
    wp_deregister_style('elementor-icons');
17
}
18
add_action('wp_enqueue_scripts', 'sdstudio_dequeue_font_styles', 9999);
19
add_action('wp_head', 'sdstudio_dequeue_font_styles', 9999);

Prioriteten 9999 är viktig: hooken måste köras EFTER att tillägg och temat har registrerat sina stilar. Om teckensnittet fortfarande laddas, kontrollera om ett annat tillägg anropar det (till exempel kan en meny eller ett kontaktformulär ansluta sin egen version av Font Awesome). Sök i tilläggsfilerna efter strängen wp_enqueue_style med motsvarande handle.

Efter att ha lagt till koden kommer Font Awesome-ikonen på webbplatsen tillfälligt att försvinna; detta är normalt. Vi tar tillbaka den i steg 4.

Steg 3: kopiera teckensnittsfiler till en lokal mapp

När ett teckensnitt ansluts via CDN eller genom ett tillägg gör webbläsaren en extra DNS-förfrågan till en tredjepartsdomän. Lokal teckensnittslagring tar bort denna fördröjning. Algoritmen:

• Hitta teckensnittsfilerna i tilläggsstrukturen. För Font Awesome från Elementor blir sökvägen: /wp-content/plugins/elementor/assets/lib/font-awesome/fonts/. För eicons: /wp-content/plugins/elementor/assets/lib/eicons/fonts/. För Google Fonts, ladda ner .woff2 från Google Fonts CDN.

• Skapa en mapp /wp-content/fonts/ i webbplatsens rot och kopiera alla nödvändiga filer dit. Formaten .woff2 (moderna webbläsare) och .woff (fallback för äldre) räcker.

• Om teckensnittet anslöts av temat via Google Fonts CDN, ladda ner aktuell .woff2 manuellt via en direktlänk eller med hjälp av OMGF-tillägget (mer om det nedan).

Nu har varje teckensnitt en lokal sökväg som /wp-content/fonts/fontawesome-webfont.woff2. Låt oss gå vidare till den viktigaste delen: att ansluta dem.

Steg 4: anslut teckensnitt med font-display: swap och preload

Stilar är inaktiverade, filer är på plats. Nu definierar vi @font-face med rätt font-display: swap-direktiv och lägger till preload för omedelbar laddning. Placera koden i functions.php via wp_head-hooken:

1
/**
2
 * Load fonts locally with font-display: swap and preload
3
 */
4
function sdstudio_inject_font_preload()
5
{
6
    ?>
7
    <!-- Preload critical fonts -->
8
    <link rel="preload" href="/wp-content/fonts/fontawesome-webfont.woff2" as="font" type="font/woff2" crossorigin="anonymous">
9
    <link rel="preload" href="/wp-content/fonts/eicons.woff2" as="font" type="font/woff2" crossorigin="anonymous">
10
 
11
    <style>
12
        /* Font Awesome — icon font */
13
        @font-face {
14
            font-family: 'FontAwesome';
15
            font-display: swap;
16
            font-style: normal;
17
            font-weight: normal;
18
            src: url('/wp-content/fonts/fontawesome-webfont.woff2') format('woff2'),
19
                 url('/wp-content/fonts/fontawesome-webfont.woff') format('woff');
20
        }
21
 
22
        /* eicons — Elementor icons */
23
        @font-face {
24
            font-family: 'eicons';
25
            font-display: swap;
26
            font-style: normal;
27
            font-weight: normal;
28
            src: url('/wp-content/fonts/eicons.woff2') format('woff2'),
29
                 url('/wp-content/fonts/eicons.woff') format('woff');
30
        }
31
    </style>
32
    <?php
33
}
34
add_action('wp_head', 'sdstudio_inject_font_preload', 5);

Prioritet 5 i wp_head innebär att preload-taggar kommer att visas i <head> bland de första, så att webbläsaren börjar ladda ner teckensnittet innan den når CSS:en. Attributet crossorigin="anonymous" är obligatoriskt för förhandsladdning av teckensnitt: utan det kommer webbläsaren att ignorera preload och ladda ner filen igen.

En viktig nyans: URL:en inuti @font-face bör inte ha frågeparametrar som ?#iefix eller ?v=4.7.0. PageSpeed Insights snubblar på dem under analysen. Länken ska vara ren: /wp-content/fonts/fontawesome-webfont.woff2, och inget mer.

Efter att ha lagt till koden, rensa cachen (cachingtillägg + Cloudflare, om det används) och kör PageSpeed Insights igen. Teckensnittsvarningen bör försvinna. Font Awesome-ikonerna återvänder till sina platser, men nu blockerar de inte textvisning.

Steg 5: Elementor anpassade teckensnitt, ett specialfall

Om du använder Elementor Pro med funktionen "Anpassade teckensnitt" är logiken densamma, men det finns två ytterligare steg.

Först, ändra teckensnittssökvägen i Elementor-inställningarna. Gå till Elementor → Anpassade teckensnitt, öppna önskat teckensnitt och ange i URL-fältet den lokala sökvägen /wp-content/fonts/your-font.woff2 istället för en extern CDN- eller Google Fonts-länk:

För det andra, bygg om Elementor CSS. Efter att ha ändrat sökvägen, gå till Elementor → Verktyg → Återskapa CSS och klicka på återskapningsknappen. Detta tvingar Elementor att bygga om stilfiler med de nya teckensnittssökvägarna:

Efter återskapandet, verifiera att teckensnittssökvägen i sidans HTML leder till den lokala filen, inte CDN. Lägg sedan till preload för detta teckensnitt i header.php (eller via wp_head som i steg 4):

1
<link rel="preload" href="/wp-content/fonts/FuturaBookC.woff2" as="font" type="font/woff2" crossorigin="anonymous">

Och motsvarande @font-face med font-display: swap:

1
@font-face {
2
    font-family: 'FuturaBookC';
3
    font-display: swap;
4
    font-style: normal;
5
    font-weight: normal;
6
    src: url('/wp-content/fonts/FuturaBookC.woff2') format('woff2'),
7
         url('/wp-content/fonts/FuturaBookC.woff') format('woff');
8
}

Alternativ väg: tillägg för automatisk optimering

Den manuella metoden ger full kontroll men kräver uppmärksamhet vid uppdatering av tillägg (en Elementor-uppdatering kan återställa standardanslutningen av teckensnitt). Om du vill automatisera processen finns här två tillägg som löser uppgiften utan kodredigering.

OMGF (Optimize My Google Fonts). Ett gratis tillägg som skannar alla Google Fonts på webbplatsen, laddar ner dem lokalt och lägger till font-display: swap automatiskt. Installera det, klicka på "Optimera", så blir alla ditt temas Google Fonts lokala med korrekta headers. Pro-versionen kan arbeta med Adobe Fonts och alla tredjeparts CDN-teckensnitt.

Swap Google Fonts Display. Ett minimalistiskt tillägg som gör exakt en sak: lägger till font-display: swap till alla Google Fonts i farten. Det laddar inte ner lokalt men tar bort PageSpeed Insights-varningen på 10 sekunders installation. Lämpligt som en tillfällig lösning eller om lokal teckensnittslagring inte är kritisk.

Tillägg sparar tid, men kom ihåg: de fungerar bara med Google Fonts. Ikonteckensnitt (Font Awesome, eicons) och Elementor anpassade teckensnitt berörs inte; du kommer fortfarande att behöva gå igenom manuella steg 1-5.

⁉️🤔 Vanliga frågor

Behöver jag förhandsladda ALLA teckensnitt på webbplatsen?

Nej. <link rel="preload"> är bara meningsfullt för ett eller två teckensnitt som visas i första skärmbilden, till exempel teckensnittet för H1-rubriken och huvudtextteckensnittet. Att förhandsladda ett dussin teckensnitt får motsatt effekt: webbläsaren lägger bandbredd på filer som inte behövs just nu och saktar ner laddningen av kritiskt innehåll. Förhandsladda endast teckensnitt som används i den första viewporten. För en typisk blogg är detta ett rubrikteckensnitt och ett textteckensnitt, totalt två woff2-filer. Att förhandsladda ett ikonteckensnitt är bara värt det om en ikon visas i första skärmbilden (meny, sök). Allt annat laddas medan du scrollar utan att skada PageSpeed-mätvärdena.

Vad händer om webbplatsen "går sönder" efter att stilarna inaktiverats?

Det vanligaste scenariot: du inaktiverade elementor-icons, och skjutreglagets pilar eller sökikonen försvann. Lösningen är att kontrollera vilka specifika element som använder teckensnittet innan du inaktiverar. Öppna DevTools (F12), fliken Elements, hitta ikonen och titta på CSS-klassen. Om klassen börjar med fa- är det Font Awesome. Om med eicon- är det eicons. Inaktivera bara det som faktiskt används, och anslut samma filer lokalt; visuellt kommer ingenting att förändras. Webbplatsen "går sönder" i två fall: antingen inaktiverade du en stil som, förutom teckensnittet, bar CSS-regler (sällsynt men händer med teman som Astra), eller så återanslöt du inte teckensnittet lokalt. I det första fallet, extrahera CSS-reglerna från den inaktiverade filen och kopiera dem till ditt wp_head-block. I det andra fallet, lägg helt enkelt till den saknade @font-face.

Fungerar denna metod för alla WordPress-teman?

Ja, med reservationer. Principen dequeue style → local fonts → font-display: swap → preload är universell. Endast stilhandtagen ändras: för Astra är det astra-google-fonts, för GeneratePress är det generate-fonts, för OceanWP är det oceanwp-google-fonts. För att hitta ditt temas handle, öppna sidkällan (Ctrl+U), hitta <link rel="stylesheet" med teckensnittet och titta på taggens id; detta är handtaget. Ersätt det sedan i wp_dequeue_style. Moderna teman (2024-2026) lägger allt oftare till font-display: swap direkt: Twenty Twenty-Five och blockteman baserade på theme.json har redan denna inställning. Innan du redigerar kod, kontrollera om ditt tema redan gör allt korrekt och varningen endast orsakas av ett ikonteckensnitt från ett separat tillägg.

Är det obligatoriskt att kopiera teckensnitt lokalt?

Tekniskt sett, nej. font-display: swap fungerar även med teckensnitt anslutna via CDN (Google Fonts, cdnjs). Men lokal lagring ger två fördelar: för det första tar du bort en extra DNS-förfrågan till en tredjepartsdomän (sparar 50-200 ms), och för det andra är du inte beroende av CDN:ets tillgänglighet. Om Google Fonts går ner kommer din webbplats att förbli med läsbar text. För en produktionswebbplats är lokal lagring bästa praxis; för ett hobbyprojekt är det valfritt. Undantag: ikonteckensnitt. Font Awesome, eicons och dashicons laddas från tillägget (lokalt per definition); att kopiera dem till rotmappen behövs bara för att "fånga upp" laddningskontrollen efter dequeue. Själva filen finns redan fysiskt på servern.

Vad du ska göra åt teckensnittsvarningen: den slutliga algoritmen

Gå igenom de fem stegen i denna guide, så försvinner varningen "Ensure text remains visible during webfont load" från PageSpeed Insights-rapporten. Kortfattat: inaktivera standardanslutningen → placera teckensnitt lokalt → ta tillbaka dem med font-display: swap → förhandsladda kritiska woff2 → för Elementor, ändra dessutom sökvägen och bygg om CSS. Som ett resultat är text på webbplatsen synlig omedelbart, LCP- och FCP-mätvärden förbättras, och besökaren ser inte en "hoppande" sida.

Om du inte vill gräva i kod, börja med OMGF-tillägget för Google Fonts. För ikonteckensnitt finns det inget tillägg som är ett "mirakelpiller"; du kommer fortfarande att behöva bearbeta dem manuellt, men det är 20 minuters arbete som lönar sig med högre PageSpeed-poäng och verkliga förbättringar av laddningshastigheten. Prova och testa efter varje ändring; endast en upprepad granskning kommer att visa att problemet faktiskt är löst.