Under motorhuven: webbserver, PHP och databas

Modul 1: Hur WordPress fungerar · Lästid: 8 minuter

Lärandemål: Efter den här lektionen kan du steg för steg förklara hur en sidförfrågan hos WordPress blir en HTML-sida, och var en cache förkortar den vägen.

Nyckelbegrepp: webbserver (LiteSpeed, Apache, nginx), PHP, MariaDB/MySQL, query, index.php, mallhierarki, dynamisk vs statisk, TTFB

En statisk och en dynamisk sida

På en statisk webbplats ligger varje sida som en färdig fil på servern. Webbservern hämtar filen och skickar den vidare. Det är snabbt och enkelt, men varje ändring innebär en ny fil.

WordPress är dynamiskt: sidan existerar inte förrän någon efterfrågar den. Det finns ingen fil som heter contact.html. Det finns en text i databasen, ett tema med mallar och en mängd PHP-kod som sätter ihop dessa två. Det ger smidighet (du redigerar texten i din webbläsare), men det kostar beräkningsarbete vid varje besök. Förstår du det beräkningsarbetet förstår du också senare varför en webbplats är långsam, varför cachning gör så stor skillnad och varför en PHP-uppgradering kan göra sönder något.

En sidförfrågans resa

Säg att en besökare öppnar https://example.com/contact/. Så här går det till:

1. DNS: webbläsaren slår upp IP-adressen för example.com (se DNS-kursen). Den upprättar en säker anslutning till den adressen.
2. Webbserver: på servern körs en webbserver, till exempel LiteSpeed, Apache eller nginx. Den tar emot förfrågan. Finns det en riktig fil eller mapp med det namnet (en bild, en stilmall), skickar den den direkt. Annars gäller regeln från .htaccess (hos LiteSpeed och Apache) eller från nginx-konfigurationen: "skicka allt som inte finns till index.php".
3. PHP: index.php är en PHP-fil. Webbservern låter PHP köra den, programmeringsspråket som WordPress är skrivet i. PHP läser först in wp-config.php (inställningarna, med databasuppgifterna), sedan resten av WordPress, sedan alla aktiva tillägg och det aktiva temat.
4. Databas: WordPress tar reda på vilket innehåll som hör till /contact/ och ställer frågor till databasen (MariaDB eller MySQL): vilken sida har slugen contact, vilka är webbplatsens inställningar, vilken meny hör till? En sådan fråga kallas en query. Redan en enkel sida kan kosta ett trettiotal queries; med tillägg kan det bli hundratals.
5. Tema: WordPress väljer vilken mall i temat som formaterar sidan. Det sker enligt mallhierarkin: för en sida med slugen contact letar WordPress först efter en mall page-contact, sedan page-<id> (sidans nummer), sedan page, sedan singular och till slut index. Den första som finns vinner.
6. HTML tillbaka: resultatet är en HTML-sida som PHP ger till webbservern, och webbservern till webbläsaren.
7. Webbläsaren läser HTML:n och hämtar sedan stilmallar, skript, typsnitt och bilder. De är vanliga filer, så de kommer direkt från webbservern (eller från en cache).

Mellan steg 2 och steg 6 ligger tiden som servern behöver för att skapa sidan. Den ser du som TTFB (time to first byte): tiden mellan förfrågan och det första svarsbytet. På en välkonfigurerad webbplats ligger den gott under en sekund. I modul 6 mäter du det själv.

Varför varje tillägg räknas

I steg 3 laddas alla aktiva tillägg, vid varje förfrågan. Även om det tillägget inte gör något på just den här sidan. Ett tillägg för ett fotogalleri laddas alltså även när någon öppnar din kontaktsida. Varje tillägg kan göra fler queries, ladda extra kod och lägga till extra skript på sidan.

Det förklarar två saker du stöter på flera gånger i den här kursen:

• Färre tillägg är oftast snabbare. Inte för att antalet i sig spelar roll, utan för att varje tillägg kan göra arbete vid varje förfrågan.
• Ett trasigt tillägg kan lägga ner hela webbplatsen. Går något fel i steg 3 (till exempel ett tillägg som inte fungerar med den nya PHP-versionen), når PHP aldrig fram till steg 6. Besökaren får en vit sida eller meddelandet "Det har uppstått ett kritiskt fel på den här webbplatsen" (lektion 5.4).

