Webbhotell med PHP-stöd

PHP-stödet avgörs av mer än ett versionsnummer

PHP driver merparten av webben, inklusive WordPress, Joomla, PrestaShop och otaliga egenutvecklade system. Ändå är PHP-stödet ett av de mest missförstådda kriterierna när man väljer webbhotell. Frågan är inte om ett webbhotell kör PHP, det gör nästan alla, utan vilken version som körs som standard, hur enkelt det är att byta, och vilka resursgränser som faktiskt gäller när trafiken ökar.

Det finns en stor praktisk skillnad mellan ett webbhotell som erbjuder PHP 8.3 som ett alternativ du måste aktivera manuellt, och ett som kör det som standard för alla nya sajter. Standardversionen är vad dina sajter faktiskt använder om du inte aktivt ändrar den. På äldre delade servrar är det inte ovanligt att standardvalet fortfarande är PHP 8.0 eller 8.1, versioner som saknar säkerhetsuppdateringar sedan länge.

PHP-versioner: livscykel och vad som faktiskt gäller

PHP:s officiella livscykel innebär att varje version får aktiva buggrättningar i två år, följt av ytterligare ett år med enbart säkerhetsuppdateringar. PHP 8.1 nådde end-of-life i december 2024, PHP 8.2 tar slut i december 2025. Att ett webbhotell erbjuder en version i sin kontrollpanel är inte samma sak som att den versionen underhålls av hosten med egna säkerhetspatchar. Frågan du bör ställa är alltså om det handlar om paketet från det officiella PHP-projektet eller om hosten kompilerar och patchat egna byggen.

PHP 8.2 och 8.3 innebar bland annat union types, readonly properties, fibers (för mer lättläst asynkron kod) och förbättrad typhantering. PHP 8.4, lanserad november 2024, tillförde property hooks och asymmetrisk synlighet, vilket gör objektorienterad PHP-kod mer uttrycksfull. Moderna ramverk som Laravel 11 kräver minst PHP 8.2. Väljer du ett webbhotell som låser fast dig vid äldre versioner begränsar det ditt val av verktyg och bibliotek framåt.

PHP-FPM kontra mod_php: vad det innebär i praktiken

Det finns två dominerande sätt att köra PHP på en webbserver, och skillnaden påverkar både prestanda och säkerhet.

mod_php är den äldre metoden, där PHP laddas som en modul direkt i Apache-processen. Varje Apache-tråd bär med sig hela PHP-runtime, oavsett om begäran ens behöver PHP. Det är resursslöseri, och det innebär att alla virtuella hostar på servern delar samma PHP-process och därmed samma systemanvändare, vilket är en säkerhetsrisk på delade servrar.

PHP-FPM (FastCGI Process Manager) kör PHP som en separat processpol, frikopplad från webbservern. Det ger flera fördelar: varje sajt kan ha sin egen FPM-pool med egna systemrättigheter, processen startas bara när PHP faktiskt behövs, och konfigurationsparametrar kan sättas per sajt. Moderna webbhotell som vill leverera god isolering och prestanda kör PHP-FPM, ofta i kombination med LiteSpeed eller Nginx.

I kombination med PHP-FPM är det också möjligt att köra olika PHP-versioner parallellt på samma server, en per sajt om det behövs. Det är den tekniken som gör att bättre webbhotell kan erbjuda ett enkelt versions-switch i kontrollpanelen utan att det påverkar grannens sajt.

OPcache och JIT: hur PHP cachelagrar sig självt

PHP är ett tolkande språk, vilket traditionellt sett innebär att källkoden läses, parsas och kompileras till bytekod vid varje sidladdning. OPcache (Opcode Cache) lagrar den kompilerade bytekoden i minnet och hoppar över kompilieringssteget vid nästa request för samma fil. Effekten är markant: OPcache kan halvera svarstiden för PHP-tunga sidor och minska CPU-belastningen med 30-60 procent. Det bör vara aktiverat som standard hos alla moderna webbhotell.

