Har du problem med kumulativa layoutförskjutningar på din webbplats? Eller är du inte säker på vad detta betyder?

Kumulativa layoutförskjutningar, eller CLS, är ett mått som ingår i Google’s initiativ Core Web Vitals.

Man kan kortfattat säga att det mäter hur mycket av innehållet på en webbsida som flyttas ”oväntat”. En hög CLS-poäng kan tyda på en dålig användarupplevelse och kan även vara förödande när det gäller din webbplats SEO.

I det här inlägget så får du veta allt som du behöver veta om kumulativ layoutförskjutning och hur det påverkar WordPress-webbplatser (och webben i allmänhet).

Vad är Kumulativa layoutförskjutningar (CLS)?

Kumulativa layoutförskjutningar är måttet på hur mycket en sida på din webbplats oväntat flyttas runt under en användares besök, vilket mäts av Layout Instability API, ett standardiserat API för prestandatestning.

Kumulativa layoutförskjutningar (CLS) är ett av de tre mätvärdena i Google’s initiativ Core Web Vitals, tillsammans med Largest Contentful Paint (LCP) och First Input Delay (FID).

För att förstå innebörden av Kumulativa layoutförskjutningar så är det viktigt att diskutera layoutförskjutning i allmänhet.

En layoutförskjutning inträffar när innehållet på din webbplats ”flyttas” eller ”förskjuts” oväntat.

Eller, i tekniska termer, när ett element som är synligt i visningsfönstret ändrar sin startposition mellan två ramar.

Ett vanligt exempel är att du håller på att läsa ett textblock. Då dyker det plötsligt upp en annons som laddas sent och flyttar textinnehållet nedåt på sidan.

Här är en annan exempelbild från Google som visar hur det här går till:

Ett exempel på kumulativ layoutförskjutning från Google.
Ett exempel på kumulativ layoutförskjutning från Google.

Du har säkert stött på layoutförskjutningar när du har surfat runt på webben, även om du inte känner till dem under det namnet.

Vid ett enda besök så kan det förekomma flera separata layoutförskjutningar. Det kumulativa måttet för layoutförskjutningar syftar till att fånga hela bilden genom att mäta det totala antalet oväntade layoutförskjutningar på en sida*.

*Det exakta måttet är lite mer tekniskt efter vissa ändringar av Google, men det är fortfarande den grundläggande idén. Om du är intresserad av de små detaljerna så kan du läs om detta här.

Varför är kumulativ layoutförskjutning dåligt?

Huvudskälet till att Kumulativa layoutförskjutningar är dåligt är att det skapar en dålig användarupplevelse på din webbplats.

I bästa fall så är det lätt irriterande för dina besökare. I värsta fall så kan det få besökare att utföra åtgärder som de inte vill utföra.

Tänk dig exempelvis att en användare vill klicka på ”Avbryt” men råkar klicka på ”Bekräfta” eftersom en layoutförskjutning har flyttat knapparnas position just när personen klickar.

Förutom att det påverkar besökarnas upplevelser så kan dåliga resultat för kumulativa layoutförskjutningar även försämra webbplatsens placering i sökmotorerna.

Från och med Google’s uppdatering Page Experience (som avslutades i augusti år 2021) så använder Google Core Web Vitals som en av sina SEO-rankningsfaktorer. Eftersom Kumulativa layoutförskjutningar är en del av Core Web Vitals så betyder detta att det kan påverka din webbplats sökprestanda.

Om du åtgärdar eventuella problem med Kumulativa layoutförskjutningar på din webbplats så kan du göra den bättre för både mänskliga besökare och sökmotorer.

Så – vad kan orsaka Kumulativa layoutförskjutningar? Det tar vi upp härnäst..

Vad orsakar Kumulativa layoutförskjutningar?

Här är en snabb genomgång av de vanligaste orsakerna till layoutförskjutning:

  • Du ställer inte in dimensioner för bilder, iframes, videor eller andra inbäddningar.
  • Problem med laddning av anpassade typsnitt, vilket kan leda till att text blir osynlig eller ändrar storlek när anpassade typsnitt laddas in.
  • Servering av responsiva annonser (t.ex. AdSense) med olika storlekar (och att det inte finns något reserverat utrymme för dessa annonser).
  • Dynamiskt innehåll med plugins (meddelanden om samtycke till cookies, formulär för leadgenerering osv.)
  • Användning av animationer utan CSS-egenskapen Transform.

