Hur vi gjorde WordPress snabbare än generatorer för statiska webbplatser (Fallstudie – Snabbare WPBeginner)

På 10-årsdagen av WPBeginner delade jag med mig av att WPBeginners infrastruktur för webbhotell fick en enorm uppgradering tack vare vår webbhotellspartner HostGator.

Kort därefter började jag få email från läsare som bad mig att dela med mig av detaljerna om hur vi fick WPBeginner att ladda blixtsnabbt.

Ja, WPBeginner laddar snabbare än de flesta generatorer för statiska webbplatser och i vissa fall snabbare än Googles AMP webbplatser också.

I den här artikeln kommer jag att ge dig en titt bakom kulisserna på hur vi gjorde WordPress snabbare än statiska site generatorer och headless CMS-plattformar.

Note: Den här artikeln är lite mer teknisk än vad vi vanligtvis publicerar på WPBeginner. För icke-tekniska användare rekommenderar jag att du följer vår ultimata guide om hur du snabbar upp WordPress.

Update: Vi använder inte längre den installation som delades i den här artikeln. Istället har vi bytt helt till Google Cloud-plattformen som hanteras av SiteGround. Vi har samma hastighetsresultat och har låst upp ännu snabbare back-end-prestanda. Läs varför vi bytte till SiteGround.

Bakgrund

På senare tid har WordPress fått en hel del dåligt rykte från ”moderna” utvecklare som säger att WordPress är långsamt.

Uttalandet brukar följas upp med, du bör byta till en JAMstack statisk site generator gillar GatsbyJS. Andra i företagsvärlden kommer att säga att you should switch to a headless CMS like Contentful.

Flera av mina mycket utan problem entreprenörsvänner började fråga mig om detta var sant.

Vissa började till och med flytta till ett headless CMS eftersom de läste fallstudier om hur andra unlockade enorma hastighetsförbättringar genom att byta från WordPress till statiska site generatorer.

Detta var mycket frustrerande för mig eftersom jag visste att de slösade bort tiotusentals dollar i kostnader för att flytta. Eller ej, för att inte tala om de oändliga kostnader för customize som kommer att uppstå i framtiden.

Så jag tog det som en utmaning att bevisa att en stor webbplats med WordPress content gillar WPBeginner kan hämta lika snabbt eller ej snabbare än de flesta moderna statiska webbplatsgeneratorer.

You can call me old school, but at the end of the day, a static site is just a page loading from cache.

Resultat

Innan jag går in på den exakta infrastrukturen för webbhotell WordPress, konfigurationer av server och tillägg, tror jag att det är bra att dela med sig av resultaten.

Här är hur snabbt WPBeginners home page hämtar på Pingdom från deras server i Washington, DC:

Beroende på vilken tid på dagen och vilken location du kontrollerar från, kommer detta resultat att variera mellan 400ms – 700ms, vilket är ganska snabbt för en homepage.

Här är ett test som jag körde för en page med ett enskilt inlägg eftersom den har större images och mer content:

Vi fick också en perfekt poäng på ”100” i Googles sidhastighetstest för skrivbordet. Även om vi har lite utrymme för förbättringar på mobilpoängen.

Resultaten ovan är för cachelagrade pages vilket är vad våra Läsare och search engine bots får när de viewar vår website. Den upplevda laddningstiden för WPBeginner är nästan omedelbar (mer om detta senare).

För jämförelsens skull, här är ett hastighetstestresultat för Gatsbys homepage. Detta är en populär statisk site generator som många utvecklare är förtjusta i:

Här är hastighetstestresultatet för Netlifys homepage, en populär server för statiska webbplatser, som många utvecklare rekommenderar. Notice that they have half the amount of requests, and their page size is 30% of WPBeginner, yet it still loads slower than our homepage.

Hastigheten på homepage för Contentful, det huvudlösa CMS som är ”hur företag levererar bättre digitala upplevelser” är helt enkelt inte optimerad all. Detta var den långsammaste website vi testade.

