HTTP/2

HTTP/2 är den version av webbens överföringsprotokoll som låter en server skicka många filer samtidigt över en enda uppkoppling, i stället för att skicka dem en i taget och vänta på svar mellan varje. För dig som driver en sajt betyder det i praktiken snabbare sidladdning, ofta utan att du behöver röra en enda rad i ditt innehåll.

Tänk dig att du beställer tio saker från samma butik. Med det gamla sättet, HTTP/1.1, skickas paketen ett i taget: butiken väntar tills du bekräftat att du fått paket ett innan paket två skickas iväg. Med HTTP/2 packas allt och skickas i samma leverans, i parallella strömmar som färdas över samma uppkoppling utan att trängas i samma kö. Det är samma butik, samma varor och samma adress, men ett betydligt smartare sätt att leverera. Den här guiden förklarar vad som faktiskt händer under huven, varför det spelar roll för både besökare och Google, och hur du på någon minut kollar om din egen sajt redan kör det. Vi går igenom multiplexing, header compression and prioritization och de missförstånd som lever kvar sedan HTTP/1.1-tiden, så att du efteråt vet exakt vad du ska titta efter och vad du tryggt kan strunta i.

Vad är HTTP/2, egentligen?

HTTP står för Hypertext Transfer Protocol, och det är reglerna för hur en webbläsare och en server pratar med varandra. Varje gång du öppnar en sida på World Wide Web skickar din webbläsare en begäran (request) till servern, och servern svarar (response to den begäran) med HTML, bilder, stilmallar och skript. HTTP/2 är den andra stora versionen av det här regelverket, en efterträdare till HTTP/1.1 som dominerade webben i nästan två decennier. Begreppet Hypertext är samma idé som har funnits sedan webbens början: dokument som länkar till andra dokument, hämtade på begäran.

Det viktiga att förstå är att HTTP/2 inte ändrar vad som skickas. Samma HTML, samma bilder, samma cookies skickas fram och tillbaka mellan server och webbläsare. Det som ändras är hur data travels mellan dem. Protokollet är binärt i stället för textbaserat, vilket gör det effektivare för maskiner att tolka, och det organiserar trafiken i strömmar (streams) som var och en får en egen Stream Identifier. Tack vare dessa Stream ID kan servern hålla reda på vilken bit av svaret som hör till vilken begäran, även när allt skickas om vartannat och bitarna anländer i en annan ordning än de begärdes.

HTTP/2 standardiserades 2015 och bygger vidare på ett tidigare experiment från Google som hette SPDY. Sedan dess har stödet blivit närmast universellt: alla moderna webbläsare, de flesta webbhotell och praktiskt taget varje större CDN hanterar det. Om din sajt körs på en någorlunda uppdaterad plattform är chansen stor att du redan använder det utan att ha tänkt på saken. På den punkten skiljer sig HTTP/2 från många andra tekniska finesser, eftersom du sällan behöver göra ett aktivt val: det aktiveras tyst i bakgrunden när förutsättningarna finns.

För att hålla isär de centrala byggstenarna kan det hjälpa med en snabb ordlista över de begrepp som återkommer i resten av guiden:

• Stream är en logisk kanal inom uppkopplingen där en enskild begäran och dess svar färdas.
• Stream Identifier är numret som binder ihop varje frame med rätt stream, så att inget blandas ihop.
• Frame är den minsta byggstenen i protokollet, ett litet paket av data som hör till en specifik stream.
• Multiplexing är förmågan att skicka flera streams samtidigt över samma uppkoppling.
• HPACK är metoden som komprimerar headers så att samma information inte upprepas i onödan.

En kort historik: från HTTP/1.1 till idag

För att förstå varför HTTP/2 togs fram hjälper det att veta var skon klämde. Webben på HTTP/1.1-tiden såg helt annorlunda ut. En sida bestod ofta av en handfull filer. Idag laddar en genomsnittlig sida in dussintals eller hundratals resurser: typsnitt, ikoner, spårningsskript, bilder i flera storlekar och tunga ramverk. HTTP/1.1 var helt enkelt inte byggt för den volymen, och det märktes tydligast på sidor med många små filer som alla skulle hämtas innan sidan kändes klar.

Här är de stora stegen i protokollets utveckling, i ordning:

