Så vet ni om hemsidan faktiskt är mobilanpassad
Nästan alla hemsidor krymper numera när skärmen blir smal. Det är inte samma sak som att de går att använda i mobilen. Här är skillnaden, vad Google faktiskt mäter, och en kontroll ni kan göra själva innan ni ber någon om en offert.
En kund står i en trapphusdörr och ska ringa er. Hon har googlat, tryckt på er sida och väntar. Bilden högst upp laddar, texten hoppar nedåt när loggan dyker upp, och tummen som skulle träffa telefonnumret träffar menyn i stället. Efter sex sekunder går hon tillbaka till träfflistan.
Sidan var responsiv. Den var bara inte användbar.
Vad mobilanpassning betyder i dag
För tio år sedan betydde mobilanpassad ungefär “krymper utan att gå sönder”. Den ribban klarar nästan alla sajter numera. I dag handlar frågan om fyra saker som mäts var för sig: innehållet, läsbarheten, svarstiden och inmatningen.
Innehållet ska vara detsamma i mobilen som på datorn. Google beskriver i sin dokumentation om mobile-first indexing att sökmotorn använder mobilversionen av en sida, hämtad med en mobilrobot, för både indexering och ranking. En text, en bild eller en strukturerad märkning som bara finns i datorvyn finns i praktiken inte. Google skriver i samma dokument att innehåll som kräver att besökaren sveper eller klickar för att laddas inte hämtas alls.
Läsbarheten handlar om att stycken ska gå att läsa utan att zooma och att ingenting ska sticka ut i sidled. WCAG 2.2 sätter en mätbar gräns: innehållet ska kunna visas i en spalt motsvarande 320 CSS-pixlars bredd utan att besökaren måste dra i sidled, med undantag för sådant som verkligen kräver två dimensioner, som kartor och vissa tabeller. Samma riktlinjer kräver att text går att förstora till 200 procent utan att innehåll eller funktioner försvinner.
Svarstiden är hur snabbt sidan visar något och hur snabbt den reagerar på en tryckning. Det mäter Google med Core Web Vitals, och de siffrorna går vi igenom nedan.
Inmatningen är den del som oftast får minst uppmärksamhet och kostar mest pengar. Ett formulär som är obehagligt att fylla i på en telefon blir inte ifyllt.
Varför det avgör om besökaren stannar
Andelen mobil varierar kraftigt mellan branscher, och medelvärden säger mindre än era egna siffror. Enligt Statcounter Global Stats stod mobiltelefoner i augusti 2026 för 44,2 procent av sidvisningarna i Sverige, mot 54,2 procent för dator och 1,6 procent för surfplatta. För ett hantverksföretag vars kunder söker hjälp akut ligger mobilandelen ofta betydligt högre än så, och för en B2B-tjänst som används på jobbet lägre.
Slå upp er egen siffra i Google Analytics innan ni bestämmer hur mycket arbete mobilvyn förtjänar. Ligger ni över hälften är mobilen inte en variant av hemsidan, den är hemsidan.
Vad Google faktiskt mäter
Core Web Vitals är tre mått på hur sidan upplevs av riktiga besökare, inte av ett testverktyg. Enligt web.dev gäller de här gränserna:
| Mått | Vad det mäter | Bra värde |
|---|---|---|
| LCP | tiden tills det största innehållet syns | högst 2,5 sekunder |
| INP | tiden från tryckning till synligt svar | högst 200 millisekunder |
| CLS | hur mycket layouten flyttar sig | högst 0,1 |
Två detaljer är värda att känna till. Värdena räknas på den 75:e percentilen av sidvisningarna, uppdelat på mobil och dator, vilket betyder att tre av fyra besök ska klara gränsen. Och mobilvärdena är nästan alltid sämre än datorvärdena, eftersom telefoner har svagare processorer och sämre uppkoppling.
Google Search Central skriver att Core Web Vitals används av rankningssystemen och rekommenderar att sajtägare når bra värden. I samma dokument står det rakt ut att bra värden i Search Consoles rapport inte garanterar en bra placering. Innehållet väger tyngre. Men mellan två sidor som svarar lika bra på frågan vinner den som går att använda.
Det som gör mobilsidor långsamma är sällan exotiskt. web.dev:s genomgång av LCP pekar ut bilden eller rubriken högst upp som det element som nästan alltid mäts, och den laddas långsamt av tre skäl: bilden är sparad i full upplösning för en dator, den hämtas först efter att en bunt skript har körts, eller så väntar hela sidan på ett typsnitt som ligger på en annan server. Alla tre går att rätta utan att bygga om designen. Skala bilderna till den storlek de faktiskt visas i, ladda dem i ett modernt format, och flytta ned det som inte behövs för att visa första skärmen.
CLS är måttet som oftast överraskar. Det mäter hur mycket innehållet hoppar medan sidan laddar, och den vanligaste orsaken är enkel: bilder och annonsytor utan angiven höjd och bredd, samt typsnitt som byts ut mitt i laddningen. Besökaren som just skulle trycka på en länk trycker på något annat.
Det här kan ni kontrollera själva
Ta er egen telefon, inte en simulator i datorn, och gå igenom listan. Det tar tio minuter.
- Läs ett stycke brödtext. Behöver ni nypa för att zooma är texten för liten.
- Dra fingret i sidled. Rör sig sidan i höjdled är något bredare än skärmen, ofta en tabell, en bild eller ett inbäddat kartfält.
- Tryck på telefonnumret. Startar ett samtal direkt? Bra. Ett nummer som bara är text i mobilen är en missad förfrågan.
- Öppna menyn och pricka varje rad. Sitter raderna för tätt träffar ni fel. WCAG 2.2 anger 24 gånger 24 CSS-pixlar som minsta klickyta på AA-nivå, med undantag bland annat när små ytor har tillräckligt med luft omkring sig. AAA-nivån anger 44 gånger 44 pixlar.
- Fyll i kontaktformuläret med en hand, hela vägen till bekräftelsen. Räkna fälten. Notera om tangentbordet blir ett siffertangentbord i telefonfältet.
- Ladda sidan över mobilnät med wifi avstängt. Det är så era kunder ser den.
- Kör sidan i PageSpeed Insights och läs mätvärdena för mobil, alltså siffrorna från riktiga besökare.
- Zooma in till 200 procent i webbläsarens inställningar och se om något innehåll försvinner.
Punkterna 1, 2, 4 och 5 går att åtgärda utan att bygga om något. En rubrikstorlek, ett radavstånd, en bredd på ett formulärfält och lite luft i menyn är ändringar på timmar, inte veckor.
Formuläret är där pengarna finns
Ett kontaktformulär på en telefon är ett hantverk för sig. Fyra saker gör mest skillnad.
Använd rätt fälttyp. Ett telefonfält ska ge ett siffertangentbord och ett e-postfält ett tangentbord med snabbknapp för snabel-a. Det är en attributsändring i koden, inget ombygge.
Slå på ifyllningshjälpen. MDN:s dokumentation över attributet autocomplete beskriver hur webbläsaren kan fylla i namn, adress, e-post och telefon åt besökaren. På AA-nivå kräver WCAG 2.2 dessutom att fält som efterfrågar information om användaren själv är märkta så att det går. Det är både tillgänglighet och färre avhopp.
Korta ned. Varje fält är en anledning att avbryta. Namn, telefon och ett fritextfält räcker för en förfrågan. Resten kan ni fråga om när ni ringer upp.
Lägg etiketten ovanför fältet, inte inuti. En etikett som försvinner när besökaren börjar skriva gör att man tappar bort sig, särskilt när tangentbordet täcker halva skärmen.
Hur ett formulär bör se ut för att faktiskt ge förfrågningar hör till webbdesign och användbarhet, och det är oftast den billigaste förbättringen på en sajt som redan finns.
Vad som kräver ombyggnad
En del går inte att justera. Signalerna är de här.
Sidan har en separat mobilversion på en egen adress, till exempel en som börjar med m-punkt. Den lösningen är från en annan tid och skapar dubbletter av allt innehåll. Google rekommenderar responsiv design, alltså samma adress och samma kod för alla skärmar.
Mobilvyn saknar innehåll som finns på datorn. Då tappar ni inte bara besökare, ni tappar det som Google indexerar.
Sidan spärrar zoomning. MDN varnar uttryckligen för att sätta user-scalable=no i viewport-taggen, eftersom det hindrar personer med nedsatt syn från att förstora sidan. Ett tema som gör så är byggt med fel utgångspunkt.
LCP ligger långt över gränsen på mobil och det beror på temat självt, inte på en enskild bild. Ett tema som laddar fem typsnittsvikter, tre bibliotek och en bildkarusell högst upp blir sällan snabbt av att man byter ut bilderna.
Tillgängligheten brister brett. Kraven i WCAG 2.2 överlappar mobilanpassning på nästan varje punkt, och för en del företag är de dessutom reglerade. Vilka som omfattas går vi igenom i artikeln om tillgänglighetsdirektivet.
I de lägena blir en ombyggnad billigare än ännu en lapp. Vad en sådan kostar och vad som styr priset står i artikeln om vad en hemsida kostar, och hur vi bygger står på sidan om hemsida för företag.
Mobilanpassning och synlighet hänger ihop
En snabb och läsbar mobilsida rankar inte av sig själv. Den gör däremot att allt annat arbete räknas: texterna indexeras som de ser ut i mobilen, besökaren stannar länge nog för att läsa dem, och den som ringer hittar knappen. Utan den grunden blir arbetet med att synas på Google mest en trafikkanal till en sida som tappar folk i dörren.
Vill ni ha siffrorna för er egen sajt innan ni bestämmer något kan ni beställa en gratis analys. Vi mäter mobilvärdena, går igenom formulär och klickytor och skickar en prioriterad lista med ungefärlig kostnad per punkt. Listan kan ni ta med till vilken leverantör som helst.