Share
I forrige innlegg begynte vi å konfigurere forhåndsinnstillinger for Page Cache i W3 Total Cache-plugin og konfigurert innstillingene for General og Cache Preload. I denne artikkelen vil vi dekke opprensingspolitikk og avanserte konfigurasjonsalternativer.
Så la oss dykke inn.
"Purge" innebærer sletting eller fjerning av dokumenter eller poster. I en rensepolitikk konfigurerer vi i utgangspunktet vårt plugin slik at det forteller hvordan og når det skal rense hurtigbufferen som er utdatert. Akkurat som handlinger i WordPress, er det visse punkter i W3TC som man kan ringe utløser, disse utløserne er ansvarlige for å rydde cachen.
Merk at standardinnstillingene for denne delen anbefales.Jeg skal forklare hver enkelt av dem nedenfor.
W3TC holder faner på hendelser som når et innlegg opprettes, redigeres, eller når kommentarer blir lagt ut. Man kan bruke disse utløserne til å rense hurtigbufferen på bestemte sider som vist ovenfor i skjermbildet. Den har en enkel forklaring: Når en side er oppdatert eller et innlegg er opprettet, vil sidens cache for forsiden (for eksempel bloggsiden) der alle innleggene er oppført, og innleggssiden (som er den enkle siden) med feeds som bør renses.
Disse standardinnstillingene er bare fine. Hvis du legger til flere alternativer til denne listen, øker serverens last. Du vil ikke gjøre det med mindre du har en sterk server, minst en VPS, og det er et ytre behov for å rense alt. I stedet kan du rense hele hurtigbufferen manuelt.
WordPress tilbyr en paged struktur for å paginere blogginnleggets listeside og / eller til og med et enkelt innlegg kan pagineres. Denne innstillingen fjerner mengden av disse sidene. For eksempel, i tilfelle av et blogginnleggs liste side, som er fronten [alder i de fleste tilfeller.
Tenk på at du har paginering etter hver fem artikler. Deretter, når du lager et innlegg, vil denne grensen rense den paginasjonen med en gang. Så spesifiser antall sider som viser innlegg (som arkivsiden) som skal ryddes på postoppdateringer.
For eksempel, sider som:
Bygger du en tilpasset struktur med WordPress og lurer på hvordan du skal rense den? Dette området bidrar til å oppnå akkurat det.
Denne innstillingen er ansvarlig for å rense nettstedets nettstedkart. Her kan du definere et regulært uttrykk for alle nettstedkartene. Som nybegynner trenger du ikke å gjøre noe.
Hvis du bruker Yoasts WordPress SEO-plugin eller Google Sitemap-plugin for WordPress, brukes standardverdien til nettstedkartene som er generert av dem. Så la det være som det er.
Lagre innstillingene på dette punktet.
Det er en stor liste over forhåndsinnstillingene for sideoppdatering. Jeg skal liste dem en etter en og forklare dem med de anbefalte innstillingene.
Aktivering av dette alternativet kan øke responsiv tid. Så, jeg vil anbefale deg alle å forlate dette ukontrollert. Det muliggjør støtte for WordPress-funksjonalitet i fragment-caching for sidekachingsmotoren.
Det anbefales å være sjekket i de fleste tilfeller. Hvilken kompatibilitetsmodus gjør at den reduserer ytelsen med ~ 20% i skala i bytte for å øke interoperabiliteten med flere hosting-miljøer og WordPress-idiosyncrasies.
Dette alternativet bør være aktivert for de fleste nettsteder. Disse dager er de fleste hosting stabler basert på flere lokale nettverk kombinert sammen for å danne et hybrid system. For å takle dette hybridsystemet og kulturen i WordPress, slik som hvordan WordPress fungerer, kan man bruke kompatibilitetsmodusen for å forbedre total ytelse.
Dette alternativet bør være ukontrollert i de fleste tilfeller. Det hjelper bare med å løse nettleserproblemer som kan oppstå på grunn av feil merkelig tegnkoding. Så hvis du ikke opplever noen merkelige tegn i sidens cache, er det ikke nødvendig for dette alternativet å være aktivert. Men hvis du opplever noen merkelige tegn i sidens cache, og du er sikker på at de er der på grunn av W3TCs sidebuffer, kan du bare prøve å kryss av aktiver dette alternativet for å løse problemet, hvis det gjør det.
Som oftest HODE forespørsler inneholder tekstinformasjon for bestemte brukerdata og registrering, brukerens nettleser sender forespørsler til webserveren i form av tekst og mottar nettadressen til ønsket tekst.
Hvis du kontrollerer dette alternativet, vil det føre til at deaktivere caching av HODE forespørsler slik at uautorisert bruker ikke kan laste siden på nytt med en hurtigbufring HODE be om.
Men samtidig kan det føre til at "tomme sider" blir returnert for påfølgende forespørsler om en nettadresse. Så jeg anbefaler å beholde denne innstillingen ukontrollert med mindre du vet hva du gjør mens du tillater det.
Hvis du cacher sidene dine på disk, her er hvor du angir hvor ofte utløpte cachedata skal fjernes fra det.
Hvis nettstedet ditt får en anstendig trafikk 3600 som er standardinnstillingen vil fungere fint. Hvis du tror at nettstedet ditt har mye mer trafikk enn gjennomsnittlige nettsteder, kan du avta nummeret for hyppig fjerning av utdatert side cache.
TTL - eller tid til å leve - er en mekanisme som definerer levetiden til data i brukerens nettleser. For eksempel, når det gjelder WordPress-kommentarer, er en informasjonskapsel angitt for å autentisere brukeren som en del av godkjent trafikk. Redusere tiden for å leve for den informasjonskapselen som forblir i brukerens nettleser, kan øke nettstedets ytelse og effektivitet. 1800 er en anbefalt innstilling. Selv om du kan gjøre det lavere enn det eller gå inn -1 å returnere standard TTL som er satt opp av WordPress selv.
I denne seksjonen kan du angi søkeordene du vil kunne cache sine sider. Det vil si at hvis du vil nevne en forespørselsstreng inne i denne tekstboksen, vil W3TC alltid cache nettadresser med den søkte strengen. For nybegynnere anad ikke-programmører bare la dette alternativet være tomt.
Du kan legge til brukeragenter her, som du ikke vil sende hurtigbuffersidene til. For nybegynnere og ikke-programmører, bare la dette alternativet være tomt.
Du kan begrense W3TC fra caching-sider, som bruker spesifikke informasjonskapsler, ved å nevne informasjonskapslene her. For nybegynnere og ikke-programmører bare la dette alternativet være tomt.
Du kan stoppe at enkelte sider blir cached i dette området. Hvis du er utvikler, er det lett å forstå hvordan det fungerer. For nybegynnere og ikke-programmører forlater bare dette alternativet som det er.
Hvis du har problemer med å cache en bestemt side, vil det bli cache det selv om det er oppført i feltet "aldri cache de følgende sidene". Den støtter også vanlig uttrykk.
Hvis en side i WordPress er en ikke slående side, kan dette området brukes til å cache det. Som Sitemaps. La det stå som standard.
Hvis du vil spesifisere flere sideoverskrifter til cache, kan du gjøre det her. For nybegynnere og ikke-programmører forlater bare dette alternativet som det er.
Lagre innstillingene nå.
Dette avslutter våre Advanced Page Cache-innstillinger for W3TC. Hvis du har noen spørsmål, ikke nøl med å spørre nedenfor.
Accentsconagua