För några dagar sedan startade vi en serie tutorials om W3TC (W3 Total Cache), vilket är ett plugin som låter dig cacha din blogg så att den går mycket snabbare.
Denna handledningsserie ser ut så här:
- Del 1: Introduktion till Cache
- Del 2: Konfigurera W3TC
- Allmänna inställningar - Avsnitt 1
- Fler allmänna inställningar - Avsnitt 2
- Konfigurera sidcache - avsnitt 3 (denna handledning)
- Konfigurationsminifikationer - Avsnitt 4
- Databascache-konfiguration - avsnitt av 5
- Objekt- och webbläsarkonfiguration - Avsnitt 6
- Del 3: Alla svar på dina frågor
- Del 4: W3TC "Mainspan" -parametrar
I förra avsnittet var vi fortfarande i del 2, men började med de allmänna inställningarna. Idag fortsätter vi med inställningarna för caching sidor.
när caching sidor aktiveras från den allmänna inställningsmenyn, använd " sidcache För att komma åt cache-konfigurationen för detta element.
När du väljer sidor att cache ska du vara så inkluderande som möjligt. I de flesta fall vill du cache nästan alla sidor.
Om din webbplats finns med https då du kommer att vilja aktivera SSL Cache (https) För dessa tillämpningar.
De flesta webbplatser kommer inte att dra nytta av caching baserat på URI:erna. Att aktivera det här alternativet kan ge oväntade resultat genom att cachelagra oväntade strängar. Så om inte din sökfunktion används allmänt för att söka med samma termer, lämna det här alternativet inaktiverat.
Slutligen är det tillrådligt att inte cache 404-sidan. Besökare ska i alla fall inte se dem ofta, och du vill inte att Google ska indexera en 404-sida som en vanlig sida, vilket kan hända om du aktiverar det här alternativet.
Nästa alternativ, "Cache begär endast för (din domän) webbadressen ”(endast cache förfrågningar) är inte avmarkerat som standard, men den universella rekommendationen är att kontrollera det här alternativet.
De nästa två alternativen ser ganska lika ut, men förklaringen nedan för varje alternativ rensar upp det.
« Cache-sidor för inloggade användare ska inte alltid vara kontrollerade Måste alltid vara kontrollerad. Om du lämnar den markerad och visar din webbplats när du är ansluten cache- rar din åtgärd sidan och visar den för användare som inte är inloggade.
« Dölj inte sidor för följande användarroller Betyder att användare som matchar den valda rollen kommer att få åtkomst till den direkta (inte cachelagrade) versionen av din webbplats.
Nästa avsnitt, " cache Preload Används för att bygga sidcachen innan den laddas.
Det är en bra idé att välja alternativet att förladda sidcachen. Standardvärdena för sidintervall och sidintervall är bra inställningar för delade servrar. Men om du har en miljö avlogi mer kraftfull minska gärna siduppdateringar och cachningsintervall.
Du måste lägga till webbadressen till webbplatskartan i lämpligt sortfält som W3TC använder för att använda den för att identifiera sidor som behöver cache.
Slutligen vill du i de flesta fall välja " Förladda Cache post på publicera händelser ". Detta säkerställer att den cachade versionen av din sida uppdateras varje gång du publicerar en ny artikel.
Rengöringsavsnittet används för att specificera sidor till " tom Från cache, när en artikel publiceras, redigeras eller kommenteras.
Du kommer antagligen att lämna cache-rengöringsalternativen, såvida du inte vet att du inte vill att en av sidorna ska rensas vid de tidigare nämnda händelserna.
Rensningsgränsen bestämmer antalet arkiverade sidor som måste rensas. Till exempel, om ditt artikelarkiv har 20-sidor, och du ställer in reningsgränsen till 15, kommer de sista 15-sidorna att rensas, medan de äldsta fem sidorna inte rensas förrän att utgångsdatumet för dessa sidor kommer.
Att ställa in värdet till 0 för att rensa alla sidor är en bra idé om inte några av dina arkiv är väldigt stora. I det här fallet måste du använda ett värde på 10, vilket kan vara lämpligt för den här situationen.
Om du har byggt egna sidor som måste rensas varje gång meddelandena redigeras och publiceras måste du lägga till dem manuellt i fältet för ytterligare sidor (tillgängliga alternativet lite lägre).
Det avancerade avsnittet hjälper dig att:
- Kontrollerar hur W3TC hanterar specifika förfrågningssträngar,
- Utesluta vissa medel (enheter, webbläsare) som inte kommer att få den cachade versionen,
- Identifiera cookies som gör att W3TC inte kan cache-sidor
- Ställ in ytterligare specifika undantag.
Ta en minut att titta på inställningarna i början av avsnittet "Avancerat".
« sen initiering Den här avancerade funktionen låter dig implementera sidcache i ett fragmenterat sätt. Du kan ignorera det här alternativet i de flesta fall.
« Kompatibilitetsläge »: Författaren till pluginet rekommenderar att du aktiverar kompatibilitetsläget för att minimera uppkomsten av fel.
« teckenuppsättning Om du märker att udda tecken visas i cachelagrade sidor aktiverar du det här alternativet.
« Avvisa HEAD förfrågningar ": Lämna det här alternativet inaktiverat. Informationen i en HTTP HEAD-begäran är ibland nödvändig för att skapa den resulterande sidan. Om du inaktiverar det här alternativet kommer data från HEAD-begäran inte att cachas och kan bryta sidor som är byggda med denna information.
« Sophämtning intervall »: Ange hur ofta utgången cachad data raderas. Att ta bort cachad data tar medel på servern, bör det inte göras för ofta om din webbplats är upptagen eller om din server är överbelastad. Standardinställningen är lämplig för nästan alla servrar.
« Hur kakan livstid Att minska detta värde kommer att minska belastningen på servern eftersom de cookies som används för att verifiera intressenter löper ut snabbare. Om du ställer in ett värde för kort kommer användarna att logga in hela tiden.
Resten av fälten i det här avsnittet bör inte ändras såvida du inte vet att du vill åsidosätta W3TC-beteendet för en specifik cookie, en " user agent Eller en sida.
Det är det för den här sviten. Vi fortsätter i nästa avsnitt.