1. HTTP/0.9 var den första, extremt enkla versionen som bara kunde hämta HTML.
2. HTTP/1.0 lade till headers, statuskoder och möjligheten att skicka andra filtyper.
3. HTTP/1.1 introducerade ihållande uppkopplingar och blev webbens arbetshäst i många år.
4. SPDY var ett experiment från Google som testade idéer kring multiplexing och prioritering.
5. HTTP/2 standardiserade de bästa idéerna från SPDY till en öppen standard 2015.
6. HTTP/3 bytte ut TCP mot QUIC för ännu smidigare uppkopplingar på instabila nät.

Poängen är att varje version löste ett konkret problem som föregångaren skapade. HTTP/2 löste framför allt det som kallades head-of-line blocking på applikationsnivå, alltså att en långsam fil kunde blockera kön för alla andra. SPDY var här en viktig mellanstation: Google byggde det för att testa idéer i skarp drift innan de blev en formell standard, och flera av idéerna lever kvar i HTTP/2 i nästan oförändrad form.

Det är också värdt att notera vad som inte ändrades. Adresserna ser likadana ut, statuskoderna som 200, 301 och 404 fungerar precis som förut, och dina cookies hanteras på samma sätt. För en utvecklare som är van vid HTTP/1.1 är det mesta bekant, och för dig som sajtägare är skiftet i regel osynligt. Det enda du märker är att sidan känns snabbare, särskilt på en sajt med många resurser att hämta.

Hur fungerar HTTP/2 under huven?

Nu blir det lite mer tekniskt, men jag lovar att hålla det jordnära. Det finns i huvudsak fyra mekanismer som gör HTTP/2 snabbare än sin föregångare, och de samverkar. Om du förstår dem förstår du också varför protokollet i regel ger en mätbar förbättring utan något extra arbete från din sida. De fyra mekanismerna är multiplexing, header-komprimering med HPACK, prioritering och det binära formatet, och vi tar dem en i taget.

Multiplexing: flera filer samtidigt

Multiplexing är hjärtat i HTTP/2. Med HTTP/1.1 kunde en webbläsare bara hämta en fil i taget per uppkoppling. För att komma runt detta öppnade webbläsaren flera parallella uppkopplingar, ofta sex stycken per domän, vilket var resurskrävande både för webbläsaren och servern. När en sida behövde ladda hundra filer blev det snabbt en flaskhals, och varje ny uppkoppling kostade tid att etablera innan något ens kunde skickas.

Med multiplexing skickas alla dessa filer parallellt över en enda uppkoppling. Varje begäran och svar delas upp i mindre bitar, så kallade frames, som är connected to en specifik ström via sitt Stream ID. Webbläsaren och servern kan alltså skicka bitar av tio filer om vartannat och sätta ihop dem korrekt i andra änden. Multiplexing which lets webbläsaren hantera allt över en kanal är just det som gör att om en fil är långsam, blockerar den inte längre de andra. Det var själva svagheten i den gamla modellen, där en enda trög resurs kunde hålla kvar hela kön.

I praktiken betyder det att smaller websites med få filer ser en mindre vinst, medan tunga sajter med många resurser, till exempel en WordPress-sajt med flera plugins och bilder, ofta märker en tydlig skillnad och har mest att vinna på ett genomtänkt SEO-arbete för WordPress. Det är just den typen av sajt där multiplexing, header compression and prioritization gör mest nytta. Tänk dig en produktsida med trettio bilder, fem stilmallar och ett dussin skript: med HTTP/1.1 köar de, medan de med HTTP/2 hämtas i samma andetag. Effekten blir störst i exakt det scenario där den gamla modellen var sämst.

Några konkreta saker multiplexing förändrar i hur data travels mellan server och besökare:

• En enda uppkoppling räcker, i stället för upp till sex parallella per domän.
• File transfers av många små filer blir effektiva i stället för långsamma.
• En trög resurs blockerar inte längre alla andra i kön.
• Servern och webbläsaren slipper kostnaden för att gång på gång etablera nya uppkopplingar.
• Färre uppkopplingar betyder mindre belastning på både klient och server.

Header-komprimering med HPACK

Varje begäran och svar bär med sig headers, alltså metadata om vad som efterfrågas, vilka cookies som gäller, vilken webbläsare som används och så vidare. På en sida med många resurser upprepas mycket av denna information om och om igen, vilket slösar bandbredd. När hundra filer hämtas skickas i princip samma uppsättning headers hundra gånger.