Jag delar denna statistik inte för att misskreditera de andra ramverken, utan snarare för att ge perspektiv på att inte alla nya saker är så glänsande som de kan verka.

WordPress med rätt infrastruktur för webbhotell och optimeringar kan vara lika snabbt som vilken statisk generator som helst. Dessutom kommer ingen annan plattform ens i närheten av den flexibilitetsnivå som WordPress erbjuder företagare genom sitt stora ekosystem av tillägg och themes.

WPBeginner Infrastruktur för webbhotell

När det gäller webbplatsens hastighet spelar inget en viktigare roll än ditt webbhotells infrastruktur.

Som många av er redan vet har jag varit kund hos HostGator sedan 2007. Jag startade WPBeginner-bloggen 2009 på ett litet HostGator-konto för delat webbhotell.

När vår website växte uppgraderade vi till deras VPS webbhotell och sedan till dedikerade servrar.

Under det senaste decenniet har jag fått chansen att arbeta close med många av deras teammedlemmar, och de har blivit en utökad del av WPBeginners familj.

Så när jag tog mig an utmaningen att göra WPBeginner snabbare än generatorer för statiska webbplatser vände jag mig till dem för att få hjälp.

Jag delade min vision med deras ledningsgrupp, och de erbjöd sig att hjälpa mig att bygga ett unikt webbhotell för WPBeginner.

De satte de bästa ingenjörerna från både Bluehost och HostGator att arbeta close med mig för att göra WPBeginner blixtsnabbt.

Här är en översikt över hur WPBeginners webbhotell gillar att se ut:

Som you can see, this is a multi-server setup spread across two geographical regions (Texas and Utah). Det finns totalt 9 servrar som ej inkluderar lastbalanserarmolnet. Varje server är en Xeon-D CPU med 8 cores (16 threads) med 32 GB RAM och 2 x 1 TB SSD (RAID-installation).

Vi använder Googles Cloud Load Balancing-plattform, så att vi kan ha sömlös automatisk skalning och lastbalansering över hela världen.

När hårdvaran var konfigurerad med korrekt datasynkronisering på plats arbetade Bluehost- och HostGator-teamen tillsammans för att optimera konfigurationen av servern för WordPress. Min förhoppning är att några av dessa optimeringar snart kommer att finnas med i framtida planer för webbhotell för WordPress

Sammanfattning av konfiguration av server

Att sammanfatta konfigurationen av servern i denna komplexa installation i några få punkter är svårt, men jag ska göra mitt bästa.

Vi använder Apache för vår programvara för web server eftersom teamet är mer bekant med det. Jag kommer inte att gå in på debatten om NGINX vs Apache.

Vi använder PHP 7.2 tillsammans med PHP-FPM-pooler, så att vi kan hantera höga hämtar av processer och requests. Om ditt webbhotell inte använder PHP 7+, går du miste om en seriös hastighetsoptimering.

Vi använder Opcode caching med en avancerad cache-varnare för att säkerställa att ingen riktig användare ska uppleva en ocachad sidvisning.

Vi använder också Object cache med memcache, så att vi kan förbättra svarstiden för ocachade page hits och andra API-svarstider i WordPress admin area för inloggade användare (våra skribenter). Här är en network load tabs av vår ”All Posts” vy i WordPress admin:

För att sätta det i perspektiv är vår upplevelse av admin area nu 2X snabbare än vad vi hade tidigare.

För vår server för databaser bytte vi från MySQL till MariaDB, som är en klon av MySQL men snabbare och bättre. Vi bytte också från HyperDB till LudicrousDB eftersom det hjälper oss att förbättra vår replikering av databaser, failover och lastbalansering.

Det finns också många andra konfigurationer som hjälper oss med prestanda och skalbarhet som HTTP/2 och HSTS för snabbare anslutning + Encryption, möjlighet att snurra upp ytterligare servrar i nya regioner i händelse av datacenteravbrott etc.