I PHP 8.0 introducerades JIT-kompilering (Just-In-Time), ett steg längre än OPcache. JIT kompilerar bytekoden vidare till maskinkodinstruktioner som processorn kör direkt, utan tolkning. Resultatet är dramatiskt för beräkningsintensiva uppgifter, bildredigering, kryptering, vetenskapliga beräkningar. För typiska webbapplikationer som WordPress eller WooCommerce är vinsten mer modest, ofta 5-15 procent, eftersom dessa applikationer tillbringar mer tid i I/O-operationer (databas, filsystem) än i ren CPU-beräkning. JIT är ändå ett tecken på en modern PHP-installation, och webbhotell som kör PHP 8.x med JIT aktiverat har åtminstone inte aktivt vridit bort prestanda-möjligheter.

Vad du kan kontrollera: be hosten om vilka OPcache-inställningar de kör, eller kolla via ett PHP-infoskript. Intressanta värden är opcache.memory_consumption, opcache.max_accelerated_files och opcache.validate_timestamps. En produktion med validate_timestamps=0 och manuell cache-invalidering ger bäst prestanda men kräver att cachain töms vid koddeploy.

PHP-tillägg: vad som behöver finnas

PHP-kärnan är slimmad. Det är tilläggen (extensions) som ger den faktiska funktionaliteten som webbapplikationer bygger på. Saknas ett tillägg som ditt CMS, ramverk eller plugin kräver är det inget fel du kan felsöka bort i koden.

Välkonfigurerade delade webbhotell kompilerar en bred uppsättning tillägg som standard. Det som bör finnas inkluderar bland annat:

• mysqli / PDO_MySQL för databasanslutning mot MySQL och MariaDB
• GD / Imagick för bildbehandling (WordPress, Joomla och de flesta e-handelsystem kräver minst ett av dessa)
• curl för HTTP-anrop mot externa API:er
• mbstring för korrekt hantering av multibyte-tecken som å, ä och ö
• openssl / sodium för kryptografi och säkra anslutningar
• zip / zlib för komprimering och pakethantering
• intl för internationalisering, datumsformat och språkhantering
• xml / simplexml / dom för XML-parsing, används bland annat av RSS-feeds och API-integrationer

Tillägg som ibland behöver aktiveras separat är Redis och Memcached för objektcachning, APCu som ett lättare alternativ, och XDebug för debugging i utvecklingsmiljö. XDebug ska inte köras i produktion då det påverkar prestanda märkbart. Ramverk som WordPress och Laravel kommunicerar tydligt vilka tillägg de kräver, och det är en enkel kontroll att göra mot vad webbhotellet faktiskt erbjuder.

Möjligheten att styra PHP per sajt

På ett välkonfigurerat delat webbhotell ska du kunna påverka PHP-inställningarna för din specifika sajt, inte bara acceptera serverns globala standardvärden. De vanligaste metoderna är via en .user.ini-fil i rotkatalogen för sajten, via .htaccess med php_value-direktiv (fungerar med mod_php men inte alltid med PHP-FPM), eller via ett GUI i kontrollpanelen.

Det finns webbhotell som låser dessa möjligheter helt, av säkerhetsskäl eller av bekvämlighetsskäl. Det är en begränsning som ger problem när en plugin kräver högre upload_max_filesize eller när du kör ett skript som behöver mer tid än standardvärdet tillåter. Se det som en röd flagga om hosten inte kan visa hur du justerar dessa värden, alternativt om det kräver ett supportärende.

Möjligheten att köra olika PHP-versioner per sajt är ännu viktigare om du hanterar flera sajter på samma konto. En äldre webbplats byggd för PHP 7.4 ska kunna sambos med en ny Laravel-sajt på 8.3, utan att de stör varandra. Det är det PHP-FPM med separata pooler möjliggör, och det bör vara ett grundkrav om du förvaltar mer än en sajt.