HTTP/2 löser det med en metod som heter HPACK. Den komprimerar headers och, ännu viktigare, kommer ihåg vilka headers som redan skickats så att de inte behöver upprepas i sin helhet. Value, alltså värdet i en header som inte ändrats, behöver bara refereras med en kort kod i stället för att skickas om i sin helhet. På sidor med många filer summerar detta till en märkbar minskning av onödig overhead. HPACK använder både en statisk tabell med vanliga headers och en dynamisk tabell som byggs upp under uppkopplingens gång, och tillsammans gör de att andra omgången headers nästan alltid blir mycket billigare än den första.

Prioritering och server push

HTTP/2 låter webbläsaren signalera vilka filer som är viktigast, så att servern kan skicka dem först. Det betyder att en kritisk stilmall som behövs för att rendera sidan kan prioriteras framför en bild långt ner på sidan. Den här prioriteringen (prioritization) hjälper sidan att kännas snabb, eftersom det viktigaste syns först. Webbläsaren bygger i praktiken ett litet beroendeträd där den talar om vad som ska komma i vilken ordning, och servern försöker följa den planen.

En annan funktion var server push, där servern in advance kunde skicka filer den gissade att webbläsaren snart skulle begära, utan att vänta på själva begäran. I praktiken visade sig server push svår att använda rätt, och stödet har sedan dess fasats ut i flera webbläsare. Det är ett bra exempel på att en idé kan låta klok på pappret men inte alltid håller i verkligheten. Lärdomen är att inte allt som standardiseras blir användbart i längden, och att det är klokt att luta sig mot det som faktiskt fungerar i fält.

Binärt protokoll i stället för text

HTTP/1.1 skickade allt som vanlig text, vilket var lätt för en människa att läsa men ineffektivt för en dator att tolka. HTTP/2 är binärt, vilket innebär att meddelanden delas upp i tydligt definierade frames med ett bestämt format. Det gör tolkningen snabbare och mindre felbenägen (efficient and less prone till feltolkningar), och det är en del av varför det binära formatet är more efficient and less känsligt för de tvetydigheter som plågade den textbaserade föregångaren. Där HTTP/1.1 lämnade utrymme för olika tolkningar av blanksteg och radbrytningar, är HTTP/2 entydigt: varje frame har en bestämd plats där varje fält ska ligga.

Tänk på skillnaden så här: HTTP/1.1 är som att läsa upp ett brev högt, ord för ord. HTTP/2 är som att skicka ett färdigt formulär där varje ruta har sin bestämda plats. Mottagaren behöver inte tolka, bara läsa av.

HTTP/2 jämfört med HTTP/1.1 och HTTP/3

Många blandar ihop versionerna, så låt oss reda ut det. Den vanligaste frågan är vad som skiljer versionerna åt i praktiken, och svaret handlar mest om hur uppkopplingen hanteras och hur filer skickas. Här är en jämförelse i tabellform så att du ser de viktigaste skillnaderna på en gång.

The second jämförelseparet som ofta kommer upp är HTTP/2 vs HTTP/3, och det är värt en egen titt. Skillnaden där ligger inte i multiplexing, som båda har, utan i transportlagret. HTTP/2 vilar på TCP, medan HTTP/3 bygger på QUIC, som i sin tur använder UDP. På ett stabilt nät märks knappt någon skillnad, men when network-förhållandena är dåliga, till exempel på mobil eller en skakig wifi, hanterar HTTP/3 paketförluster smidigare eftersom en förlorad packet of data inte stoppar alla strömmar. Det är samma grundidé som i HTTP/2, men flyttad ett lager ner i nätverksstacken.

Om vi ställer alla tre versionerna bredvid varandra blir mönstret tydligt:

• HTTP/1.1 hämtar en fil i taget per uppkoppling och skickar headers i klartext.
• HTTP/2 multiplexar många filer över en uppkoppling och komprimerar headers med HPACK, men vilar fortfarande på TCP.
• HTTP/3 behåller multiplexing men byter TCP mot QUIC, vilket gör det robustare när paket tappas bort.

Vad betyder detta för dig som sajtägare?

Du behöver inte fatta ett aktivt val mellan versionerna. Servern och webbläsaren förhandlar automatiskt fram den högsta version båda stödjer, en mekanism som historiskt byggde på NPN och senare på en nyare metod i SSL-handskakningen. Din roll är snarare att se till att din plattform är modern och att HTTPS är på plats. Resten sköter sig självt, och du behöver aldrig välja protokoll manuellt i någon inställning.

För de flesta små och medelstora sajter är prioriteringen tydlig. För att göra det konkret, så här bör du tänka på ordningen:

1. Se till att du kör HTTP/2, vilket du nästan säkert redan gör.
2. Bekräfta att HTTPS är aktivt med ett giltigt certifikat, eftersom det är förutsättningen.
3. Låt HTTP/3 vara en bonus om ditt CDN erbjuder det, inte ett mål i sig.
4. Lägg den mesta energin på bilder, skript och serverns svarstid i stället för protokolljakt.

Att jaga den senaste versionen manuellt ger sällan någon vinst som är värd besväret jämfört med det praktiska arbetet i en genomgång av din sidhastighet, där bildoptimering och städad kod nästan alltid väger tyngre. Protokollet är grunden, men det är vad du bygger ovanpå grunden som avgör hur snabb sajten verkligen känns.

Påverkar HTTP/2 din SEO och sidhastighet?

Det här är frågan de flesta egentligen vill ha svar på, så låt oss vara ärliga. HTTP/2 är inte en magisk rankingknapp. Google har aldrig sagt att en sida som kör HTTP/2 rankas högre än en identisk sida som kör HTTP/1.1. Den som lovar dig snabba placeringar bara genom att byta protokollversion överdriver, och det är värt att vara skeptisk mot sådana löften.

Men, och det är ett viktigt men, HTTP/2 bidrar ofta till snabbare laddtider, och sidhastighet är något Google väger in. Sedan Core Web Vitals blev en del av rankingsignalerna spelar det roll hur snabbt din sida blir användbar för besökaren. HTTP/2 hjälper framför allt mätvärden som påverkas av hur snabbt många filer hämtas, eftersom multiplexing minskar väntetiden när en sida laddar in sina resurser. Effekten är indirekt men verklig: snabbare hämtning av resurser ger ofta bättre värden i de mätningar Google faktiskt tittar på, något du själv kan följa upp i Search Console över tid.

Lika viktigt är besökaren själv. En sida som laddar snabbt känns mer pålitlig, och färre personer lämnar innan sidan ens visats. Det är en del av den helhet som Google försöker mäta med E-E-A-T: en teknisk grund som signalerar att sajten är välskött. HTTP/2 är en pusselbit i det fundamentet, inte hela pusslet. Tänk på protokollet som ett av många små förtroendetecken: var för sig betyder de lite, men tillsammans bygger de bilden av en sajt som någon faktiskt sköter om.

Mät innan du ändrar

Innan du tror att HTTP/2 ensamt ska lösa en långsam sajt: mät. Använd Search Console och ett verktyg som mäter Core Web Vitals för att se var flaskhalsen faktiskt sitter. Ofta är det stora bilder, för många plugins eller en långsam server som drar ner hastigheten, inte protokollversionen. HTTP/2 hjälper, men det fixar inte en sajt som är tung av andra skäl, och därför är mätningen alltid första steget.

Här är de vanligaste prestandafaktorerna att kolla, ungefär i den ordning de brukar göra störst skillnad:

• Bildstorlek och bildformat, alltså att komprimera och använda moderna format.
• Antal och kvalitet på plugins eller tredjepartsskript.
• Serverns svarstid och om en CDN används för att korta avstånden.
• Om HTTPS och HTTP/2 är aktiverat över huvud taget.
• Cachning i webbläsaren och på servern, så att återbesökare slipper hämta allt på nytt.
• Mängden onödig JavaScript och CSS som laddas innan sidan blir användbar.

När du gått igenom listan ovan har du i regel hittat den verkliga flaskhalsen. I praktiken ligger den nästan alltid i bilderna eller i mängden skript, inte i protokollet, och då vet du var din tid är bäst investerad.

Så kollar du om din sajt kör HTTP/2

Det fina är att du kan kontrollera detta gratis på under en minut, och du behöver inga tekniska förkunskaper. Det finns flera sätt, från det enkla onlineverktyget till webbläsarens inbyggda utvecklarverktyg, och båda ger samma svar.

Så här gör du steg för steg i webbläsarens utvecklarverktyg, som finns inbyggt i Chrome, Firefox och Edge:

1. Öppna din sajt i webbläsaren.
2. Högerklicka var som helst på sidan och välj “Inspektera”, eller tryck F12.
3. Gå till fliken “Network” (Nätverk).
4. Ladda om sidan så att förfrågningarna dyker upp i listan.
5. Högerklicka på kolumnrubrikerna och bocka i kolumnen “Protocol”.
6. Titta i Protocol-kolumnen: står det “h2” kör du HTTP/2, står det “http/1.1” gör du inte det.