Det känns som om jag inte gör rättvisa åt den fantastiska setup som teamet har byggt, men ni ska vänligen veta att min core-styrka är marknadsföring. Ja, jag är en bloggare som skriver om WordPress, men många av de tekniska optimeringarna här är långt ovanför min lönegrad.

De gjordes av supersmarta ingenjörer i Endurance-teamet inklusive David Collins (chefsarkitekt för Endurance / CTO för HostGator), Mike Hansen (core WordPress utvecklare), och andra som jag kommer att tacka i krediter sektionen under.

CDN, WAF och DNS

Notis: Förutom webbhotell är de andra area som spelar en viktig roll för hastigheten på din website din DNS provider, ditt content delivery network (aka CDN) och din web application firewall (WAF).

Även om jag har listat det som tre separata saker, erbjuder många företag nu dessa lösningar i en sammansatt plan som Sucuri, Cloudflare, MaxCDN (StackPath), etc.

Eftersom jag vill ha maximal control och sprida riskerna använder jag tre separata företag för att hantera varje del på ett effektivt sätt.

WPBeginners DNS drivs av DNS Made Easy (samma företag som Constellix). De rankas konsekvent som de snabbaste DNS providers i världen. Fördelen med DNS Made Easy är att jag kan göra global trafikstyrning när ett specifikt centrerat datacenter på mitt CDN eller WAF inte fungerar som det ska för att säkerställa maximal upptid.

Vårt CDN drivs av MaxCDN (StackPath). De tillåter oss i princip att servera våra statiska filer (images, CSS-filer och JavaScript) från deras stora nätverk av servrar över hela världen.

Vi använder Sucuri som vår firewall för webbapplikationer. Notis: Förutom att blockera attacker fungerar de också som ett annat lager av CDN, och deras övergripande prestanda är helt enkelt fantastisk. Jag tror att de har den bästa lösningen för en firewall för WordPress på marknaden.

När du arbetar med hastighetsoptimering av websites är det viktigt att spara varje millisekund. Därför gör det stor skillnad att använda dessa lösningsleverantörer i kombination med vår nya infrastruktur för webbhotell.

För att illustrera, här är vattenfallsuppdelningen av WPBeginner.com vs GatsbyJS.org vs CloudFlare.com:

Notice that WPBeginner’s DNS time, SSL time, Connect time, and Wait time are all högst upp jämfört med dessa andra populära websites. Var och en av dessa förbättringar samverkar för att leverera de bästa resultaten.

Instant.page, optimerade images och andra bästa metoder

En av de saker du kanske har noterat är den nästan omedelbara laddningstiden när du browsar WPBeginners post och pages.

Notis: Förutom allt jag nämnde ovan, fuskar vi också med latensen genom att använda ett skript anropat omedelbar.page som använder just-in-time-förladdning.

I grund och botten innan en användare klickar på en länk måste de hovera musen över den länken. När en användare har hoverat i 65 ms (mycket kort tid) kommer en av två faktiskt att klicka på länken.

Instant.page-skriptet börjar förladda den page i detta ögonblick, så när användaren faktiskt klickar på länken är mycket av det tunga lyftet redan gjort. Detta gör att den mänskliga hjärnan uppfattar webbplatsens laddningstid som nästan omedelbar.

För att aktivera Instant.page på din site, kan du helt enkelt installera och aktivera Instant Page WordPress plugin.

Det här skriptet är ganska snyggt. Jag rekommenderar starkt att du kontrollerar deras website och klickar på knappen ”test your clicking speed” för att se hur det lurar hjärnan.

Update: Jag har inaktiverat instant.page för tillfället, och jag kommer att testa FlyingPages plugin inom en snar framtid. Gijo Varghese delade sitt new plugin med mig i WPBeginner Engage Facebook-gruppen, och det verkar kombinera det bästa av instant.page och quicklink script.

