Kod på en bärbar dator granskas framför flera utvecklingsskärmar

Den digitala fetman som kväver din sajt

TL;DR: De flesta webbplatser lider inte först och främst av dålig hosting. De lider av pålagrad digital skräp: spårningsskript, gamla tillägg, överflödiga webbfonter och funktioner som ingen längre använder. Det kan ofta städas bort på en kafferast, utan dyr migrering eller en dramatisk omskrivning av hela plattformen.

Tänk på webbplatsen som en överlastad flyttbil. Där finns den gamla Facebook-pixeln, tre analysverktyg, ett A/B-test som avslutades för två år sedan, sju versioner av samma typsnitt och ett plugin som installerades ”för säkerhets skull”. Ingen vet riktigt vad kartongerna innehåller, men ingen vågar kasta dem heller. Resultatet blir en tung bil som accelererar långsamt, drar mer bränsle och får besökaren att undra om det verkligen var värt att kliva ombord.

Den vanliga reflexen är att köpa kraftigare server, byta ramverk eller beställa en ny teknisk plattform. Ibland behövs det. Men ofta fungerar den typen av projekt som en dyr bortförklaring för enkel städning. Börja i stället med det som faktiskt skickas till besökarens webbläsare. På 15 minuter går det att identifiera flera uppenbara ballastposter, dokumentera vad som ska bort och skapa en säkrare väg mot snabbare laddning, utan att röra en rad komplex backend-kod.

Dödsdansen bland spårningsskript och tagghanterare

Google Tag Manager var tänkt att ge marknadsavdelningen frihet från utvecklingsköer. I praktiken har många installationer utvecklats till digitala soptippar. Där ligger skript från tidigare kampanjer, testmiljöer, annonsplattformar och analysverktyg som ingen längre öppnar. Namnen är ofta vaga, ägarna har slutat på företaget och dokumentationen består av ett gammalt kalkylblad som senast uppdaterades när en annan logotyp satt på startsidan.

Problemet är inte bara ordningen i arbetsytan. Tredjepartskod kan belasta huvudtråden, alltså den del av webbläsaren som samtidigt ska bygga sidan, reagera på tryck och visa innehåll. Om flera skript laddas tidigt kan rendering fördröjas, särskilt på äldre mobiltelefoner och tröga nätverk. En PageSpeed-varning är inte automatiskt ett bevis på katastrof, men återkommande externa anrop bör tas på allvar. För en tydlig genomgång av hur skript kan blockera rendering, se guiden om optimering av webbplatsens laddningstider.

Radera inte på måfå. Kontrollera först att ett skript verkligen saknar affärsnytta, att ingen rapport använder datan och att eventuella samtyckeskrav är hanterade. Därefter är följande kandidater ofta de mest uppenbara:

Glödande rött hjärta ovanför en färgad laddningsindikator
Varje onödigt skript förlänger vägen till det innehåll besökaren faktiskt kom för.
  • Glömda Facebook- eller Meta-pixlar från kampanjer som aldrig återkommer.
  • Gamla A/B-testverktyg som inte längre har aktiva experiment.
  • Inaktiva värmekartor och inspelningsverktyg som ingen analyserar.
  • Annons- och remarketingtaggar utan definierad ägare eller mätmål.
  • Dubbla analysinstallationer där samma sidvisning skickas till flera system.

Varje extra spårningsskript innebär dessutom fler beslut kring samtycke, fler nätverksanrop och fler möjliga konflikter. På mobil kan en kort fördröjning vara skillnaden mellan att en besökare fyller i ett formulär och att sidan överges. Därför ska varje tagg kunna svara på tre frågor: Vem äger den, vilket beslut stöder den och vad händer om den tas bort? Kan ingen svara är den inte ett verktyg. Den är ballast.

Typsnittshysterin som kostar sekunder

Designers älskar typsnitt på samma sätt som teknikavdelningar älskar nya ramverk: varje variant känns motiverad när den beställs. En rubrik ska ha en vikt, brödtexten en annan, citatet kursiv stil och knappen kanske en femte. Lägg till både rak och kursiv variant, flera teckenuppsättningar och ett externt anrop till ett typsnittsbibliotek, så har en enkel typografisk idé förvandlats till en liten transportsträcka före själva innehållet.

Skillnaden mellan systemfonter och externa webbfonter är inte att den ena alltid är rätt och den andra alltid är fel. Systemfonter finns ofta redan på enheten och kräver därför inget separat typsnittsanrop. Externa fonter kan ge en tydlig visuell profil, men varje fil ska laddas, tolkas och ibland ersätta en tillfällig standardfont efteråt. Det kan skapa både väntan och så kallad layoutförskjutning. Börja med en baslinje i PageSpeed Insights, WebPageTest eller liknande, och mät sedan förändringen. Ett högt Lighthouse-betyg är inte målet i sig, men det är ett användbart signalinstrument.

Typografisk profil Vad som laddas Praktisk konsekvens
Full typsnittspark Flera vikter, kursiv stil, många teckenuppsättningar och externa anrop Fler filer, fler anrop och större risk för fördröjd textvisning
Sanerad profil En familj med högst två nödvändiga vikter i WOFF2 Mindre överföring och enklare kontroll över layouten
Systemstandard Systemets befintliga sans-serif eller serif Minimalt typsnittsanrop och ofta snabbast start