Om du hellre slipper utvecklarverktygen finns det gratis onlineverktyg där du klistrar in din adress och får svar direkt. Båda metoderna duger gott. Det viktiga är att du vet vad du tittar efter: bokstavskombinationen “h2” betyder HTTP/2, medan “h3” betyder HTTP/3. Ser du “http/1.1” är det dags att höra av dig till ditt webbhotell, vilket vi tittar på härnäst.

Att tolka resultatet är enkelt när du vet vad symbolerna står för:

• h2 betyder att sidan hämtas över HTTP/2, vilket är det du vill se.
• h3 betyder HTTP/3, alltså den nyaste versionen, ofta via ett CDN.
• http/1.1 betyder att du fortfarande kör den gamla versionen och bör fråga ditt webbhotell.
• En tom eller saknad Protocol-kolumn betyder bara att du behöver bocka i den i kolumninställningarna.

Om du fortfarande kör HTTP/1.1

Skulle det visa sig att din sajt fortfarande kör den gamla versionen är åtgärden oftast enkel. Eftersom HTTP/2 aktiveras på serversidan handlar det om att din webbhotellsleverantör behöver slå på det. Svenska leverantörer som Oderland och de flesta andra moderna webbhotell stödjer HTTP/2 sedan länge, så ett mejl till supporten brukar räcka. Kontrollera samtidigt att du har ett giltigt SSL-certifikat, eftersom HTTP/2 i praktiken kräver HTTPS.

En kort lista över vad du kan be supporten kontrollera om du fastnar:

• Att HTTP/2 är aktiverat för just din domän och inte bara på servern generellt.
• Att ditt SSL-certifikat är giltigt och inte på väg att löpa ut.
• Att eventuell CDN framför sajten också kör HTTP/2 och inte faller tillbaka till HTTP/1.1.
• Att serverprogramvaran är uppdaterad nog att stödja protokollet.

Vanliga missförstånd om HTTP/2

Eftersom HTTP/2 är tekniskt florerar det en del myter. Här är de jag oftast stöter på, och varför de inte stämmer. Många av dem bottnar i att råd från HTTP/1.1-tiden lever kvar långt efter att de slutat gälla.

”HTTP/2 gör automatiskt min sajt snabb”

Nej. HTTP/2 gör överföringen av filer effektivare, men det gör inget åt själva filerna. En sida med tre megabyte ooptimerade bilder är fortfarande tung, oavsett protokoll. Tänk på HTTP/2 som en bredare motorväg: trafiken flyter smidigare, men en överlastad lastbil är fortfarande tung att köra. Du behöver fortfarande komprimera bilder, minska antalet skript och städa din kod, för protokollet flyttar data snabbare men minskar inte mängden data.

”Jag måste installera något för att få HTTP/2”

Inte heller. Det finns inget plugin du installerar i WordPress för att få HTTP/2, eftersom protokollet aktiveras på servern, inte i din webbplats kod. De extensions chrome firefox edge du kanske sett handlar om att visa vilken version som används, inte om att aktivera den. Sådana extensions chrome och liknande tillägg är diagnostikverktyg, inget annat, och de ändrar ingenting på själva servern.

”HTTP/2 ersätter behovet av en CDN”

Nej, de löser olika problem. En CDN (Content Delivery Network) placerar kopior av din sajt geografiskt nära besökaren, så att data inte behöver resa lika långt, till exempel från en server i New York till en besökare i Sverige. HTTP/2 effektiviserar själva överföringen oavsett avstånd. De kompletterar varandra, och de flesta CDN-leverantörer kör HTTP/2 som standard, så du får ofta båda på köpet.

”HTTP/2 har något att göra med en VPN”

Det här är en vanlig sammanblandning, så den är värd att reda ut kort. En VPN är en tjänst som krypterar din egen trafik och döljer din IP-adress, något helt annat än hur en server levererar en webbsida. Folk som söker på “what is vpn”, “is vpn”, “download vpn” eller funderar på en dedicated ip och olika vpn servers letar efter integritetsskydd och anonymity, inte efter ett överföringsprotokoll. HTTP/2 handlar om hur din sajt levereras till besökaren, medan en VPN handlar om hur en enskild användare surfar safe online. De två har ingenting med varandra att göra, även om båda nämner kryptering.

HTTP/2 i ett större sammanhang