Optimera Images för webben

Även om det finns nya format för images som utvecklas, till exempel webp, använder vi dem inte ännu. Istället ber vi alla våra skribenter att optimera varje image med hjälp av TinyPNG tool.

Du kan också automatisera komprimeringen av images med tillägg som Optimole eller EWWW Image Optimizer.

Personligen föredrar jag dock att låta teamet göra detta manuellt, så att vi ej uploadar stora filer på servern.

För närvarande gör vi inte någon lazy loading för images, men jag har planer på att add to det inom en snar framtid nu när Google har lazy loading support built-in i Chrome 76.

Det finns också en ticket i WordPress core för att lägga till denna funktion på alla webbplatser (hoppas verkligen att detta händer snart), så jag behöver inte skriva en custom plugin.

Update: Några timmar efter att jag publicerade blogginlägget släppte Google Native Lazy Loaded plugin för WordPress.

Limiting HTTP Queries + Bästa praxis

Beroende på vilka WordPress plugins du använder, kommer vissa att lägga till ytterligare CSS- och JavaScript-filer vid varje hämning av sidan. Dessa ytterligare HTTP-förfrågningar kan komma ur kontroll om du har många tillägg på din website.

För mer detaljer, se hur tillägg till WordPress kan påverka din sites laddningstid.

Innan du nu drar den felaktiga slutsatsen att för många WordPress-tillägg är dåligt, vill jag berätta att det finns 62 aktiva tillägg som körs på WPBeginners website.

Vad du behöver göra är att kombinera CSS- och JavaScript-filer där det är möjligt för att minska HTTP-requests. Vissa tillägg för caching WordPress gillar WP Rocket kan göra detta automatiskt med sin utvalda funktion för minifiering.

Du kan också följa instruktionerna i den här artikeln för att göra det manuellt, vilket är vad vårt team på WPBeginner har gjort.

Notis: Förutom HTTP-förfrågningar som plugins och themes lägger till, vill du också vara uppmärksam på andra tredjepartsskript som du lägger till på din webbplats eftersom varje skript kommer att påverka din webbplats hastighet.

Om du till exempel runar många Advertising-skript eller retargeting-skript kommer de att sakta ner din site. Du kanske vill använda ett verktyg som Google Tag Manager för att villkorligt ladda skript endast när de behövs.

Om du är en annonsstödd website gillar TechCrunch eller TheNextWeb, då finns det väldigt lite du kan göra åt detta eftersom det inte är ett alternativ att ta bort annonser.

Lyckligtvis förlitar sig WPBeginner inte på tredjepartsannonsskript för att tjäna pengar. Vill du se hur WPBeginner tjänar pengar? Se mitt blogginlägg om WPBeginners inkomster.

Lärdomar (hittills) + mina slutliga tankar

Detta är ett helt nytt webbhotell, och jag är säker på att det finns massor av lärdomar som jag kommer att lära mig övertid.

Hittills älskar jag hastighetsförbättringarna eftersom det har hjälpt oss att öka vår sökmotorsoptimering och vårt admin area är mycket snabbare.

Med den nya multi-site-installationen introducerade vi ett nytt distributionsarbetsflöde för att få WPBeginner i nivå med resten av Awesome Motives produktwebbplatser.

Vad detta innebär är att vi nu har ordentlig versionskontroll built-in, och det finns åtgärder på plats för att hindra mig från att vara vårdslös (dvs. lägga till plugins utan ordentlig testning, updating av plugins från dashboarden utan testning, etc.)

Dessa förändringar banar också väg för att jag äntligen ska kunna lämna utvecklarna och lämna över ledningen av WPBeginners site till vårt utvecklingsteam.

Jag har motstått detta i flera år, men jag tror att tiden kommer och jag behöver bara godkänna det.

Den nya installationen har inte cPanel eller WHM, så det gör mig praktiskt taget värdelös ändå eftersom jag inte är särskilt flytande med kommandoraden längre.