Vi kommer att gå in på dessa problem mycket djupare senare i det här inlägget. Du kommer då att få veta hur du löser varje vanligt problem.

Hur man mäter kumulativ layoutförskjutning: Bästa testverktyg

Det finns ett antal verktyg som du kan använda för att testa din webbplats poäng för Kumulativ layoutförskjutning.

Kumulativ layoutförskjutning är en del av Lighthouse-granskningen, så alla hastighetstestverktyg som använder Lighthouse som en del av sin granskning kommer att innehålla CLS-data – detta inkluderar PageSpeed Insights, GTmetrix, Chrome Developer Tools och många andra populära testverktyg.

Här är några av de bästa testverktygen för Kumulativ layoutförskjutning som utmärker sig för sin användbarhet..

PageSpeed Insights

PageSpeed Insights är ett av de mest användbara verktygen för att bedöma läget för layoutförskjutningen på din webbplats eftersom det ger dig två datakällor:

  • Fältdata – riktiga användardata från Chrome UX-rapporten (förutsatt att din webbplats har tillräckligt mycket trafik för att ingå i rapporten). På så sätt kan du se de faktiska uppgifterna om Kumulativ layoutförskjutning för dina verkliga mänskliga besökare. Detta är även de data som Google använder som en rankningssignal.
  • Labdata – simulerade testdata som samlas in av Lighthouse (som PageSpeed Insights använder för att generera sina rapporter för prestandaanalys).

Du kan även visa data för både dator och mobil genom att växla mellan flikarna.

Resultat för Kumulativ layoutförskjutning i PageSpeed Insights.
Resultat för Kumulativ layoutförskjutning i PageSpeed Insights.

Observera – laboratoriedata kan endast mäta layoutförskjutningar som sker under sidladdningen. Dina resultat för riktiga användare kan med andra ord vara något högre om du har layoutförskjutningar som sker efter sidladdningen.

Verktyg för Chrome-utvecklare

Chrome Developer Tools erbjuder några användbara resurser för att både mäta CLS och felsöka enskilda layoutförskjutningar som sker på din webbplats.

För det första så kan du köra en Lighthouse-granskning för att se webbplatsens CLS-poäng. Så här gör du:

  1. Öppna Chrome Developer Tools.
  2. Gå till fliken Lighthouse.
  3. Konfigurera ditt test.
  4. Klicka på knappen Analysera sidladdning för att köra testet.

Efter en kort väntan så bör du se det vanliga gränssnittet för en Lighthouse-granskning (som ser ut ungefär som PageSpeed Insights).

Så här kör du en Lighthouse-granskning i Developer Tools.
Så här kör du en Lighthouse-granskning i Developer Tools.

Med Chrome Developer Tools så kan du dock även gräva djupare i CLS med dess Renderings-analys. Du kan på så sätt markera enskilda områden med layoutförskjutningar på din webbplats, vilket hjälper dig att felsöka dem.

Så här gör du:

  1. Klicka på ikonen med de ”tre prickarna” i det övre högra hörnet av gränssnittet för Chrome Developer Tools.
  2. Välj Fler verktyg Rendering, vilket bör öppna ett nytt gränssnitt längst ner.
  3. Markera rutan för Platser med layoutförskjutningar.
Hur du visar CLS-rendering i Developer Tools.
Hur du visar CLS-rendering i Developer Tools.

Ladda nu om sidan som du vill testa så bör Chrome markera eventuella områden med layoutförskjutningar med en blå ruta. Dessa markeringar kommer att visas på den aktuella sidan när innehållet laddas och försvinner när förskjutningen är klar.

Om markeringarna visas för snabbt för att du ska kunna följa dem så kan du sakta ner din webbplats och titta på när den laddas ram för ram med hjälp av fliken Prestanda.

Google Search Console

Google Search Console låter dig inte köra labbtester för att fastställa Kumulativa layoutförskjutningar, men ger dig ett enkelt sätt att se problem med detta på din webbplats, enligt mätningen i Chrome UX-rapporten.

Fördelen med att använda Google Search Console framför andra verktyg är att du snabbt kan se problem på hela webbplatsen i stället för att testa sida för sida.