Var PHP och databasen kommer ifrån

PHP och databasen körs på din hostingleverantörs server. Du väljer oftast själv PHP-version i kontrollpanelen (hos DirectAdmin kallas det Select PHP version, se lektion 8.4). Databasen skapar du vid installationen; installationsprogrammet gör ofta det åt dig (lektion 2.2).

Några saker att komma ihåg:

• PHP-version: varje ny PHP-version är snabbare och säkrare, men gammal kod kan gå sönder på den. wordpress.org rekommenderar för närvarande PHP 8.3 eller högre (läget november 2026).
• Databas: wordpress.org rekommenderar MariaDB 10.11 eller högre, eller MySQL 8.0 eller högre. MariaDB är en avknoppning av MySQL; för WordPress gör det ingen skillnad.
• Databasen ligger oftast på samma server (DB_HOST är då localhost). Vid större hostinglösningar kan den ligga på en separat server.

Cache: att förkorta vägen

Om hundra besökare efterfrågar samma kontaktsida bygger WordPress den hundra gånger om, utan cache. Varje gång samma queries, samma mall, samma HTML. En sidcache sparar HTML:n efter första gången. Nästa besökare får den sparade versionen: steg 3 till och med 6 faller bort.

Utan cache:  browser > webbserver > PHP > WordPress + tillägg > databas > tema > HTML
Med cache:     browser > webbserver > sparad HTML

Det är därför cachning ger den största hastighetsvinsten (lektion 6.2). Det förklarar också en vanlig missuppfattning: "jag har ändrat texten men ser fortfarande den gamla versionen." Då får du en sparad version; efter att cachen tömts ser du den nya.

Allt kan inte komma från en cache. En inloggad administratör, en varukorg eller en kassasida ser olika ut för varje besökare. Ett bra cachetillägg hoppar över dem.

Headers: vad servern berättar för dig

Varje svar från en webbserver börjar med headers, före HTML:n. De syns inte på sidan, men väl i webbläsarens utvecklarverktyg (F12, fliken Nätverk, klicka på den första förfrågan). Ett exempel:

HTTP/2 200
server: LiteSpeed
content-type: text/html; charset=UTF-8
link: <https://example.com/wp-json/>; rel="https://api.w.org/"
x-litespeed-cache: hit

• server anger vilken webbserver som svarar.
• link med wp-json avslöjar att det är WordPress.
• x-litespeed-cache: hit betyder att den här sidan kom från LiteSpeed-cachen. Andra cachelösningar använder andra namn, till exempel x-cache: HIT eller cf-cache-status: HIT hos Cloudflare.

Du behöver inte kunna de här raderna utantill. Men den som kan läsa dem kan hitta många problem själv.

Sammanfattning

• WordPress bygger varje sida i det ögonblick den efterfrågas: webbserver, PHP, tillägg, databas, tema, HTML.
• Vid varje förfrågan laddas alla aktiva tillägg; ett trasigt tillägg kan stoppa hela webbplatsen.
• Mallhierarkin bestämmer vilken mall i temat som formaterar en sida.
• En sidcache hoppar över beräkningsarbetet genom att ge sparad HTML. Inloggade användare och varukorgar hör inte hemma i den cachen.
• Ett svars headers berättar vilken webbserver som svarar och om sidan kom från en cache.

Quiz

Uppgift

Uppgift A1.2: Läs headers på din webbplats. Öppna din egen webbplats (eller wordpress.org) med webbläsarens utvecklarverktyg (F12, fliken Nätverk, uppdatera sidan, klicka på den första förfrågan). Fyll i vilken webbserver som står i headern server (eller "ingen" om den saknas) och om det finns en header som säger att sidan kom från en cache (vilket namn och vilket värde). Programmet hämtar samma sida och jämför.

Läs mer

Dessa artiklar beskriver stegen i WebOkés kontrollpaneler; i andra paneler fungerar det på liknande sätt.

• DirectAdmin-guide 1.9: Begrepp förklarade: domän, underdomän, pointer, DNS, brevlåda och databas
• DirectAdmin-guide 14.1: PHP-versionen välja (Select PHP version)
• Gratis DNS-kurs 1.4: Resan för en DNS-fråga
• Mallhierarki (developer.wordpress.org, Engelska): https://developer.wordpress.org/themes/basics/template-hierarchy/