Hittills har vi lärt oss två stora läxor:

För det första är updating av WordPress inte lika enkelt på grund av synkronisering/replikering av server. När vi uppgraderade min personliga blogg (SyedBalkhi.com) till WordPress 5.2 synkroniserades inte update-filerna ordentligt på en av webbnoderna, och debug tog mycket längre tid än väntat. Vi arbetar på att bygga en bättre bygg- och testprocess för detta.

För det andra måste vi ha bättre kommunikation mellan olika team eftersom vi hade en mindre kris med felkonfigurationer av lastbalanserare som resulterade i viss nedtid. För att göra det värre var jag på en transatlantisk flygning med Turkish Airlines, och WiFi fungerade inte.

Lyckligtvis ordnade sig allt tack vare webbhotellets snabba response, men det hjälpte oss att skapa flera new standardrutiner (SOP) för att bättre kunna hantera incidenten i framtiden.

Överlag är jag mycket nöjd med installationen, och jag vet att några av de konfigurationer och optimeringar av caching som gjordes för WPBeginner kommer att bli en standarddel av HostGator Cloud och Bluehosts planer för webbhotell för WordPress.

Jag tycker att det borde vara självklart att om du precis har startat en website, blogg eller en store, så behöver du ej denna sofistikerade företagsinställning.

Jag rekommenderar alltid att du börjar smått med HostGator delade eller Bluehost delade planer gillar jag gjorde, och sedan uppgradera din webbhotell infrastruktur när ditt företag växer.

Du kan tillämpa många av de optimeringar som jag delade ovan på din nuvarande WordPress planer för webbhotell.

Till exempel kommer Bluehosts standardplan redan med ett built-in plugin för caching som du kan använda, och de erbjuder PHP 7 som standard också.

Du kan kombinera det med ett CDN + WAF som Sucuri för att avsevärt snabba upp din website.

Om du nu är ett företag i mellansegmentet som vill ha ett liknande webbhotell, vänligen kontakta mig via vårt kontaktformulär. Jag kan hjälpa dig att peka i rätt riktning.

Särskilt tack + krediter

Medan jag i artikeln ovan har gett massor av skrik till HostGator och Bluehost varumärken, vill jag ta en stund att känna igen och uppskatta de enskilda personer som arbetade bakom kulisserna för att få det att hända.

Först vill jag säga tack till Endurance-ledargruppen Suhaib, Mitch, John Orlando, Mike Lillie och Brady Nord för att de gick med på att hjälpa mig med utmaningen.

Jag vill också tacka Mike Hansen, David Collins, Rick Radinger, Chris Miles, David Ryan, Jesse Cook, David Foster, Micah Wood, William Earnhardt, Robin Mendieta, Rod Johnson, Alfred Najem och andra i teamet i datacentret för att de faktiskt gjorde det hårda arbetet och fick det att hända.

Jag vill ge en särskild eloge till Steven Job (grundare av DNSMadeEasy) för att han snabbt svarade på mina frågor och hjälpte mig att bättre förstå vissa Settings. Jag vill också ge en eloge till Tony Perez och Daniel Cid kl Sucuri för att de alltid har stöttat mig.

Sist men ej minst vill jag ge ett särskilt erkännande till Chris Christoff. Han är medgrundare av MonsterInsights, och han var vänlig nog att hjälpa mig med en hel del av testningen och driftsättningen.

Jag hoppas verkligen att du tyckte att den här bakom kulisserna-fallstudien om WPBeginners infrastruktur för webbhotell var till hjälp. You may also want to see our ultimate guide on how to speed up WordPress som är mycket mer nybörjarvänlig.

Bonus: Här är de bästa tillägg och tools för WordPress som jag rekommenderar för alla WordPress webbplatser.

Om du gillade den här artikeln, vänligen prenumerera på vår YouTube-kanal för WordPress video tutorials. Du kan också hitta oss på Twitter och Facebook.