En rimlig tumregel är att behålla högst två vikter, exempelvis normal och fet, i komprimerat WOFF2-format. Kursiv stil kan ofta undvaras eller ersättas med en väl vald standardvariant. Om varumärket inte kräver en särskild font, välj systemstandard. Besökaren kommer sällan att lämna sidan i protest för att brödtexten använder ett mindre exotiskt typsnitt. Däremot kan besökaren lämna sidan om innehållet fortfarande väntar på att ritas upp.

Tilläggens kyrkogård i CMS-panelen

CMS-panelen visar ofta vilka tillägg som är aktiva, men inte alltid hur mycket arbete de utför i bakgrunden. Ett inaktivt tillägg kan vara ofarligt när det verkligen är avstängt, medan ett aktivt ”bra-att-ha”-tillägg kan läsa in CSS och JavaScript på varje undersida, även där funktionen aldrig används. Ett galleri behöver inte sina resurser på kontaktsidan. Ett formulärtillägg behöver inte köra sin kod på en artikel utan formulär.

Funktionen i sig är heller inget argument för ett separat tillägg på 400 kilobyte. Många moderna CMS-plattformar har redan stöd för menyer, formulär, bildstorlekar, rubrikstruktur, cachehantering eller enkel statistik. Varje ytterligare komponent ska motiveras av en konkret funktion, inte av att den såg användbar ut i en rekommendationslista. På en WordPress-webbplats kan tunga tillägg dessutom skapa många databasfrågor, skanningar, säkerhetskopior eller loggar som påverkar både serverns svarstid och administrationen.

Gå igenom tilläggslistan med samma kyliga blick som Tag Manager. Stäng av ett misstänkt tillägg i taget, testa startsida, formulär, inloggning och köpflöde, och kontrollera därefter laddningstid och serverrespons. Avinstallera sedan sådant som inte behövs och radera kvarlämnade filer eller inställningar när plattformen tillåter det.

  • Separata sociala delningsfält när temat eller CMS:et redan har en enkel lösning.
  • Extra SEO- eller statistikmoduler som duplicerar funktioner i den befintliga plattformen.
  • Bildgallerier, reglage och popup-verktyg som kan ersättas med enklare HTML, CSS eller inbyggda block.
  • Gamla backup- och skanningstillägg som kör tunga jobb utan tydlig återställningsplan.

Prestandakulturen varierar mellan marknader, men svenska användare förväntar sig inte att vänta artigt på en webbsida som borde ha visats direkt. Sveriges höga digitala mognad, något som också speglas i landets beskrivning hos Wikipedia om Sverige, gör att långsamhet snabbt känns som ett kvalitetsproblem. Det betyder inte att varje varning kräver panik. Det betyder att varje tung komponent måste försvara sin plats.

Kvartens räddningsaktion med checklistan som kapar ballast

En kvart räcker inte för en fullständig prestandarevision, men den räcker för en fokuserad första insats. Arbeta i en testmiljö eller ta en verifierad säkerhetskopia innan du avinstallerar något. Mät före och efter, eftersom en åtgärd som ser logisk ut i panelen inte alltid ger utslag i verklig laddtid.

  1. Granska Tag Manager. Ta bort taggar, triggers och variabler som saknar aktiv ägare, tydligt syfte eller aktuell rapportering. Publicera inte ändringen förrän viktiga konverteringar har kontrollerats.
  2. Avinstallera oanvända tillägg och teman. Inaktivera först, testa centrala flöden och radera därefter sådant som inte behövs. Ett gammalt tema ska inte ligga kvar som en digital reservdelslåda på produktionsservern.
  3. Kapa typsnittsvarianterna. Ta bort oanvända vikter ur CSS eller temainställningar och behåll bara nödvändiga WOFF2-filer. Kontrollera att rubriker och formulär fortfarande har rätt radbrytning.
  4. Rensa gamla analysverktyg. Identifiera dubbla mätningar och verktyg som inte längre används. Kontrollera samtidigt samtycke och integritetskrav, eftersom mindre kod också betyder färre onödiga personuppgiftsflöden.

Efter varje steg bör sidan testas från mobil och dator, gärna i ett privat webbläsarfönster. Kontrollera särskilt Largest Contentful Paint, alltså när det största synliga innehållet är på plats, First Contentful Paint och serverns svarstid. Om resultatet inte förbättras betyder det inte automatiskt att åtgärden var meningslös. Ett borttaget skript kan ha varit litet, medan en bild, långsam databasfråga eller tung serverrespons fortfarande dominerar. Mätningen visar vad som ska angripas härnäst.

Börja stryka i källkoden redan i dag

God prestanda handlar oftare om återhållsamhet och redaktionellt mod än om avancerad infrastruktur. En webbplats blir inte snabb för att den har fler verktyg, fler dashboards och fler automatiseringar. Den blir snabb när varje del som laddas har ett tydligt jobb och när onödiga delar får lämna scenen.

Den bästa koden är den kod som besökarens webbläsare aldrig behöver ladda. Sätt därför en återkommande kvartalsstädning i kalendern: granska taggar, tillägg, fonter, externa anrop och analysverktyg. Dokumentera vem som äger varje komponent och vilket resultat den ska skapa. Då slipper webbplatsen långsamt förvandlas till en digital flyttbil igen, full av kartonger som ingen längre minns varför de sparades.