Så här visar du potentiella problem på din webbplats:

  1. Gå till Google Search Console. Om du ännu inte har verifierat din webbplats så kan du följa vår guide om hur du verifierar Google Search Console.
  2. Öppna rapporten Core Web Vitals under Upplevelse.
  3. Klicka på Öppna rapport bredvid Mobil eller Skrivbord, beroende på vad du vill analysera.
Rapporten Core Web Vitals i Search Console.
Rapporten Core Web Vitals i Search Console.

Om det är tillämpligt så kommer Google att lyfta fram webbadresser med problematiska resultat för Kumulativ layoutförskjutning.

Så här ser du webbadresser med CLS-problem i Search Console.
Så här ser du webbadresser med CLS-problem i Search Console.

Obs – du ser bara data här om din webbplats har tillräckligt med trafik månadsvis för att ingå i Chrome UX-rapporten.

GIF-generator för layoutförskjutning

Som namnet antyder så genererar Layout Shift GIF Generator en GIF av layoutförskjutningarna på din webbplats så att du kan se exakt vilket innehåll som orsakar problem. Du får även ditt resultat, även om det inte är verktygets huvudfokus.

Allt du gör är att lägga till den webbadress som du vill testa och väljer mellan mobil eller dator. Det genereras sedan en GIF-film av din webbplats med gröna markeringar som visar exakt vilka element som förskjuts.

Genom att se vilka element som flyttas runt och bidrar till din Kumulativa layoutförskjutnings-poäng så kan du veta exakt vad du ska fokusera på när det gäller att förbättra din webbplats poäng.

Verktyget markerar enskilda layoutförskjutningar i grönt.
Verktyget markerar enskilda layoutförskjutningar i grönt.

Vad är ett bra resultat för kumulativ layout?

Enligt Google’s initiativ Core Web Vitals så är ett bra resultat för Kumulativa layoutförskjutningar 0,1 eller mindre.

Om ditt resultat för kumulativ layoutförskjutning ligger mellan 0,1 och 0,25 så definierar Google detta som ”behöver förbättras”.

Och om din Kumulativa layoutförskjutnings-poäng är över 0,25 definierar Google den som ”dålig”.

Här är en grafik från Google’s webbplats Core Web Vitals som visar dessa poäng visuellt:

Google's rekommendationer för CLS-poäng.
Google’s rekommendationer för CLS-poäng.

Så här åtgärdar du Kumulativa layoutförskjutningar i WordPress (eller på andra plattformar)

Nu när du förstår vad som händer med Kumulativa layoutförskjutningar så är det dags att gå över till några användbara tips om hur du åtgärdar detta i WordPress.

Även om de här tipsen kommer från en WordPress-vinkel så är alla universella och du kan tillämpa dem på andra verktyg för byggande av webbplatser.

Ange alltid dimensioner för bilder

En av de vanligaste orsakerna till layoutförskjutning är sent laddade bilder som flyttar runt innehållet, särskilt om du använder en taktik som lat laddning.

För att undvika detta så kan du ange en bilds dimensioner i koden när du bäddar in den. På så sätt kommer besökarens webbläsare att reservera det utrymmet även om bilden ännu inte har laddats, vilket innebär att bilden inte behöver flytta runt innehållet.

Om du bäddar in bilder via WordPress-redigeraren (antingen Gutenberg’s blockredigerare eller den klassiska TinyMCE-redigeraren) så behöver du inte ange bilddimensionerna manuellt, eftersom WordPress gör detta åt dig automatiskt.

Samma sak gäller för populära plugins för sidbyggare som Elementor, Divi, Beaver Builder och så vidare.

Det kan dock uppstå problem om du bäddar in bilder manuellt med hjälp av din egen kod, vilket kan hända om du lägger till innehåll till ett plugin, redigerar mallfilerna för ditt barntema och så vidare.

HTML-koden för en grundläggande bildinbäddning ser ut så här:

<img src="https://kinsta.com/example-image.jpg" alt="An example image">

För att specificera dess dimensioner så kan du lägga till parametrar för höjd och bredd. Här är ett exempel på hur det kan se ut för en bild på 600x300px:

<img src="https://kinsta.com/example-image.jpg" alt="An example image" width="600" height="300">

Många prestandaplugins för WordPress inkluderar även funktioner för att automatisera detta, t.ex. funktionerna Lägg till saknade bilddimensioner i WP Rocket eller Perfmatters.