Det är lätt att stirra sig blind på en enskild teknik, men HTTP/2 är en av många byggstenar i webbens infrastruktur. Det vilar på TCP, samarbetar med SSL för kryptering, och samexisterar med teknologier som WebSocket för realtidskommunikation och SSH för säker fjärranslutning. För dig som sajtägare behöver du inte förstå alla dessa lager i detalj, men det hjälper att veta att de finns och hur de hänger ihop, eftersom de ofta nämns i samma andetag.

För att placera HTTP/2 bland de tekniker det ofta förväxlas eller buntas ihop med:

• TCP är transportlagret HTTP/2 vilar på, alltså det som ser till att paketen kommer fram i rätt ordning.
• SSL sköter krypteringen som i praktiken krävs för att webbläsare ska aktivera HTTP/2.
• WebSocket håller en öppen tvåvägskanal för realtidsdata, något HTTP/2 inte ersätter.
• SSH används för säker fjärranslutning till servern och har inget med sidleverans att göra.
• CDN kompletterar HTTP/2 genom att korta det fysiska avståndet till besökaren.

Förhållandet till HTTPS och SSL

HTTP/2 och HTTPS hör ihop på ett sätt som är värt att upprepa. Även om standarden teoretiskt tillåter HTTP/2 utan kryptering, stödjer ingen av de stora webbläsarna det i praktiken. Microsoft Edge, Chrome och Firefox kräver alla att anslutningen är krypterad med ett giltigt certifikat. Det betyder att vägen till HTTP/2 nästan alltid går via HTTPS, vilket i sin tur är bra för säkerheten och för förtroendet hos både besökare och Google. Att secure your uppkoppling med SSL är alltså inte bara en säkerhetsåtgärd, utan också nyckeln som låser upp en high-speed leverans via HTTP/2.

Hur det hänger ihop med din WordPress-hosting

Om du kör WordPress, vilket en stor del av svenska företagssajter gör, är HTTP/2 oftast något din WordPress-hosting redan löst åt dig, och det går hand i hand med grunderna i SEO för WordPress. Bra hosting innebär modern serverprogramvara, aktiverat HTTP/2 och ofta en inbyggd CDN. Det är en av flera anledningar till att valet av webbhotell påverkar din sidhastighet mer än många tror. En billig, överbelastad delad server kan göra all din optimering om intet, oavsett hur fint protokoll den kör.

Det här är några tecken på att din WordPress Hosting drar nytta av HTTP/2 som den ska:

• Servern svarar snabbt även när flera besökare är inne samtidigt.
• HTTP/2 är aktivt, vilket du ser som “h2” i Network-fliken.
• Ett giltigt SSL-certifikat förnyas automatiskt utan att du behöver tänka på det.
• En CDN finns framför sajten och kör samma moderna protokoll.

Praktiska nästa steg

Vi har nu gått igenom vad HTTP/2 är, hur det fungerar och vad det betyder för din sajt. Om du bara ska komma ihåg en sak: HTTP/2 är ett tekniskt fundament som gör överföringen effektivare, men det är din helhet av snabb server, optimerade bilder och ren kod som avgör hur snabb sajten verkligen blir.

Här är en konkret att-göra-lista du kan följa direkt:

• Kontrollera om din sajt redan kör HTTP/2 via Network-fliken.
• Säkerställ att du har HTTPS med ett giltigt SSL-certifikat.
• Fråga ditt webbhotell om HTTP/2 om du fortfarande kör den gamla versionen.
• Sluta slå ihop filer i onödan, eftersom multiplexing gör det överflödigt.
• Lägg din energi på bildoptimering och att rensa onödiga plugins.
• Mät dina Core Web Vitals i Search Console innan och efter förändringar.

Och om du vill bygga vidare på grunden, här är några rimliga nästa steg i tur och ordning:

1. Optimera de tyngsta bilderna först, eftersom de nästan alltid är den största vinsten.
2. Rensa bort plugins och tredjepartsskript du inte längre använder.
3. Sätt upp cachning i webbläsaren och på servern så att återbesökare slipper hämta allt på nytt.
4. Lägg till eller utvärdera en CDN om dina besökare finns på flera orter eller länder.
5. Mät igen och jämför med utgångsläget, så att du ser om åtgärderna gjorde skillnad.

Vill du gräva djupare i hur det tekniska arbetet hänger ihop med en bredare plan för din synlighet kan en genomtänkt innehållsstrategi vara en bra punkt att utgå ifrån. HTTP/2 löser en sak väl: hur data reser mellan server och besökare. Resten av din prestanda och SEO bygger du ovanpå den grunden, steg för steg, och nästa steg är alltid det du själv kan mäta och påverka.