När det gäller WordPress-webbplatser, kan inte alla av dem behandlas på samma sätt när det gäller vad som fungerar bäst för prestanda. En enkel femsidig WordPress webbplats beter sig helt annorlunda än till exempel en stor WooCommerce webbplats (som kan vara mycket krävande). WordPress medlemskaps och gemenskapswebbplatser är en annan typ som faller i vad vi ibland kallar denna ”knepiga” kategori. Om du inte installerar eller konfigurerar korrekt befinner du dig snart i en mardröm med 500-fel, driftstopp och långsam sidladdning. Men det betyder inte att du inte har alternativ, du behöver bara följa bästa praxis.
Idag ska vi utforska vad du bör och inte bör göra för WordPress medlemskapawebbplatser och hur man bäst optimerar dem för att säkerställa optimal prestanda, skalbarhet och livslängd. 🚀
- Exempel på medlemskapssidor
- Varför WordPress medlemskapssidor är annorlunda
- Vad du bör göra för WordPress medlemskapssidor
- Vad du inte bör göra för WordPress medlemskapssidor
Exempel på medlemskapssidor
Här är bara några exempel på några vanliga WordPress medlemskaps och gemenskapswebbplatser:
- En webbplats byggd kring en Lärplattform (LearnDash, Lifter LMS) som säljer digitala kurser till sina medlemmar. Dessa håller på att bli riktigt populära på senaste tiden och det finns några fantastiska LMS-plugins där ute!
- En forumsbaserad (bbPress eller BuddyPress) WordPress-webbplats som främst används av medlemmar för att diskutera olika ämnen.
- Ett medlemskapssida byggd på en av de många populära allt-i-ett tredjeparts medlemskapsplugin (MemberPress eller Ultimate Membership Pro).
- Ett socialt nätverks-fokuserat community (PeepSo).
- Vissa kan också räkna med e-handelslösningar som WooCommerce och Easy Digital Downloads som medlemssidor eftersom många av dessa har användarprofiler och diskussionsfunktioner.
Varför WordPress medlemskapssidor är annorlunda
Innan vi hoppar in vad du bör och inte bör göra, låt oss dyka in i några anledningar till varför WordPress medlemskapssidor är annorlunda än din vanliga blogg eller webbplats för ditt lilla företag.
1. Icke-cachebart Innehåll
Först av allt, medlemskapssidor innehåller en hel del icke-cachebart innehåll och sidor som ständigt förändras. Saker som inloggningssidan för communitymedlemmar (som kan bli träffad ständigt beroende på webbplatsens storlek), kassasidor för digitala varor eller kurser, och diskussionsforum är vanliga syndabockar och smärtpunkter, eftersom dessa vanligtvis inte kan cachas.
Men det slutar inte där. På vanliga WordPress-webbplatser är WordPress-panelen inte cachad för ”inloggade” användare. Det här är bra när du bara har några författare och administratörer, men när du plötsligt har tusentals medlemmar som använder instrumentpanelen orsakar det omedelbart prestandaproblem eftersom inget av det kan servas från cacheminnet på servern. Det betyder att du behöver kraften och arkitekturen bakom kulisserna för att backa upp det. Delade hosting-leverantörer kommer vanligtvis lamslå dig under dessa omständigheter.
I MyKinsta analytics-verktyget som vi tillhandahåller för våra klienter kan du se hur mycket cache som kringgås. Nedan visas ett exempel på en webbplats där en stor majoritet av begäran inte servas från cacheminnet.
2. Ett stort antal samtidiga besökare
Det andra problemet som medlemskapssidor vanligtvis har är ett stort antal samtidiga besökare och sessioner. På en informations- eller företagswebbplats, kan en besökare stanna i fem eller 10 minuter tills de hittar vad de behöver (och detta är en hög siffra, vanligtvis är avvisningsfrekvenserna mycket högre). På medlemskapssidor, händer det motsatta. Besökare kommer vanligtvis till webbplatsen för att engagera med något eller någon. Om de går igenom en online-kurs är det inte ovanligt för dem att stanna i timmar. Du kan se vart detta är på väg. De samtidiga besökare anslutna till din WordPress-värd kommer snabbt att bli många.
För att göra det värre, har du sedan ett stort antal samtidiga besökare ovanpå ”icke-cachebart innehåll” -problemet.
3. Komplexa Förfrågningar
För det tredje genererar medlemssidor vanligtvis mer komplexa förfrågningar, vilket i sin tur lägger till ytterligare latens för att hämta informationen från MySQL-databasen. Mycket av detta beror helt enkelt på alla extra rörliga delar och stora mängder data som sajter som dessa har. Detta kan också orsakas av webbplatser som är starkt beroende av sökningar som navigering eller använder WP_Query.
Och dessutom de stora mängder samtidiga användare som kontinuerligt skickar förfrågningar till databasen.
4. Lagrar mycket data
Det är inte direkt förvånande, men medlemskapssidor lagrar en hel del data och om den inte hanteras på rätt sätt (som vi kommer att gå igenom nedan), kan ditt diskutrymme snabbt bli för litet. Detta läggs också ihop under webbplatsens livstid. Videor, kurser, medlemskap och profilinformation, diskussioner, digitala nedladdningar, etc. Dessa är bara några av de många olika typer av innehåll som snabbt läggs ihop till en mycket stor mängd.
Vad du bör göra för WordPress medlemskapssidor
Vi hostar många Medlemskapssidor på Kinsta och våra ingenjörer interagerar ständigt med dessa webbplatsägare dagligen. Även om vi alltid uppmuntrar användare att implementera bästa webbprestandapraxis, är detta vanligtvis inte tillräckligt när det gäller dessa typer av webbplatser. Så idag visar vi dig några sätt att göra det lilla extra för att säkerställa att din medlemskapssida och dess besökare har en så bra upplevelse som möjligt.
1. Välj en prestationsfokuserad WordPress-värd
Råd att välja en bättre WordPress-värd kan tyckas vara en tråkig upprepning vid det här laget, men sanningen är att många prestandaproblem med medlemssidor kan spåras tillbaka till detta som grundorsaken. Vi har gång på gång sett kunder migrera till Kinsta från andra leverantörer och omedelbart se drastiska förbättringar. Hela vårt företag, från infrastrukturen vi lägger bakom dina webbplatser, till de ingenjörer vi anställer, är prestationsfokuserade. Detta har och kommer aldrig att förändras.
Quite impressed what @googlecloud and @kinsta can pull of for #WordPress hosting! #DevOps #Cloud #WPDev #webdevelopment pic.twitter.com/Cr7UMaHdpH
— Neuralab (@Neuralab) July 22, 2017
Hur Kinsta Snabbar Upp Medlemskapssidor
Kinsta var den första hanterade WordPress-värden som uteslutande använder Google Cloud Platform. Vi erbjuder 19 olika datacenter runt om i världen, vilket innebär att du kan välja en närmast dina besökare för att minska latens och TTFB. Medan andra värdar kan använda Googles standardnivå-nätverk (billigare och långsammare) använder vi Googles premiumnivå-nätverk. Detta är utformat för att minimera avstånd och hopp, vilket resulterar i snabbare och säkrare global transport av dina data.
För att göra din WordPress-webbplats säkrare använder vi även Google Clouds brandvägg på enterprise-nivå. Till skillnad från andra hostar som strikt använder programvarubaserade brandväggar på webbservernivå sitter vår primära brandvägg vid Googles nätverkskant utanför vårt nätverk av virtuella datorer. Detta gör att vi kan blockera känd skadlig trafik innan den kommer in i vårt nätverk och minskar belastningen på våra belastningsutjämnare och virtuella datorer.
Vår värdplattform faller inte i någon av de traditionella värdkategorierna, och skiljer sig mycket från traditionell delad, VPS eller dedikerad infrastruktur. Kinsta använder LXD-hanterade värdar och orkestrerade LXC-programcontainers för varje webbplats. Vad detta innebär är att varje WordPress medlemskapssida är inrymd i sin egen isolerade container, som har alla programresurser som krävs för att köra den (Linux, Nginx, PHP, MySQL). Resurserna är 100% privata och delas inte med någon annan eller ens dina egna webbplatser.
Här på Kinsta gör vi Google Clouds virtuella C2-datorer tillgängliga för alla våra kunder. C2-maskinfamiljen är utrustad med de senaste skalbara Intel Xeon-processorerna som kan arbeta med 3,8 GHz ihållande turbo med alla kärnor. Med högpresterande C2-maskiner som driver ditt WordPress-medlemskap så kommer frekventa icke-cachelagrade begäranden och databasfrågor att kunna köras snabbare, vilket resulterar i en bättre upplevelse för dina besökare.
Varje medlemskapssida kan också dra nytta av vår skalbara infrastruktur för att bättre hantera plötsliga ökningar i trafik och laddning. Detta gör att du kan utveckla din WordPress medlemskapssida utan att behöva oroa dig för de gemensamma begränsningar och hårda gränser som andra webbhotell använder.
Läs mer om hur Kinsta är annorlunda.
2. Dra Nytta av PHP 8.1
Vi kan inte betona nog hur viktigt det är att använda en av de senaste versionerna av PHP, helst PHP 8.1. För många webbplatser kräver detta inte något extra arbete och är en gratis och omedelbar boost till prestandan!
PHP 7.4 stöds inte längre hos Kinsta. Observera att vi stöder PHP-versionerna 8.1, 8.2 och 8.3.
Vi har publicerat våra riktmärkestester för PHP-prestanda där vi testade PHP 7.2, 7.3, 7.4, 8.0 och 8.1. Som du kan se nedan, på en WooCommerce-webbplats, så tog PHP 8.0 hem vinsten för den snabbaste prestandan! 🍰 och 8.1 var ännu snabbare.
Vi testade även Easy Digital Downloads och återigen överträffade så PHP 8.0 allt annat.
Om din nuvarande WordPress-host inte stöder PHP 8.0 eller högre så är det kanske dags att leta efter en ny host. Kinsta erbjuder och stöder PHP-versionerna 8.1, 8.2 och 8.3. Du kan växla mellan dem enkelt i MyKinsta-instrumentpanelen med ett enda klick.
Om din medlemskapssida har kompatibilitetsproblem med den senaste versionen av PHP, då är det förmodligen dags att fråga plugin- eller temautvecklare varför de släpar efter eller anlita din egen WordPress utvecklare för att åtgärda problemet. Du vill inte missa prestandaförbättringar från PHP 7 och högre.
3. Använd Objektscachning
Cachning gör webbplatser snabbare och minskar belastningen på webbservern. Oavsett om du använder ett cachningsplugin eller en hanterad värd som Kinsta som har servernivå (sida)-cachning, är detta något du redan bör göra. Men när det gäller WordPress medlemskapssidor är dina vanliga cachningsinställningar oftast inte tillräckligt eftersom de inte alltid kan utnyttja det till fullo. Det är här objektscachning kommer in i bilden.
Objektcache lagrar resultaten från databasförfrågningar så att nästa gång den specifika biten av data behövs kan den levereras från cache utan att fråga databasen. Detta påskyndar PHP-exekveringstider och minskar belastningen på din databas. Detta blir oerhört viktigt med medlemskapssidor! Med WordPress kan du implementera objektscachning på ett par olika sätt:
- En tredjeparts cachningslösning som W3 Total Cache
- Redis (rekommenderas)
- Memcached
Vi erbjuder Redis som tillägg på Kinsta så att du kan dra full nytta av ihållande objektscachning för dina Medlemssidor. Den goda nyheten är att när den är konfigurerad kan du fortfarande använda alternativet Rensa Cache på din webbplats adminområde i Kinsta MU-pluginet. Denna knapp kommer att rensa både vår sidocache och all objektscachning på webbplatsen.
I vissa fall kan vi också cacha en viss sida eller URL för inloggade användare. Du måste dock först prata med vårt supportteam om detta eftersom det är viktigt att du förstår alla konsekvenser av att aktivera detta.
4. Förbättra Din WordPress Sök
Allteftersom en medlemssida växer, kommer du att upptäcka att WordPress standardsökfunktion inte kommer att räcka till. Webbplatser som använder WP_Query väldigt mycket använder sökningen som den främsta navigationsmetoden, eller även sidor med ett stort antal inlägg, kan få prestandaproblem eftersom alla sökförfrågningar så småningom läggs samman. Det är där en sökmotor som Elasticsearch kan hjälpa till.
Elasticsearch kan användas för att påskynda förfrågan till WordPress databas. Detta görs genom att bygga ett index över innehållet i webbplatsens databas och sedan använda Elasticsearch för att söka detta index mycket snabbare än en MySQL-förfrågan kan utföra samma sökning.
5. Skapa en lättviktig 404-sida
Vi har själva sett att medlemskapssidor vanligtvis genererar en hel del 404-fel. Din webbplats genererar förmodligen fler än du tror! Vårt MyKinsta analytics-verktyg kan hjälpa dig att avgöra det exakta antalet (se nedan).
Du kan också kontrollera 404-fel i Google Search Console eller installera ett tredjepartsplugin som Redirection som loggar 404-fel. Men kom ihåg att plugins som dessa också har en inverkan på prestanda. Det är mycket bättre att lita på ett servernivåverktyg.
Anledningen till att dessa fel är dåliga är att många 404-sidor är mycket resurskrävande. För en medlemskapssida vill du undvika en tung 404-sida. Skapa en enkel 404-mall som undviker att fråga databasen ytterligare om det är möjligt. Och självklart, spendera lite tid och fixa 404-felen eftersom det inte bara är resursintensivt, det är helt enkelt dåligt för användarupplevelsen.
Förutom att använda en lättviktig 404-sida är det även en bra idé att lägga till en speciell sidcacheregel för 404-sidor. Om du är kinsta-kund behöver du inte oroa dig för det här. Vår Nginx-konfiguration cachelagrar 404-sidor i 15 minuter. Om vi upptäcker att en ny sida har skapats som har samma URL som en cachelagrad 404-sida rensar vi cacheminnet efter behov. Om din WordPress-webbplats inte har cachelagrade 404-sidor rekommenderar vi att du arbetar med din host för att lägga till den här funktionen på din webbserver.
6. Öka PHP-arbetare
PHP-arbetare kan vara en term som du aldrig hört talas om, men de är hur många webbhotell, inklusive Kinsta, hanterar begränsning av förfrågningar (snarare än att begränsa dig med CPU eller RAM, vilket vanligtvis är vad delade värdleverantörer gör).
PHP-arbetare bestämmer hur många samtidiga förfrågningar din webbplats kan hantera vid en given tidpunkt. För att uttrycka det enkelt, hanteras varje icke-cachad begäran på din webbplats av en PHP-arbetare. Om du till exempel har 4 förfrågningar som kommer till din webbplats på exakt samma gång och din webbplats har 2 PHP-arbetare, kommer två av dessa förfrågningar att behandlas medan de andra två måste vänta i kön tills de två första har avslutat bearbetningen.
Kom ihåg att vi diskuterade tidigare att ett av de största problemen med WordPress medlemssidor är alla de icke-cachade förfrågningarna. Därför blir PHP-arbetare mycket viktiga eftersom de måste arbeta för varje förfrågan. Därför kommer dessa platser normalt att kräva ytterligare PHP arbetare för att säkerställa att varje begäran behandlas utan förseningar och slutförs framgångsrikt.
Vad händer om du kontinuerligt maxar dina PHP-arbetare? Kön kommer i princip att trycka ut äldre förfrågningar vilket kan leda till 500-fel på din webbplats. Var och en av Kinstas värdplaner innehåller ett fördefinierat antal PHP-arbetare. Om du har problem med att uppskatta vad din webbplats kan behöva kommer den här guiden att vara användbar: PHP-arbetare: Rekommendationer för medlemswebbplatser. Men du kan alltid chatta med vårt försäljnings- eller supportteam också.
7. Utför Regelbundet Databasunderhåll
Regelbundet databasunderhåll rekommenderas inte bara för WordPress medlemssidor, det är ett måste! Om du inte gör det kommer du en dag förmodligen att undra varför din webbplats har börjat släpa sig fram. Här är några rekommendationer:
Rensa upp Autoladdade data
Autoladdade data är data som laddas på varje sida på din WordPress webbplats. Dessa data lagras i din i din wp_options tabell. På stora webbplatser kan denna tabell snabbt växa sig utom kontroll. Kolla in vår djupgående handledning om hur du rensar autoladdade data.
Städa upp transienter och CRON-jobb
Precis som med autoladdad data, bör du också regelbundet städa upp transienter. När du arbetar korrekt är transienter tänkta att löpa ut och ta bort sig själva, men detta är inte alltid fallet. Om något är fel konfigurerat eller till och med korrupt kan dessa börja bli många.
Till exempel hade vi en klient där något gick fel med att transienter inte löpte ut och det gjorde att hela webbplatsen till slut kröp fram. Efter att ha grävt in i det upptäckte vi att webbplatsen hade 695 846 transienta poster (rader) i databasen. Vid radering av raderna (som innehöll transienter som redan borde ha löpt ut) återhämtade sig webbplatsen omedelbart (enligt nedan).
Du kan använda gratispluginet Transients Manager för att visa, söka, Redigera och ta bort transienter på din WordPress-webbplats.Om du är lite mer tekniskt lagd, kan du även använda WP-CLI kommandon för att rensa transienter.
CRON-jobb (WP-Cron), som används för att schemalägga repetitiva uppgifter för din WordPress-webbplats, kan också ha liknande problem. Du kan använda gratispluginet WP Control för att kontrollera och se till att dina CRON-jobb hålls inom rimliga gränser.
Ändra databasmotor till InnoDB
Sist men inte minst bör du flytta din databasmotor till InnoDB om du inte redan har gjort det. Många äldre webbplatser använder fortfarande MyISAM-lagringsmotorn i sin databas. Under de senaste åren har InnoDB visat sig fungera bättre och vara mer tillförlitlig. En stor anledning till att använda InnoDB istället för MyISAM, är att du inte kommer att stöta på problemen med full låsning på tabellnivå. Detta gör att dina förfrågningar bearbetas snabbare.
Kolla in vår handledning om hur du konverterar din databas (tabeller) från MyISAM till InnoDB. Om du migrerar till Kinsta och låter vårt tekniska team hjälpa dig, flyttar vi automatiskt din databasmotor till InnoDB.
8. Avlasta Data
Som vi nämnde tidigare har medlemskapssidor helt enkelt massor av data! Videor, PDF-filer, foton med full upplösning, dokument och ljudfiler tenderar att vara de största syndabockarna. Därför kan du behöva komma på ett sätt att avlasta detta till en billigare lagringslösning. Detta kan spara pengar åt dig genom att helt enkelt uppgradera din värdplan. Kolla in följande artiklar:
- Så här lastar du av media till Google Cloud Storage
- Så här lastar du av stora filer till Amazon S3
- Avlastningslagring av PDF, DOCX, MP4 och MP3s
Vad du inte bör göra för WordPress medlemskapssidor
Här är några saker du inte bör göra på din WordPress medlemskapssida.
Håll Dig Borta Från Inläggsräknare
Lägg aldrig till Visnings/inläggsräknare på din webbplats om du inte behöver det. Undvik till exempel saker som ”792 inlägg” bredvid en användares avatar i foruminlägg eller ”5,243 visningar” när du listar foruminlägg. Under en lång diskussion kommer dessa räknare att väga enormt tungt på din databas. I allmänhet bör du minimera användningen av räknare och endast använda dem om det behövs.
Detta gäller också för sociala räknare. Lägg märke till att vi använder dessa på Kinsta-bloggen, men ingen annanstans på vår webbplats. Men vårt plugin har också cachning inbyggt, vilket säkerställer att de inte genererar förfrågningar på varje sidladdning.
Undvik Sidbyggare
Sidbyggare är bra för många människor, vi har faktiskt även en hel lista över några du kan använda på din webbplats. Men de flesta (inte alla) av dessa har prestandapåverkan eftersom de genererar ytterligare onödig kod för att få sidan att rendera så att användaren fortfarande kan bygga den utan att veta hur man kodar. Om du kan, koda dina sidmallar för hand och gör dem alltid så lätta som möjligt.
Till exempel är vår Kinsta-webbplats (som ses nedan) på WordPress, men hela temat är faktiskt kodat av vår egen utvecklare. Detta hjälper oss att minska lite av den uppblåsning som stora WordPress-teman vanligtvis har men tillåter oss att fortfarande dra nytta av alla fantastiska funktioner. Ta en titt på den här kollektionen om du letar efter marknadens bästa WordPress-medlemskapsteman. Återigen finns det tusentals begåvade WordPress-utvecklare och designers där ute till ditt förfogande om du behöver hjälp.
Använd inte för många Plugins
Vi vet att du har hört det här förut. Sanningen är att kvaliteten på ett plugins kod är viktigare än det totala antalet plugins du har installerat. Men med det sagt kommer var och en fortfarande att ha en ”prestationskostnad.”🐢 Om du inte längre använder funktionerna från olika plugins, inaktivera och ta bort dem från din webbplats. Inte bara gör detta felsökningsåtgärder lättare, men det kommer sannolikt att minska antalet förfrågningar på din webbplats (både backend och frontend).
Var Försiktig Med Tredjepartsintegrationer
Det finns en hel del tredjeparts CRM och automationsplattformar där ute som du kanske vill integrera med din WordPress medlemskapssida. Var dock försiktig med dessa eftersom vissa kan införa ytterligare latens och förseningar när de kommunicerar med sina API:er, tjänster etc. Du kanske vill titta på lösningar som är byggda inuti WordPress, såsom dessa CRM-lösningar.
Inte för att göra det svårare, men motsatsen kan också vara sant. Om en tredjeparts CRM eller automatiseringsplattform hanterar en hel del av sina egna uppgifter, kan det i själva verket bidra till att lasta av din WordPress-värd. Det bästa sättet att veta säkert är att testa olika lösningar.
Ytterligare Rekommendationer
Och självklart kan vi inte låta dig gå utan att nämna några av de vanligaste hastighetsoptimeringarna som du redan borde ha gjort:
- Komprimera dina bilder! På Kinsta ser vi vanligtvis 60-70% besparingar beroende på vilka typer av bilder och vilken form av komprimering du använder. Vi rekommenderar destruktiv
- Använd alltid CDN. Även om vi har 18 datacenter tillgängliga att välja mellan på Kinsta, kommer din server fortfarande att vara långt ifrån någon. Ett CDN kan fixa detta genom att kopiera och leverera dina tillgångar (bilder, JS, CSS) från POPs runt om i världen. Vårt Kinsta CDN ingår för kunder.
- Tänk två gånger innan du bestämmer dig för att hantera din egen VPS. Att försöka att vara en sysadmin för att spara $20/månad är en dålig idé.
Sammanfattning
WordPress medlemskaps- och gemenskapswebbplatser är definitivt i sin egen kategori när det gäller optimering. De kräver vanligtvis lite extra slit om du vill se utmärkt prestanda. Men den goda nyheten är att många av lösningarna där ute kan göra underverk. PHP 8.1, Elasticsearch och Redis Objektscachning är alla enkla och effektiva sätt att se omedelbara resultat. Och naturligtvis bör att ha en prestationsfokuserad värd alltid vara högst upp på din lista. 😉
Driver du en WordPress medlemssida? Vi vill gärna höra dina tankar eller problem du har stött på på vägen.
Brian har stor passion för WordPress och har använt det i över ett årtionde, han har till och med utvecklat ett par premium-plugins. Brian gillar att blogga, kolla filmer och hiking. Ta kontakt med Brian via Twitter.
Lämna ett svar