Ange alltid dimensioner för videor, iframes och andra inbäddningar

Precis som för bilder så bör du även ange dimensioner när du lägger till videor, iframes eller andra inbäddningar.

De flesta webbplatsers inbäddningsverktyg bör ange dimensioner för inbäddningen automatiskt.

Om du exempelvis tittar på YouTube-inbäddningskoden så ser du att den inkluderar dimensioner:

Ett exempel på iframe-dimensionerna i inbäddningskoden.
Ett exempel på iframe-dimensionerna i inbäddningskoden.

Samma sak gäller för många andra tjänster.

Om din inbäddningskod inte anger höjd och bredd så kan du dock lägga till dessa dimensioner manuellt i inbäddningskoden.

Fixa och optimera laddning av teckensnitt

Problem med laddning och optimering av typsnitt kan vara en annan vanlig källa till layoutförskjutningar via två potentiella problem:

  • Blixt av osynlig text (FOIT) – sidan laddas initialt utan att något textinnehåll visas överhuvudtaget. När det anpassade teckensnittet laddas så visas plötsligt texten (vilket kan leda till att befintligt innehåll förskjuts).
  • Blixt av ostylerad text (FOUT) – textinnehållet laddas med ett systemtypsnitt (utan stil). När det anpassade typsnittet laddas ändras texten till det anpassade typsnittet. Detta kan leda till att innehållet förskjuts eftersom textstorleken och avståndet kan vara annorlunda.

För att undvika dessa problem så måste du optimera hur du laddar typsnitt på din webbplats (vilket även kan ha vissa fördelar för webbplatsens prestanda).

Hosta teckensnitt lokalt och ladda teckensnitt i förväg

Genom att hosta teckensnitt lokalt och använda förladdning så talar du om för besökarnas webbläsare att de ska ha en högre prioritering av laddning av anpassade teckensnittsfiler.

Genom att ladda teckensnittsfiler före andra resurser så kan du se till att teckensnittsfilerna redan är inlästa när webbläsaren börjar rendera ditt innehåll, vilket kan förhindra problem med FOUT och FOIT.

Om du vill veta hur du hostar teckensnitt lokalt i WordPress så kan du läsa vår fullständiga guide för att hosta teckensnitt lokalt i WordPress.

Därifrån så kan du ställa in förladdning av teckensnitt manuellt eller med hjälp av ett plugin. De flesta prestanda-plugins inkluderar alternativ för förladdning av teckensnitt, inklusive WP Rocket, Perfmatters, Autoptimize och andra.

Om du använder Google Fonts så kan du även använda det kostnadsfria OMGF-pluginet för att hosta teckensnitten lokalt och ladda dem i förväg.

Du kan även förinstallera teckensnitten manuellt genom att lägga till koden i <head>-avsnittet på din webbplats.

Här är ett exempel på koden – se till att du ersätter den med det faktiska namnet/platsen för den teckensnittsfil som du vill ladda in i förväg:

<link rel="preload" href="https://kinsta.com/fonts/roboto.woff2" as="font/woff2" crossorigin>

Du kan lägga till den direkt med hjälp av ett WordPress-barntema eller injicera den med wp_head-haken och ett plugin som Code Snippets.

Ställ in Font-Display till Valfritt eller Byte

Med CSS-egenskapen Font-Display så kan du styra renderingsbeteendet för teckensnitten på din webbplats och undvika FOIT.

Du kan i princip använda ett reservtypsnitt i situationer där ditt anpassade typsnitt inte har laddats ännu.

Det finns två huvudalternativ som du kan använda för att hantera CLS:

  • Byte – använder ett reservtypsnitt medan det anpassade typsnittet laddas och byter sedan till ditt anpassade typsnitt när typsnittet laddas.
  • Valfritt – låter webbläsaren avgöra om ett anpassat typsnitt ska användas eller inte baserat på besökarens anslutningshastighet.

Med Byte så byter webbläsaren alltid till det anpassade teckensnittet när det laddas.

Byte löser FOIT helt och hållet, men kan leda till FOUT. För att minimera detta så bör du se till att reservtypsnittet använder samma avstånd som det anpassade typsnittet (åtminstone så mycket som möjligt). Det kommer på så sätt inte att leda till layoutförskjutningar, även om typsnittsstilen ändras, eftersom avståndet kommer att vara detsamma.

