'N Dieptehandleiding vir effektiewe WordPress-cache
11.05.2020 Category: Optrede
Ek het 'n rukkie gelede 'n artikel oor cache geskryf – Wat is cache van die webwerf en waarom is dit so belangrik ?, wat gekyk het na hoe caching webwerwe bespoedig deur statiese inhoud te dien, waar moontlik. In hierdie volgende artikel oor cache fokus ek op WordPress-besonderhede, en wat u as webwerf-eienaar kan doen om die cache so effektief moontlik te benut.
1.1 Maak die kas skoon
2 Doeltreffende WordPress Caching
2.1 Tydgebaseerde cache
2.2 Aksie-gebaseerde kas
2.3 Handmatige kas skoonmaak
3.3 Gevorderde instellings
3.4 Verstrykingstyd & Vullisversameling
3.5 Aanvaarde lêernaam & URI's wat verwerp is
4 Ander inproppe
5 WordPress Hosting bestuur
In 'n neutedop, elke keer as u werf laai, voer dit baie databasisnavrae uit. Caching slaan 'n statiese weergawe van u bladsy op en stuur dit aan elke gebruiker om die databasis geheel en al na te kyk.
Ek het 'n lang gedeelte geskryf oor die verwikkeldheid van die kasproses, maar ek het besef dat dit nie regtig nodig was nie. Die skep van die cache-weergawe van 'n bladsy is onbeduidend – om te weet wanneer u die kas moet skoonmaak, is die eintlike uitdaging.
Dit verwys na die proses om die statiese kopie van die bladsy uit te vee. As daar geen cache-weergawe is nie, loop al die databasisnavrae soos gewoonlik, en word die resultaat weer gestoor, wat 'n nuwe statiese kopie skep.
Die inhoud van u tuisblad is min of meer konstant; dit verander slegs as u 'n nuwe plasing publiseer. 'N Goeie kasstelsel sal 'n statiese weergawe dien, wat die kas slegs skoonmaak as dit die publikasiegeleentheid bespeur. Dit sal dan voortgaan om die nuwe statiese weergawe te dien totdat u 'n ander pos publiseer.
Doeltreffende WordPress Caching
Caching is effektief as u bladsye op die hoogte hou met die minimum aantal cache-skoonmaakoperasies.
U kan 'n cache-weergawe van u voorblad skep wat elke sekonde verval. Dit sal altyd aktueel wees, maar dit sal die prestasie negatief beïnvloed:
Slegs 99.9999% van die verwydering van die kas is onnodig.
Die kas word elke sekonde herwin, wat sal daartoe lei dat meer databasisnavrae uitgevoer word as wat nodig is.
U kan ook u voorbladgeheue stel om elke week te verval. Die resultaat sou elke week honderd databasisnavrae wees, in plaas van elke sekonde, maar u tuisblad sal selde die nuutste vorm vertoon.
Wat van die keuse van iets tussenin, soos 24 uur? Daar is nog steeds baie min navrae nodig, maar u tuisblad kan tot 24 uur steeds nie met u inhoud sinkroniseer nie.
Vir sommige bladsye wat selde besoek word of nie-tydgevoelig is, kan dit goed gaan, maar die meeste van die tyd is dit belangriker dat u voorblad aktueel bly as om hulpbronne te bespaar.
Vanweë die aard van tydgebaseerde kas skoonmaak, is aksie-gebaseerde metodes in die meeste gevalle beter. WordPress bevat 'n klomp aksies wat uitgevoer word wanneer daar aan sekere voorwaardes voldoen word.
Een so 'n voorbeeld is die na-publikasie-geleentheid. Caching-inproppe kan opspoor wanneer 'n boodskap gepubliseer word, en dan die nodige bladsye uitvee.
Hierdie metode is perfek, omdat bladsye so lank as moontlik staties bly en presies skoongemaak word indien nodig.
Handmatige kas skoonmaak
Dit is ook moontlik om kasse met die hand uit te vee. Dit is nuttig as u u kas moet skoonmaak, maar geen outomatiese gebeurtenis is afgevuur nie.
Gelukkig hoef u nie te veel te bekommer oor die skoonmaak van die kas nie – plugins sal dit alles vir u uitwerk. Kom ons begin deur die WP Super Cache-instellings te gaan met my aanbevelings en aantekeninge.
Sodra die inprop geïnstalleer is, gaan dan oor na Instellings->WP Super Cache->Advanced.
In die eerste groep moet u natuurlik die cache aanskakel. In die tweede groep, kies aanvanklik gebruik mod_rewrite, gaan dan na die oortjie Maklike instellings en gebruik die kas-toetser om te sien of dit werk.
As dit nie so is nie, kan u probeer om mod_rewrite in te skakel (dit sal 'n mate van sysadmin-ervaring nodig hê), of u kan die PHP-cache-instelling gebruik.
As u mod_rewrite wil inskakel, beveel ek aan dat mod_rewrite op nginx inskakel of Hoe mod_rewrite op Apache 2.2 in staat stel.
Ek beveel aan om die eerste twee instellings te merk: Kompressie en nie cache vir bekende gebruikers nie. Miskien wil u u gasheer vra of hulle probleme met kompressie het, en as dit probleme is, of probleme ondervind, maak dit uit.
Ek deaktiveer altyd kasgeheue vir bekende gebruikers (aangemelde gebruikers) omdat dit my toelaat om aan te meld en die ongecacheerde (mees onlangse) weergawe van die webwerf te sien. Dit kan nuttig wees tydens ontwikkeling wanneer veranderinge na die tema gedruk word, maar die kas word nie skoongemaak nie, aangesien geen inhoudveranderings aangebring is nie.
Let daarop dat as u 'n webwerf het wat met baie aangemelde gebruikers werk – soos 'n inskrywinggebaseerde webwerf – u dit dalk wil afskakel. As dit die geval is, raai ek u aan om die instelling 'Maak bekende gebruikers anoniem' te merk. Die enigste uitsondering is as u aangemelde gebruikers inhoud redigeer.
Hou die heropbou-opsie van die kas gekontroleer, aangesien dit die proses om 'n nuwe cache-lêer te genereer, optimaliseer.
Die instelling 'Don cache-bladsye met GET-parameters' hang af van hoe u webwerf gebou is. GET-parameters is addisionele stukkies aan die einde van die URL, en as u dit gebruik om inhoud op 'n bladsy te manipuleer, as uiterste bronne vir die opspoor of iets dergeliks, raai ek u aan om die blokkie te merk.
Vir sommige scenario's, soos utm-parameters, kan u dit verander in ankeretikette. Raadpleeg die kommentaar van Joost se urbronne vir meer inligting.
As u cacheblaaie aan gebruikers van mobiele toestelle wil bedien, moet u die ondersteuningsopsie vir mobiele toestelle nagaan en 'n aanbevole inprop gebruik – of u eie ontwikkelaar. Die aanbevole inproppe is:
Jetpack se mobiele temamodule
'Maak alle kaslêers skoon wanneer 'n plasing of bladsy gepubliseer of opgedateer word' nie word vir die meeste gebruikers nagegaan. As u egter 'n klomp aanbevole verwante items op u webwerf het, en / of veranderinge in 'n enkele pos 'n aantal stelsels op ander bladsye beïnvloed, kan u probeer om op hierdie opsie te klik.
Ekstra tuisbladkontroles moet aangeskakel word. Dit kan onnodige skoonmaak van die kas veroorsaak vir die tuisblad, maar dit is belangriker om daar op die hoogte te bly – die bokoste is gewaarborg.
As u die standaard WordPress-kommentaarstelsel gebruik, moet u die opsie 'Slegs die huidige bladsy herlaai as kommentaar gemaak is' merk. Dit sal verseker dat kommentaar verskyn sodra dit goedgekeur is.
Verstrykingstyd & Vullisversameling
Hierdie afdeling bepaal hoe en wanneer ou kas lêers verwyder word. As 'n nuwe cache-weergawe geskep word, word die ou een nie verwyder nie – die nuwe weergawe word vars genoem, die ou weergawe word verouderd genoem en word gehou.
Ek beveel aan dat u die dokumentasie onder hierdie instellings lees vir 'n paar wenke oor hoe om die waardes in te stel.
Aanvaarde lêernaam & URI's wat verwerp is
Met hierdie afdeling kan u 'n aantal inhoudsoorte uit die geheue uitsluit, en ek raai u aan om die soekbladsy hier te merk om seker te maak dat die resultate altyd vars is.
Met die onderstaande teksboks kan u sommige paaie uit die kas verwyder, wat nuttig kan wees vir addisionele soekbladsye of bladsye wat u ontwikkel..
Sluit-af sal sorg dat kommentaar wel doen nie sneller skoonmaak. Dit sal daartoe lei dat opmerkings effens vertraag word, maar dit kan moontlik wees dat u webwerf tydens 'n styging in die verkeer aanlyn bly.
Daar is 'n klomp ander plugins daar wat soortgelyke funksies bied. Die belangrikste is:
WP Rocket (lees ons resensie
Hul instellings sal effens anders wees, maar die denke agter die opstel daarvan is dieselfde. U moet 'n paar besluite neem oor u webwerf en 'n balans vind tussen altyd vars wees en hoeveel hulpbronne bewaar word.
Caching-plugins vir WordPress is wonderlik, maar dit werk op dieselfde vlak as WordPress, wat hulle ondoeltreffend kan maak in vergelyking met kasstelsels wat op 'n laer vlak werk. Dit is meestal reuse-invoegtoepassings wat alle nuanses dek, wat dit moeilik kan maak om op te stel.
Gasheerondernemings wat WordPress-eksklusiewe hosting aanbied, het dikwels hul eie kasstelsels wat nog minder hulpbronne gebruik en 'n doeltreffender ervaring bied. Die belangrikste voordele sluit in:
U kan geheel en al van caching vergeet.
Geen addisionele inproppe beteken geen opstelling nie.
Dit word dwarsdeur die hele gasheernetwerk toegepas, wat lei tot 'n doeltreffender bediener.
Die grootste voordeel is dat u nie daaroor hoef te bekommer nie – alles is so effektief moontlik buite die kassie opgestel. Caching kan baie tegnies raak, en wanneer u 'n ingewikkelde inprop instel, sal u foute maak.
In vergelyking met 'n perfek gekodeerde tema en 'n perfek opgestelde caching-inprop, sien u dalk nie veel van 'n verskil nie. Die feit dat caching op bedienervlak nie deur PHP hoef te gaan om lêers te skep nie, maak dit vinniger, maar dit is nie iets wat u normaalweg sou oplet nie. Die meeste van die snelheidsverskille is die resultaat van 'n goed geoliede stelsel buite die kassie.
As u 'n webwerf met enorme verkeer en baie bewegende onderdele het, kan die kasstelsel van 'n bestuurde WordPress-gasheer moontlik nie genoeg opsies bied nie, maar dan is dit waarskynlik dat geen plugin sal plaasvind nie, en u sal waarskynlik u eie oplossing implementeer.
Ek sal nie aanbeveel dat u bestuurde WordPress-hosting kies nie, net omdat dit 'n eie cache-stelsel op die bedienervlak het, maar dit is beslis 'n baie lekker toevoeging! As u kies om bestuurde WordPress-hosting te gebruik, kies dan een van die beste, dit wil sê 'n onderneming soos WPEngine, Flywheel (lees ons resensie of Kinsta.
Caching is deesdae 'n moet-hê-funksie vir webwerwe. Dit bespaar hulpbronne, terwyl u gebruikerservaring verbeter.
As webwerf-eienaar moet u 'n WordPress-gasheer van hoë gehalte kies of 'n cache-plugin installeer en opstel – 'n klein belegging vir so 'n ongelooflike funksie.
As u enige ekstra truuks op die kassie het, kan ons dit graag hoor! Deel asb in die kommentaar hieronder!