Med Valfritt låter webbläsaren det anpassade teckensnittet laddas i 100 ms. Om det anpassade teckensnittet inte finns tillgängligt då kommer webbläsaren att använda reservteckensnittet och aldrig ändra det till det anpassade teckensnittet för den sidvisningen (det anpassade teckensnittet kommer att användas för efterföljande sidvisningar, eftersom det är troligt att teckensnittsfilen har laddats ner och lagrats i cacheminnet vid det laget).

Valfritt kan både lösa FOIT och FOUT, men nackdelen är att besökaren kan fastna med reservtypsnittet för sin första sidvisning.

Om du känner dig bekväm med att arbeta med CSS så kan du redigera Font-Display-egenskapen manuellt i stilarket för ditt barntema.

Om du inte känner dig bekväm med att göra detta så kan du även hitta några plugins som hjälper dig:

  • Swap Google Fonts Display – aktiverar enkelt byte av teckensnittsvisning för Google Fonts.
  • Asset CleanUp – stöder Google Fonts kostnadsfritt och anpassade lokala typsnitt med Pro-versionen.
  • Perfmatters – erbjuder en funktion för Google Fonts.

Om du använder Elementor så har Elementor också ett inbyggt alternativ för att göra detta. Gå till Elementor → Inställningar → Avancerat. Du kan sedan ställa in rullgardinsmenyn Google Fonts Laddning till Byte eller Valfritt enligt dina önskemål:

Elementor's alternativ för visning av teckensnitt.
Elementor’s alternativ för visning av teckensnitt.

För komplicerat? Överväg en systemteckensnitts-stack!

Om allt detta prat om förladdning och Font-Display är lite förvirrande så är en enkel lösning att bara använda en systemteckensnitts-stack i stället för en anpassad teckensnitts-stack.

Detta begränsar visserligen dina designalternativ, men löser helt och hållet problemen när det gäller teckensnitt med kumulativ layoutförskjutning, FOIT och FOUT. Din webbplats kommer dessutom att laddas mycket snabbare.

Om du är intresserad av det här så kan du läsa Brians guide om hur man använder en systemteckensnitts-stack i WordPress.

Reservera plats för annonser (om du använder Display Annonser)

Om du använder displayannonser så är det viktigt att du reserverar utrymme för dessa annonser i koden för din webbplats. Detta följer samma idé som att reservera utrymme för bilder, videor och inbäddningar.

Displayannonser förtjänar dock ett särskilt omnämnande eftersom det är mycket vanligt att displayannonser laddas sent om du använder någon typ av budgivningsteknik. Detta beror på att budgivningstekniken behöver tid för att arbeta och räkna ut vilken annons som ska visas.

Det kan även uppstå ett problem med automatiska AdSense-annonser om du har dynamiska annonslistor. Detta beror på att AdSense även laddar annonser i olika storlekar (så du kanske inte vet annonsens storlek i förväg).

Om du använder ett av de populära annonsnätverken för displayannonser, exempelvis Mediavine eller AdThrive, så bör de redan erbjuda verktyg som hjälper dig att undvika layoutförskjutningar med dina annonser. Om du exempelvis öppnar Mediavine’s annonsinställningar så kan du aktivera en spak för att optimera annonser för CLS:

Optimera annonser för CLS-inställning i Mediavine.
Optimera annonser för CLS-inställning i Mediavine.

Att optimera AdSense för Kumulativ layoutförskjutning är lite knepigare.

En vanlig lösning är att lägga till ett <div>-omslagselement runt varje annonsenhet som anger en minsta höjd med hjälp av CSS-egenskapen min-height. Du kan även använda mediaqueries för att ändra den minsta höjden beroende på användarens enhet.

Google rekommenderar att du ställer in att min-höjden är lika med den största möjliga annonsstorleken. Även om detta kan leda till slöseri med utrymme om en mindre annons visas, så är detta det bästa alternativet för att eliminera risken för att en layoutförskjutning uppstår.

När du ställer in det här omslagselementet så ska du se till du använder ett CSS-ID i stället för en klass, eftersom AdSense ofta tar bort CSS-klassen från överordnade objekt.

Så här kan CSS-elementet se ut:

Ett exempel på CSS för en annonsomslag.
Ett exempel på CSS för en annonsomslag.

Och så här kan AdSense-inbäddningen se ut:

Inbäddning av AdSense-annonsens kod i en div.
Inbäddning av AdSense-annonsens kod i en div.

På frontend så ser du nu att din webbplats reserverar utrymme för annonsen, även om den är tom:

Din webbplats kommer nu att reservera utrymme för annonsen på frontend.
Din webbplats kommer nu att reservera utrymme för annonsen på frontend.

Var smart när du injicerar innehåll dynamiskt med plugins

Många WordPress-webbplatser injicerar dynamiskt innehåll för olika funktioner. Det kan handla om meddelanden om samtycke till cookies, relaterat innehåll, e-postformulär för opt-in och så vidare.

Även om detta är bra, så bör du vara försiktig så att du inte gör detta på ett sätt som orsakar layoutförskjutningar.

En bra metod för webbdesign är att aldrig lägga in innehåll ovanför befintligt innehåll om inte användaren specifikt har gjort en interaktion (t.ex. klickat på en knapp).

Om du exempelvis lägger till ett meddelande om samtycke till cookies så bör du inte placera det högst upp på sidan, eftersom det skulle leda till att innehållet flyttas nedåt(om du inte redan har reserverat utrymme i bannern för samtycke till cookies).

Du bör istället visa meddelandet längst ner på sidan, vilket gör att synligt innehåll inte flyttas nedåt.

För att se om dynamiskt innehåll orsakar problemet så kan du använda visualiseringsverktygen ovan (t.ex. Layout Shift GIF Generator).

Om du ser att innehåll från ett specifikt plugin utlöser layoutförskjutningar så kan du överväga att justera det pluginets inställningar eller byta till ett annat plugin.

Vissa plugins för samtycke till cookies är exempelvis bättre än andra när det gäller layoutförskjutningar, så det är värt att experimentera med olika plugins om du har problem.

Om du vill gräva ännu djupare i pluginbeteenden så kan du använda ett verktyg för övervakning av applikationsprestanda. Om du hostas av Kinsta så finns Kinsta’s APM-verktyg tillgängligt kostnadsfritt i din MyKinsta-instrumentpanel, och du kan även hitta andra APM-verktyg.

För att få hjälp med att testa plugins så kan du även använda Kinsta’s iscensättningsmiljöer eller DevKinsta’s lokala utvecklingsverktyg.

Använd CSS Transform-egenskapen för animationer när det är möjligt

Om du använder animationer på din webbplats så kan dessa vara en annan vanlig orsak till layoutförskjutningar.

För att undvika problem med animationer som orsakar layoutförskjutningar så bör du använda CSS Transform-funktionen för animationer snarare än andra taktiker:

  • I stället för att använda egenskaperna height och width så kan du använda transform: scale()
  • Om du vill flytta runt element så använder du transform: translate() i stället för top, bottom, right eller left.

Det här är mer ett tekniskt tips, så det är osannolikt att du behöver göra detta om du inte lägger till egen CSS. Om du vill veta mer så kan du läsa Google’s sida om CLS och animationer/övergångar.

Sammanfattning

Om din webbplats har en hög poäng för Kumulativ layoutförskjutning så är det viktigt att åtgärda detta. Det skapar både en bättre upplevelse för dina besökare och maximerar webbplatsens prestanda i Google’s sökresultat.

Två av de vanligaste problemen är saknade dimensioner för bilder/inbäddningar och problem med laddning av teckensnitt. Om du åtgärdar dessa så bör du vara på väg mot ett mycket bättre resultat.

Andra webbplatser kan behöva gå längre och gräva djupt i laddning av annonser, dynamiskt innehåll och animationer. Om du har svårt att genomföra dessa typer av optimeringar själv så kan du överväga att samarbeta med en WordPress-agentur eller frilansare.

Om du vill veta mer om Core Web Vitals i allmänhet så kan du läsa hela Kinsta-guiden om Core Web Vitals.

Och om du vill ha en WordPress-host som kan hjälpa dig att skapa en högpresterande webbplats som klarar sig bra i Core Web Vitals så kan du överväga att använda Kinsta’s hanterade WordPress-hosting – vi migrerar dina WordPress-webbplatser kostnadsfritt!

Jeremy Holcombe Kinsta

Innehålls- och marknadsföringsredaktör på Kinsta, WordPress webbutvecklare och innehållsskribent. Utöver WordPress tycker jag om stranden, golf och filmer. Jag har även problem med långa människor ;).