Il motivo principale per cui un sito web è “lento” di solito non è dovuto a una singola immagine, ma a qualcos'altro.Il collegamento della richiesta + la generazione del server + la distribuzione delle risorse statiche.Quello causato dall'effetto sovrapposizione:

  • L'utente è troppo lontano dal tuo server e l'RTT di rete è alto (più evidente tra continenti diversi).
  • Ogni volta che si fa una richiesta a WordPress, questo esegue il PHP, consulta il database e rende il template → Il TTFB (tempo del primo byte) è aumentato.
  • La pagina deve anche caricare JS/CSS/font/script di terze parti, il che rallenta il rendering e l'interazione.

Plugin di cacheIl punto fondamentale della soluzione consiste nel salvare i risultati della pagina che vengono “calcolati ripetutamente”, in modo che il server non debba ricalcolarli ogni volta; inoltre, con una strategia appropriata, consentire a un numero maggiore di utenti di accedere alla cache, riducendo significativamente il TTFB.La documentazione ufficiale di WordPress.È stato inoltre osservato che i plug-in come W3 Total Cache e WP Super Cache possono memorizzare le pagine nella cache come file statici, fornendoli direttamente agli utenti e alleggerendo il carico di elaborazione del server.

Prima di leggere questa pagina, ricorda tre regole fondamentali.

1. Il plug-in di caching delle pagine utilizza solo uno alla volta.

Nello stesso tempo, l'attivazione di più plug-in di cache, il risultato più comune non è una maggiore velocità, ma:

  • Regole di cache che si sovrappongono a vicenda, pulizia reciproca della cache e diminuzione del tasso di hit della cache.
  • I contenuti dinamici come la sessione di accesso, la lingua, il carrello e i prezzi vengono memorizzati nella cache, causando incidenti dovuti a “contenuti errati”.
    Molti documenti/istruzioni dei plug-in consigliano di utilizzare un determinato plug-in di caching quando si utilizza un altro plug-in di caching.Disabilita altri plug-in di cache.Per evitare conflitti.

2. E-commerce/membri/sito multilingue: la cache non è un “interruttore”, ma un “sistema di regole”.”

Il documento ufficiale sulle prestazioni di WooCommerce.Avviso importante: assicurati che nell'插件 di caching sia tutto a posto. Carrello / Checkout / Account È consigliabile che alcune pagine non vengano memorizzate nella cache ed è inoltre consigliabile evitare di comprimere i file JavaScript (poiché ciò potrebbe causare problemi di compatibilità).

3. “I plug-in di cache ≠ CDN”, ma i plug-in di cache sono la base del CDN.

I plug-in di caching risolvono il problema della “sottostima da parte del server di origine”;CDN Rendere i contenuti più accessibili agli utenti. I due aspetti sono interdipendenti: prima è necessario ridurre il TTFB del server di origine, quindi trasferire le risorse statiche al CDN per la diffusione. Questa è la soluzione più affidabile per raggiungere gli utenti di tutto il mondo.

Selezione rapida: i 4 scenari più comuni del sito web.

Se non vuoi leggere l'intero testo, segui le 4 raccomandazioni seguenti e difficilmente sbaglierai:

  1. Vuoi avere tranquillità, stabilità e accesso globale? → WP Rocket(A pagamento)
  2. Il server è chiaramente LiteSpeed/OpenLiteSpeed. → Cache LiteSpeed(È gratuito, ma dipende fortemente dalle capacità del server)Il funzionamento della cache richiede Il componente server di LiteSpeed.Per poter lavorare.
  3. Per i siti di contenuti/blog/documentazione, si desidera una soluzione gratuita e affidabile. → WP Super Cache(Caching HTML statico)Generare file HTML statici da fornire alla maggior parte degli utenti non registrati.
  4. Hai un team tecnico e vuoi un controllo preciso (CDN/caching degli oggetti/moduli multipli). → W3 Total Cache(Forte ma complesso): Punto di forza è un framework di prestazioni completo e l'integrazione con la CDN.

Ma cosa c'è esattamente nella cache?

“Perché alcuni siti sono lenti anche con la cache attivata?”. Abbiamo suddiviso le prestazioni di WordPress in 5 livelli:

  1. La cache del browser.Permettere agli utenti di accedere più rapidamente per la seconda volta (intestazione di cache delle risorse statiche, numero di versione).
  2. La cache delle pagine.: Cache i risultati dell'output della pagina come HTML (il protagonista di questa pagina)
  3. La cache degli oggetti.: Oggetti che memorizzano i risultati delle query del database (più utili per i siti web dinamici)
  4. OPcache di PHP: Cache del codice byte PHP (generalmente configurata dal server, non è un elemento fondamentale del plug-in)
  5. CDN/cache di periferia: Mettere le risorse su nodi più vicini agli utenti.

Questo articolo si concentra su: il plug-in di caching delle pagine;
Tuttavia, ti verrà continuamente ricordato che i siti web spesso necessitano di una combinazione di 2+5 per essere “veramente veloci”.

Plug-in 1:WP Rocket(A pagamento) — Una soluzione integrata “senza preoccupazioni”.

WP Rocket è popolare nell'ambiente WordPress non perché sia un prodotto miracoloso, ma perché trasforma i tre tipi di ottimizzazioni delle prestazioni più comuni in “pacchetti gestibili”.

  • La cache delle pagine (che riduce il TTFB della stazione di origine)
  • Prefetching/preheating della cache (per migliorare l'esperienza della prima visita nell'ambito di un accesso distribuito a livello globale)
  • Ottimizzazioni chiave del front-end (in particolare ritardo JavaScript, elaborazione CSS, ecc.)
Ottimizzazione della cache di WordPress - LikaCloud

Il suoDocumentazione ufficialeÈ anche chiaramente indicato che, anche se si disattiva la cache delle pagine, l'attivazione del precaricamento può comunque innescare/attivare alcuni processi di ottimizzazione (come l'ottimizzazione relativa a CSS/JS).

1.1 WP Rocket è adatto a chi?

WP Rocket è particolarmente adatto per questi siti:

  • Il sito web aziendale, il sito del marchio, il sito di marketing dei contenuti e la pagina di destinazione (con traffico proveniente da diversi Paesi e regioni)
  • Spero di poter lanciare il sito rapidamente e con stabilità come priorità, e non voglio dover affrontare la fatica di combinare molti plug-in gratuiti.
  • Non ci sono operatori di manutenzione/ingegneri delle prestazioni a tempo pieno, ma ci sono requisiti in termini di esperienza utente e SEO.
  • WooCommerce Si può usare, ma con maggiore cautela (ne parleremo più avanti in questa sezione).Regole e rischi）

1.2 Il suo valore fondamentale negli scenari di accesso ai siti web (non solo come “interruttore della cache”)

A. Precaricamento della cache: risolve l'instabilità della prima visita causata dall'accesso distribuito al sito web.“

Quando gli utenti del sito web sono dispersi, si verifica un tipico rallentamento delle prestazioni.
Quando un utente di una determinata area apre una pagina per la prima volta e questa risulta essere stata memorizzata nella cache o non è mai stata pre-caricata, l'utente deve sostenere l'intero costo di rendering di PHP/DB.
Il meccanismo di precaricamento.Il significato è:Pagare in anticipo i costi della “prima generazione”.Reduciamo la probabilità che i nuovi utenti si trovino in una situazione in cui devono affrontare da soli tutti i problemi quando visitano un sito web per la prima volta.

  • Nessun precaricamento: chi accede per primo, soffre per primo.
  • C'è il precaricamento: la cache viene generata in modo uniforme dal sistema in background, garantendo un'esperienza più stabile durante la prima visita.

B. Ritardare l'esecuzione di JavaScript: la funzionalità più immediatamente percepibile durante la visita a un sito web, ma anche quella più rischiosa.

Il team ufficiale di WP Rocket ha dichiarato che:“Ritardare l'esecuzione di JS.”È descritto come l'ottimizzazione JS più potente: ritarda l'esecuzione degli script fino a quando l'utente non interagisce (spostando il mouse, toccando lo schermo, scorrendo, premendo un tasto, ecc.), in modo da dare priorità al rendering della pagina.

Questo è molto importante per le visite ai siti web, poiché con le reti transcontinentali, il blocco del caricamento e dell'esecuzione degli script può facilmente amplificarsi:

  • Il download delle risorse è un po' lento → Il thread principale rischia di essere rallentato dagli script.
  • Gli script di terze parti (statistici, pubblicitari, plug-in di chat) rendono più probabile un peggioramento dell'INP/del ritardo nelle interazioni.

Ma potrebbe anche causare alcuni problemi:

  • Il ritardo di JS potrebbe probabilmente influire su: menu, caroselli, finestre pop-up, convalida dei moduli, pagamenti, tracciamento dei punti di interazione.
  • Pertanto, è adatto alla strategia “passo dopo passo + esclusione dalla lista nera”.

C. Compatibilità con altri plug-in/temi: la facilità d'uso non equivale a “zero conflitti”.”

WP Rocket ufficiale ha elencato appositamente “Plugin/temi incompatibili.”La lista delle ragioni include il fatto che potrebbe influenzare i meccanismi di output buffering della cache/ottimizzazione di WP Rocket.

  • Se il tuo sito web ha molti plug-in e temi pesanti, considera l'ottimizzazione delle prestazioni come un piccolo progetto di lancio: esegui test di regressione per ogni modifica (moduli, login, pagamenti, commutazione multilingue, ecc.)

1.3 Avviso speciale per WooCommerce/siti web dinamici

Il consiglio fondamentale della documentazione ufficiale di WooCommerce per la configurazione dei plug-in di caching è il seguente:

Perché? :

  • Il carrello, il checkout e la pagina dell'account dipendono fortemente dai cookie/sessioni/nonce.
  • Una volta che la cache considera queste pagine come “pagine statiche”, nel migliore dei casi i pulsanti non funzionano, nel peggiore dei casi i prezzi/le scorte/le informazioni dell'account risultano errate.
  • Il più spaventoso è che potresti non avere problemi con i test in una regione, ma riscontrare problemi in un'altra a causa di differenze nell'hit dei CDN/cache.

1.4 Suggerimenti a livello di strategia per i plug-in di caching

1° livello: rendimento di sicurezza di base (che dovrebbe essere implementato da quasi tutti i siti web).

  • Attivare la cache delle pagine.
  • AccendiPrefetch della cache(Aumentare la stabilità della prima visita)
  • Una strategia di caching del browser ragionevole (che può essere implementata a qualsiasi livello: WP Rocket, server o CDN)

2° livello: reddito medio, rischio medio (adatto alla maggior parte dei siti di contenuti)

  • Caricamento differito di immagini/iframe (approfondimento sull'ottimizzazione delle immagini)
  • Controllare il volume dei CSS (ad esempio, rimuovendo i CSS non utilizzati)

3° livello: alto rendimento ma alto rischio (è necessaria una lista di test di regressione)

1.5 Prezzo e autorizzazione

  • WP Rocket è un sistema di licenza a pagamento, che offre diverse autorizzazioni in base al numero di siti web.

Plugin 2:LiteSpeed Cache (LSCWP)—— Il presupposto di “top di gamma gratuito” è che il server sia effettivamente LiteSpeed.

Ottimizzazione della cache di WordPress - LikaCloud

Molte persone fraintendono LiteSpeed Cache, pensando che sia solo un plug-in di WordPress, che, una volta installato, funzionerà alla perfezione su qualsiasi host, proprio come WP Rocket. In realtà, non è così.

Documentazione ufficiale di LiteSpeed.Spiegazione chiara: la funzionalità di caching di LSCWP richiede il server LiteSpeed poiché deve comunicare con la cache delle pagine integrata di LiteSpeed Web Server (LSCache); il plug-in è responsabile di indicare al server quali pagine possono essere cachette, per quanto tempo e di attivare la pulizia mediante tag.

I vantaggi principali di LiteSpeed Cache derivano da “La cache delle pagine a livello di server (LSCache)”Il vantaggio principale non sarebbe possibile senza i server LiteSpeed/OpenLiteSpeed.

2.1 Cache LiteSpeedA chi è adatto?

Adatto per:

  • Il tuo pannello di hosting è chiaramente etichettato. LiteSpeed / OpenLiteSpeed(Per esempio, molti host cPanel scriveranno)
  • Desideri che “anche le soluzioni gratuite siano in grado di offrire un TTFB e una capacità di concorrenza molto forti”.”
  • Saresti disposto ad accettare: è molto funzionale, ma ha anche più concetti (TTL, Tag, Purge, ESI, Crawler…)

Non è molto adatto:

  • Non sei sicuro di quale server web utilizzare o se è Nginx/Apache (a meno che tu non voglia utilizzare solo alcune delle sue funzionalità di ottimizzazione front-end, ma in tal caso il rapporto costo-beneficio e la complessità potrebbero non essere vantaggiosi).
  • Sei un sito e-commerce/membro/multilingue complesso, ma non hai un processo di test (LSCWP è potente, ma è anche più facile “accidentalmente memorizzare nella cache i contenuti sbagliati”).

2.2 Il suo meccanismo di cache: perché è più simile a “una parte delle capacità del server”.”

Puoi descrivere il meccanismo di LiteSpeed Cache in un'unica frase: “Spiegazione ingegneristica”.

  • WP Rocket / WP Super Cache Questo tipo di ottimizzazione riguarda principalmente la memorizzazione nella cache e l'ottimizzazione sul lato WordPress/PHP;
  • LSCWP Quindi è una combinazione di “Pannello di controllo WordPress + LiteSpeed Server con LSCache integrato”: il plug-in è responsabile per l'invio delle regole e dei segnali di pulizia, mentre la cache delle pagine ad alta velocità avviene effettivamente all'interno.Il livello del server.。

Questo influenzerà direttamente l'esperienza di accesso al sito web: il caching a livello di server è generalmente più leggero, più veloce e più resistente alla concorrenza (soprattutto in caso di picchi di traffico e di accessi frequenti da parte dei crawler dei motori di ricerca).

2.3 Nello scenario degli utenti del sito web, il “modo corretto di aprire” LSCWP.”

Abbiamo suddiviso il “modo corretto di aprire” in 4 livelli:

1° livello: strategia di caching delle pagine (che determina se il TTFB può effettivamente ridursi)

  • Determinare quali pagine possono essere memorizzate nella cache (la maggior parte delle pagine di contenuti pubblici)
  • Identificare quali pagine non devono assolutamente essere memorizzate nella cache (accesso, account, carrello, checkout, pagine che richiedono cookie forti per la selezione della lingua/della valuta).
  • Impostare un TTL ragionevole per la cache (quanto più alta è la frequenza di aggiornamento del contenuto, tanto più breve sarà il TTL; al contrario, tanto più lungo sarà).
  • Stabilire una strategia di pulizia: dopo l'aggiornamento dei contenuti, pulire i tag correlati (invece di una pulizia brutale di tutto il sito).

Se questo livello viene eseguito correttamente, ciò che il sito web vedrà più direttamente sarà: \n Il TTFB è diminuito e la prima schermata è più stabile.。

Secondo livello: preriscaldamento/crawler (determina se la prima visita a una pagina “meno popolare” è lenta o no).

Il “disallineamento dell'esperienza” che si verifica spesso durante la visita a un sito web deriva dalle “differenze di performance” della cache:

  • La pagina popolare viene visitata continuamente e la cache rimane sempre attiva.
  • Le pagine poco popolari non vengono cliccate da molto tempo e la prima persona che le clicca lo fa molto lentamente.

Il pre-riscaldamento non è un optional, ma è la chiave per garantire un'esperienza di navigazione coerente sul sito web.

3° livello: soluzioni di sicurezza per contenuti dinamici (e-commerce/membri/multilingue)

La forza di LSCWP sta nel fatto che ti offre molti “strumenti avanzati”, come ad esempio:

  • Una strategia di caching differenziata per gli utenti che effettuano il login, gli utenti che lasciano commenti, ecc.
  • L'idea alla base dell'Edge Side Includes (ESI) è la seguente: dividere la pagina in "entità pubbliche memorizzabili nella cache" e "frammenti dinamici non memorizzabili nella cache", elaborarli separatamente e quindi unirli nei nodi periferici.

4° livello: servizi online e funzionalità aggiuntive opzionali

Molti webmaster entreranno in contatto con i servizi online di QUIC.cloud all'interno di LSCWP (come i servizi di ottimizzazione delle pagine).Documentazione di QUIC.cloudÈ specificato chiaramente che fornisce servizi di ottimizzazione delle pagine a LSCWP, che includono Critical CSS (CCSS), Unique CSS (UCSS), Viewport Images (VPI) e così via.

  • Tali servizi sono opzionali.Puoi usare solo la cache del server e non attivare l'ottimizzazione online.
  • Una volta attivato il servizio online, i collegamenti di elaborazione delle risorse/pagine del tuo sito cambieranno (questo è un'informazione importante per i clienti sensibili alle questioni aziendali/alla privacy).

2.4 Le insidie più comuni di LSCWP

  1. Il server non è LiteSpeed, ma ha comunque utilizzato LSCWP come plug-in di cache completamente funzionale.
    Risultato: l'effetto della cache non è stato come previsto e ha anche aumentato la complessità della configurazione. Soluzione: prima, verificare lo stack dell'host; se non lo è, LiteSpeedConsidera WP Rocket o WP Super Cache.
  2. L'attivazione di troppe ottimizzazioni front-end ha causato un malfunzionamento della funzionalità.
    L'ottimizzazione della pagina (CSS/JS) tende a causare problemi di compatibilità più facilmente rispetto alla “cache stessa”. Consiglio: prima assicurati che la cache della pagina funzioni correttamente, quindi attiva gradualmente le ottimizzazioni e crea un elenco di test di regressione (moduli, menu, pagamenti, tracciamento, cambio della lingua, ecc.).
  3. Mancanza di una strategia di esclusione/frammentazione per le pagine dinamiche.
    Incidenti tipici: carrello, checkout e pagina dell'account memorizzati nella cache; o passaggio non corretto tra lingue/valute. I siti di e-commerce devono considerare questo come un punto di controllo prima della pubblicazione (anche WooCommerce lo sottolinea ufficialmente).Le pagine chiave non devono essere memorizzate nella cache.）。

Plug-in 3:WP Super Cache(Gratuito) — Il classico schema “basso rischio, alto rendimento” dei siti di contenuti.

Ottimizzazione della cache di WordPress - LikaCloud

WP Super Cache Perché è riuscito a diffondersi così a lungo? Perché risolve i problemi in un modo molto diretto e “friendly per i server”:
Converte le pagine dinamiche di WordPress in file HTML statici.In seguito, questi file HTML vengono forniti direttamente dal server web, evitando così l'onerosa elaborazione PHP.

La pagina dei plug-in menziona inoltre che l'HTML statico verrà fornito alla maggior parte degli utenti non registrati e fornisce una spiegazione molto intuitiva: “Ai visitatori di 99% verrà fornito un file HTML statico”, un file di cache che può essere servito migliaia di volte.

3.1 WP Super Cache è adatto a chi?

Consigliatissimo:

  • Blog, siti di contenuti multimediali, siti di documentazione, siti di presentazione aziendale, pagine di destinazione.
  • I visitatori sono principalmente utenti non registrati.
  • Tu desideri: gratuitità, stabilità e bassi costi di manutenzione.

Usare con cautela/è necessaria una strategia più efficace:

  • Sito web dinamico: molti contenuti personalizzati, pagine che cambiano in base allo stato dell'utente.
  • Grandi e-commerce: è possibile utilizzarli, ma è necessario assicurarsi che le pagine chiave non vengano memorizzate nella cache e che siano compatibili con il tuo processo di test.

3.2 I suoi tre metodi di caching:

Nella descrizione del plug-in WP Super Cache, i metodi di caching sono elencati in ordine di velocità e vengono spiegate le differenze tra di loro:

  • Mod_rewrite (per esperti)Il modo più veloce è saltare completamente PHP, ma è necessario modificare il file .htaccess. Una configurazione errata potrebbe comportare un rischio maggiore di inaccessibilità del sito.
  • Semplice (metodo consigliato): I file statici del “super cache” forniti da PHP sono quasi altrettanto veloci di mod_rewrite, ma sono più facili da configurare.
  • La cache di WP.È più flessibile e viene utilizzato per utenti noti, URL con parametri, feed RSS, ecc., ma è più lento.

Selezione consigliata:

  • Per i principianti/che cercano stabilità: usare il metodo consigliato (semplice)
  • Sei molto familiare con le regole del server e sei disposto ad assumerti il rischio di riscriverle: prendi in considerazione la modalità esperto.
  • Hai bisogno di un'elaborazione più flessibile di “utenti noti/con parametri”: comprendi il posizionamento di WP-Cache.

3.3 I vantaggi e gli svantaggi di WP Super Cache.

Vantaggi:

  1. È molto adatto per essere utilizzato con i CDN.
    Poiché la sua natura è quella di “generare HTML statico”, questo è perfettamente in linea con il concetto di CDN/caching di bordo.
  2. Il miglioramento della pressione sul CPU/database della stazione di origine è molto diretto.
    Quando il traffico del sito web è distribuito, i crawler dei motori di ricerca e dei social media potrebbero provenire da tutto il mondo. La staticizzazione è efficace nel contrastare il problema del “rendering ripetuto”.

Punti deboli:

  1. Non è un “pacchetto di ottimizzazione delle prestazioni integrato”.”
    Il suo punto di forza principale è la cache delle pagine, ma non offre un'ottimizzazione approfondita di CSS/JS come WP Rocket. Potrebbe essere necessario aggiungere ulteriori contenuti alle pagine “Ottimizzazione delle immagini” e “Ottimizzazione del front-end” (o utilizzare altri plug-in/temi per ottimizzare tali aspetti).
  2. Bisogna essere più cauti riguardo alla “personalizzazione dinamica”.
    Ad esempio, mostrare contenuti diversi in base alla regione o prezzi, lingue o raccomandazioni diverse in base allo stato dell'utente. In questo caso, è necessario stabilire una strategia di esclusione o introdurre una soluzione di caching a frammenti più adatta.

3.4 Compatibilità con WooCommerce: perché è più “sicuro”

Il documento di aiuto ufficiale di WooCommerce.Da notare: WooCommerce è compatibile nativamente con WP Super Cache e WooCommerce invia informazioni a WP Super Cache in modo che, per impostazione predefinita, non memorizzi nella cache le pagine Carrello, Checkout e Il mio account.

  • Anche se sei un principiante, la combinazione di WP Super Cache e WooCommerce rende meno probabile che tu incorra nel problema delle “pagine chiave che vengono memorizzate nella cache”.
  • Tuttavia, si consiglia comunque di eseguire test di regressione prima del lancio (pagamenti, coupon, spese di spedizione, aliquote fiscali, più valute, ecc.)

Plug-in 4:W3 Total Cache (W3TC)——Il “framework di performance” più completo, adatto ai team di ingegneria.

Ottimizzazione della cache di WordPress - LikaCloud

W3 Total Cache Il posizionamento di WordPress.org non è quello di essere un “singolo plug-in di caching”, ma qualcosa di più simile a un “framework di ottimizzazione delle prestazioni del sito web”: pone l'accento sul miglioramento della SEO, dei Core Web Vitals e dell'esperienza complessiva attraverso l'integrazione con la CDN e l'adozione delle migliori pratiche.

Le funzionalità elencate nella descrizione del plug-in sono molto ampie: memorizzazione nella cache di pagine/post, memorizzazione nella cache di CSS/JS, memorizzazione nella cache di feed, memorizzazione nella cache dei risultati di ricerca, memorizzazione nella cache di oggetti di database, memorizzazione nella cache di oggetti, memorizzazione nella cache di frammenti (fragment cache) e supporto di vari metodi di memorizzazione nella cache come Redis/Memcached/APC, oltre a funzionalità come la memorizzazione nella cache per dispositivi mobili raggruppata per UA/Referrer, il supporto AMP e l'integrazione con i proxy inversi (Nginx/Varnish).

4.1 W3 Total Cache è adatto a chi?

Molto adatto per:

  • Hai capacità di sviluppo/gestione operativa e sei disposto a eseguire “attivazione graduale + test di stress + test di regressione”.”
  • Il tuo sito è complesso: multilingue, con la possibilità di cambiare l'argomento, differenziazioni per dispositivi mobili e una struttura dei contenuti complessa.
  • Non solo devi memorizzare nella cache la pagina, ma vuoi anche includere nella cache gli oggetti/i frammenti (soprattutto nei siti web dinamici).

Non adatto per:

  • Desideri che “l'installazione sia rapida e diretta” e non vuoi dover capire come funziona la gerarchia della cache.
  • Non hai un processo di test, ma vuoi comunque attivare in un colpo solo elementi ad alto rischio come la compressione e lo script di ritardo.

4.2 Perché lo si definisce “potente ma complesso”: i siti web danno priorità alla “controllabilità”.”

Il valore di W3TC non sta nel “fatto che sia necessariamente più veloce degli altri”, ma nel fornire un numero sufficiente di controlli che consentano di trasformare le strategie di ottimizzazione delle prestazioni in un sistema ingegnerizzato.

  • Cache della pagina: può essere presente nella memoria, sul disco o nella CDN.
  • Cache degli oggetti del database, cache degli oggetti: è possibile utilizzare Redis/Memcached, ecc.
  • Caching dei frammenti: è molto importante per le “pagine semi-dinamiche”.
  • Supporto mobile: memorizzare nella cache le pagine in base al referrer o al gruppo di agenti utente.
  • Gestione CDN: gestione trasparente del CDN di librerie multimediali, file di temi e così via.

Queste capacità sono particolarmente preziose per i siti web, in quanto gli accessi da tutto il mondo sono un fenomeno frequente.

  • Le varianti della stessa pagina su diversi dispositivi, in diverse regioni e in diverse lingue.
  • Alcuni contenuti possono essere memorizzati nella cache, mentre altri devono essere in tempo reale (ad esempio, prezzi, inventario, stato dell'utente).

4.3 “Ordine di attivazione consigliato” di W3TC.”

L'ordine di raccomandazione è il seguente:

  1. Per ora, attiva solo la cache delle pagine.
    Verifica: se il TTFB è diminuito, se il contenuto è coerente e se i processi chiave di login/multilingua/e-commerce funzionano correttamente.
  2. Attivare nuovamente la cache del browser.
    Obiettivo: consentire un caricamento più rapido delle pagine visitate di nuovo e delle risorse statiche, riducendo i download ripetuti tra continenti.
  3. Rivalutare la cache degli oggetti / la cache degli oggetti del database.
    Applicabile a: siti web dinamici (WooCommerce, sistemi di gestione utenti, query complesse).
    Non applicabile: i siti web che offrono solo contenuti potrebbero avere profitti limitati e persino aumentare il consumo di risorse.
  4. Infine, occupiamoci della compressione, dei script di ritardo e dell'ottimizzazione front-end.
    Poiché questo è il livello più soggetto a malfunzionamenti, è necessario stabilire un elenco di test di regressione (pagamenti, moduli, tracciamento, finestre pop-up, menu, cambio di lingua, ecc.).

Un promemoria di WooCommerce relativo alla “configurazione dei plug-in di cache”.Le pagine chiave non vengono memorizzate nella cache e si consiglia di evitare la compressione dei file JS.

Una matrice di confronto tra i quattro plug-in.

Attenzione: non si tratta di “chi è più forte”, ma di “chi si adatta meglio alla tua situazione”.

DimensioneWP RocketCache LiteSpeedWP Super CacheW3 Total Cache
Posizionamento del nucleoUna soluzione integrata e senza preoccupazioni (cache + ottimizzazione)La cache a livello di server (che dipende da LSCache)La cache HTML staticaIl framework delle prestazioni (più livelli di cache + CDN)
Dipendenza dall'hostBasso (universale)Alto (è necessario LiteSpeed/OpenLiteSpeed per sfruttare la cache principale).Basso (universale)Cinese (universale, ma dipende maggiormente dall'ambiente/dalle capacità di configurazione)
Costo dell'apprendimentoBasso-medio中低高
La raccomandazione del sito di contenuti.Molto alto.È molto alto (a condizione che i requisiti siano soddisfatti)Molto alto.Medio-alto (dipende dalla squadra)
E-commerce/sito per membriDisponibile, ma è necessario fare attenzione ad escluderlo (le pagine chiave di WooCommerce non vengono memorizzate nella cache)Disponibile, ma richiede regole/strategie di frammentazione più precise.È disponibile e WooCommerce menziona la compatibilità nativa e che per impostazione predefinita le pagine chiave non vengono memorizzate nella cache.Disponibile, adatto per il controllo ingegneristico.
BudgetPagareGratuitoGratuitoVersione gratuita + versione a pagamento

“Incidenti di cache” e lista di controllo per la prevenzione

1. Le tre cause principali della “contenuto errato” causate dalla cache.

A. Trattare la pagina “con stato” come una “pagina statica senza stato”.”

Tipico: la pagina dell'account, il carrello e la pagina di checkout vengono memorizzati nella cache. WooCommerce I funzionari hanno ripetutamente sottolineato che Il carrello, la cassa e l'account non dovrebbero essere memorizzati nella cache.

B. Le varianti multilingue/multivalutarie/regionali non distinguono correttamente la cache.

Se il tuo sito mostra contenuti diversi in base ai cookie, ai parametri di query o alla posizione geografica, la cache deve tenere conto della “dimensione delle varianti”. Altrimenti, la cache generata dagli utenti dell'area A potrebbe essere riutilizzata dagli utenti dell'area B.

C. La rielaborazione dell'ottimizzazione front-end (JS/CSS) ha causato un malfunzionamento della funzionalità.

In particolare, la compressione, la fusione e l'esecuzione ritardata di JS. WooCommerce consiglia persino di farlo.Evitare di comprimere i file JS.。

2. Lista dei test di regressione da eseguire prima della messa online.

  • L'accesso/logout funziona correttamente?
  • Il modulo di invio (modulo di contatto, iscrizione, registrazione al login) funziona correttamente?
  • Processo di e-commerce: Aggiungi al carrello → Coupon → Spese di spedizione/imposte → Pagamento → Pagina dell'ordine
  • La commutazione multilingue è stabile (contenuto, URL, hreflang, valuta dopo la commutazione)?
  • I menu, le finestre pop-up, lo scrolling e il lazy loading sul dispositivo mobile funzionano correttamente?
  • Controllare se lo script di tracciamento sta ancora funzionando (GA, Meta Pixel, eventi di conversione).

problemi comuni

Q1: Perché, nonostante abbia installato il plug-in della cache, l'accesso da un paese estero è ancora lento?

Il motivo più comune è che hai risolto solo il problema della “ripetizione del rendering della stazione di origine”, ma non quello del “ritardo di rete intercontinentale”.
I plug-in di caching consentono ai server di restituire i contenuti più rapidamente (riduzione del TTFB), ma le risorse statiche (immagini, CSS, JS, font) e il RTT dei collegamenti globali richiedono ancora tempo. CDN Per ridurre la distanza.
👉 Quindi il percorso corretto è:Prima di tutto, assicurati che la cache della stazione sorgente funzioni correttamente.Dopo di che, utilizzare la CDN per la distribuzione a livello globale.。

Q2: Perché, dopo aver messo in cache i contenuti, questi non vengono aggiornati anche se li ho modificati?

Perché quello che vedi è la “vecchia cache”. Soluzione:

  • Stabilire una strategia di pulizia: dopo aver aggiornato un articolo/pagina, pulire la cache corrispondente (invece di pulire l'intero sito).
  • Per i progetti che prevedono il pre-riscaldamento/il crawling: dopo la pulizia, è necessario effettuare nuovamente il pre-riscaldamento, altrimenti la prima visita sarà lenta.
  • Per la CDN: è necessario considerare che anche i bordi della CDN potrebbero memorizzare nella cache risorse obsolete.

Q3: È possibile installare contemporaneamente WP Rocket e WP Super Cache?

Non è consigliabile. È meglio utilizzare un solo plug-in di cache delle pagine alla volta. Puoi considerare l'idea di “uno per la cache e l'altro per l'ottimizzazione” come una “divisione dei compiti”, ma nella pratica questi due componenti spesso interferiscono con la cache delle pagine/la riscrittura delle risorse, con un'alta probabilità di conflitti. È più consigliabile scegliere un “plug-in di cache principale”, integrando le altre esigenze con strumenti più specifici.

Q4: L'uso della cache nei siti di e-commerce è molto pericoloso?

Non è pericoloso, ciò che è pericoloso è “l'assenza di regole”.I consigli di WooCommerceÈ molto chiaro: il carrello, la cassa e l'account non vengono memorizzati nella cache e si evita la compressione JS.
Inoltre, WooCommerce ha anche menzionato che è compatibile con WP Super Cache è compatibile di default.E, per impostazione predefinita, evita di memorizzare nella cache le pagine più importanti.
Pertanto, il sito e-commerce può essere completamente memorizzato nella cache, ma se lo si considera una “modifica online”, è necessario testarlo.

Q5: Dovrei scegliere LiteSpeed Cache o WP Rocket?

  • Hai confermato che l'host è LiteSpeed/OpenLiteSpeed?: Priorità a LiteSpeed Cache (gratuito e potente, con vantaggi fondamentali derivanti da LSCache a livello di server)
  • Non sei sicuro dello stack dell'host / non vuoi fare fatica / vuoi una soluzione integrata e senza preoccupazioni.WP Rocket è più affidabile.
  • Sei un sito di contenuti e il tuo budget è limitato.WP Super Cache è più stabile e più leggero.

Il plug-in della cache in combinazione con il CDN

Il plug-in di caching risolve il problema del “minor conteggio da parte del server di origine e un TTFB inferiore”; il CDN risolve il problema delle “risorse statiche e delle pagine più vicine agli utenti di tutto il mondo”. L'unione di questi due elementi rappresenta la soluzione ottimale più comune per un accesso globale.

  • Una combinazione comune per i siti di contenuti:Cache delle pagine + distribuzione statica CDN
  • Una combinazione comune per i siti web dinamici è la seguente:Cache delle pagine (esclusa in modo rigoroso) + cache degli oggetti (su richiesta) + distribuzione statica CDN.

👉 Lettura:Accelerazione CDN (nodi globali e strategia di caching)

Una combinazione di raccomandazioni per la cache del sito web.

1. Sito di contenuti / Blog / Sito di documenti

Obiettivo: Redurre il TTFB, rendere più stabile la prima schermata, ridurre la pressione sul server e collaborare con il CDN per la distribuzione globale.

1.1 Il portafoglio aziendale più semplice da gestire.

  • WP Rocket (cache delle pagine + precaricamento + ottimizzazione front-end)
    • CDN (da spiegare nella pagina CDN)

Applicabile a:

  • Desideri “impostazioni semplici, risultati rapidi e basso rischio”.”
  • Ci sono molti temi/插件 e vorrei ridurre i problemi di compatibilità.

Attenzione:

  • L'ottimizzazione front-end (in particolare il ritardo JS) viene attivata in fasi, per evitare anomalie funzionali (menu, moduli, tracciamento, ecc.)
  • Per i siti che modificano spesso le pagine o pubblicano frequentemente articoli, è necessaria una strategia di “pulizia e pre-riscaldamento”. In caso contrario, la prima visita alle pagine meno popolari sarà lenta.

1.2 Un duo classico gratuito e affidabile.

  • WP Super Cache (cache HTML statica): Trasformare le pagine dinamiche in HTML statico, principalmente per gli utenti non registrati.

Applicabile a:

  • È sensibile al budget, ma deve essere stabile.
  • I visitatori di solito non effettuano il login.
  • Il ritmo di aggiornamento dei contenuti è controllabile.

Attenzione:

  • Questa è una combinazione di “priorità di caching della pagina”, non aspettatevi che risolva tutti i problemi complessi di CSS/JS in modo automatico.

2. Sito aziendale / Sito del marchio / Pagina di destinazione

Obiettivo: Dobbiamo essere veloci, ma la cosa più importante è “non interrompere il percorso di conversione a causa dell'ottimizzazione”.

2.1 Affidabile e controllabile (consigliato per la pubblicazione a livello globale/stazioni di conversione)

  • WP Rocket
  • + (opzionale) ottimizzazione delle immagini leggera (hai una pagina “Ottimizzazione delle immagini”)
    • CDN

Perché è adatto come stazione di conversione:

  • Le stazioni di conversione temono di più che “i moduli/finestre pop-up/script di tracciamento vengano rovinati dall'ottimizzazione”.”
  • L'approccio di WP Rocket è più “integrato”: puoi attivare ogni funzionalità all'interno di un unico sistema e testarla successivamente.

I “principi di lancio” del sito aziendale:

  • L'ottimizzazione delle prestazioni è una “modifica in produzione” e richiede un elenco di test di regressione.
  • Qualsiasi impostazione che riguardi il ritardo/la fusione/la compressione di JS dovrebbe essere prima verificata nell'ambiente di pre-produzione e successivamente implementata online.

3. Sito e-commerce WooCommerce (ordini + sicurezza delle pagine dinamiche)

Obiettivo: È necessario essere veloci e, al contempo, garantire che le pagine del carrello, del checkout e dell'account siano assolutamente corrette.

Il punto di vista ufficiale di WooCommerce sui plug-in di caching è molto chiaro:Le pagine del carrello, della cassa e dell'account non devono essere memorizzate nella cache.Inoltre, si consiglia di evitare di comprimere i file JavaScript per ridurre i problemi di compatibilità.

3.1 Percorsi di sicurezza gratuiti più “adatti ai principianti”

  • WP Super Cache + WooCommerce
    • CDN

Perché lo abbiamo elencato come “un'introduzione più sicura”:

  • WooCommerce afferma ufficialmente di essere compatibile nativamente con WP Super Cache e informa che WP Super Cache non memorizza nella cache per impostazione predefinita pagine chiave come il carrello, la pagina di checkout e l'account.
  • Per i siti che iniziano a fare e-commerce, “evita di commettere errori” è più importante della “massima performance”.

3.2 Se stai utilizzando l'hosting LiteSpeed (gratis ma molto potente)

  • LiteSpeed Cache (è necessario un host LiteSpeed/OpenLiteSpeed per sfruttare i vantaggi della cache del server principale).
  • + (opzionale) Cache degli oggetti (Redis/Memcached, in base alle capacità dell'host e alle dimensioni del sito)
    • CDN

Applicabile a:

  • L'impilamento degli host è chiaro e sei disposto a stabilire regole di cache e strategie di esclusione.
  • Il volume degli ordini e della merce è elevato, e questo richiede che il server di origine sia in grado di gestire un carico maggiore.

3.3 Team di ingegneria/e-commerce complesso (controllabile su più moduli)

  • W3 Total Cache (framework di performance, con più livelli di caching e integrazione con CDN)
    • Cache degli oggetti (su richiesta)
    • CDN

Applicabile a:

  • Se si tratta di sviluppo/gestione e manutenzione, è possibile rilasciare il prodotto seguendo la procedura “attivazione graduale dei moduli + test di stress + test di regressione”.
  • È necessaria la cache dei frammenti/una strategia di varianti più complessa (ad esempio, una cache granulare in base al dispositivo/alla regione/alla lingua).

4. Siti per membri/comunità/corsi online (con un'elevata frequenza di accesso e una forte personalizzazione)

Obiettivo: Fare in modo che i contenuti pubblici siano rapidi e, al contempo, garantire che i “contenuti degli utenti connessi non vengano compromessi”.

4.1 È una strategia pratica ma richiede di escludere rigorosamente alcune possibilità.

  • WP Rocket
  • + (opzionale) Caching degli oggetti (se ci sono molte query dinamiche)
    • CDN

Punti chiave:

  • Devi escludere dalla cache le pagine che cambiano in base all'utente: profilo personale, ordini, progressi di apprendimento, messaggi, carrello della spesa, ecc.
  • Questo tipo di siti è più soggetto a “problemi di visualizzazione dei contenuti/autorizzazioni errate degli altri utenti”, ed è necessario spiegare chiaramente i rischi nella pagina.

4.2 Host LiteSpeed + strategia avanzata

  • LiteSpeed Cache (cache del server + strumenti di strategia più complessi)
  • + Cache degli oggetti (se necessario)
    • CDN

Punti chiave:

  • I siti per membri hanno spesso bisogno di un approccio che prevede “contenuti memorizzabili nella cache + frammenti non memorizzabili nella cache”.
  • Le strategie di pre-riscaldamento e pulizia devono essere più accurate, altrimenti sarà molto frequente che gli utenti continuino a vedere i vecchi contenuti dopo l'aggiornamento.

Il sito web memorizza nella cache la “Banca dati dei casi di sminamento”.”

Caso 1: Dopo aver installato il plug-in della cache, la velocità non è cambiata quasi per niente.

Fenomeno:

  • La velocità di connessione è accettabile a livello locale/nella stessa regione, ma è ancora lenta all'estero (tra continenti).
  • Il TTFB è migliorato, ma il tempo di caricamento complessivo non è diminuito in modo significativo.

Cause più comuni:

  • Hai eseguito la cache del sito di origine (TTFB), ma le risorse statiche (immagini/JS/CSS/font) vengono ancora caricate dal sito di origine a livello intercontinentale.
  • Gli script di terze parti (pubblicità, chat, statistiche) rallentano il rendering e l'interazione.
  • Le immagini sono troppo grandi e questo rende il download lento (la cache non può risolvere il problema della dimensione del “primo download”).

Soluzione: Sostituire la pompa di carburante.

  • Il plug-in della cache si occupa prima di “meno calcoli da parte del sito di origine + tasso di hit”.”
  • Le risorse statiche passano attraverso la CDN.
  • La foto deve essere ottimizzata per le immagini.
  • Scenari di ritardo/frazionamento realizzati da script di terze parti.

Leggere:

Caso 2: dopo aver attivato la cache, la pagina è stata modificata ma l'interfaccia utente non è stata aggiornata.

Fenomeno:

  • I contenuti/lo stile del back-end sono stati aggiornati, ma il front-end mostra ancora la vecchia versione.
  • O forse solo alcune zone vengono aggiornate, mentre altre rimangono invariate (questo è molto comune nei siti web globali).

Cause più comuni:

  • La cache della pagina non è stata pulita o l'ambito della pulizia non è corretto.
  • Il riscaldamento/il crawler non sono stati eseguiti, e dopo la pulizia la cache è diventata fredda, causando rallentamenti nelle prime visite, mentre tu hai erroneamente pensato che non ci fosse stato alcun aggiornamento.
  • Se hai attivato la cache di bordo del CDN, anche il bordo potrebbe conservare le risorse obsolete.

Soluzione: Sostituire la pompa di carburante.

  • Stabilire una “strategia di pulizia dopo la pubblicazione/modifica”: pulire le pagine pertinenti, anziché procedere a una pulizia completa di tutto il sito.
  • Stabilire una strategia di pre-heating per le pagine importanti (homepage, pagine di destinazione principali) per evitare che “la pulizia rallenti il sito”.”
  • Il livello CDN esegue la pulizia dei bordi quando necessario.

Caso 3: contenuti confusi dopo il passaggio a più lingue/valute

Fenomeno:

  • Dopo aver cambiato la lingua, la pagina continua a mostrare la lingua precedente.
  • O, in alcune zone, gli utenti potrebbero vedere la valuta o il contenuto sbagliati.

Cause più comuni:

  • La cache non fa distinzione tra le “dimensioni delle varianti” (cookie/parametri/prefisso della lingua/sottodominio).
  • Il hit della cache ha fornito i risultati della pagina in lingua A agli utenti della lingua B.

Soluzione: Sostituire la pompa di carburante.

  • Definisci il tuo schema multilingue: directory/sottodomini/parametri/cookie.
  • Aggiungere una “strategia di variante” alle regole della cache o escludere le pagine chiave.
  • Alcuni siti richiedono un approccio più avanzato alla “cache di frammenti” (W3TC è più adatto per il controllo a livello di ingegneria).

Caso 4: dopo l'attivazione della cache nel sito di e-commerce, si sono verificati problemi con il carrello degli acquisti/il processo di checkout.

Fenomeno:

  • Il numero di carrelli è sbagliato, i prezzi sono errati e il pulsante di checkout non funziona.
  • Dopo aver effettuato l'accesso, ho visto dei contenuti che non mi appartenevano (grave)

Cause più comuni:

  • Le pagine chiave come Carrello, Checkout e Il mio account vengono memorizzate nella cache.
  • La minimizzazione/unificazione del JS ha causato l'incompatibilità dei componenti di pagamento/dynamici.

Soluzione: Sostituire la pompa di carburante.

  • WooCommerce afferma ufficialmente che il carrello, il checkout e l'account non devono essere memorizzati nella cache e consiglia di evitare la compressione dei file JS.
  • Prima rendiamo stabile la “cache delle pagine + esclusione”, poi consideriamo l'ottimizzazione del front-end.
  • Se si utilizza WP Super Cache, WooCommerce afferma che è compatibile di default e che eviterà automaticamente la cache delle pagine chiave.

Caso 5: Dopo aver attivato “Ritardo JS/Script di fusione”, il menu/il modulo/la finestra pop-up non funzionano più.

Fenomeno:

  • Il menu di navigazione non si apre.
  • La convalida del modulo è fallita o il modulo non può essere inviato.
  • La finestra pop-up/il carosello sono anomali.
  • Gli eventi statistici/di conversione non vengono attivati (il problema più grave per i siti di pubblicità).

Cause più comuni:

  • Il ritardo JS cambia il momento dell'esecuzione dello script: lo script non viene eseguito prima dell'interazione dell'utente e alcuni componenti dipendono dall'inizializzazione immediata dopo il caricamento della pagina.“
  • La fusione/compressione potrebbe modificare l'ordine degli script o compromettere le dipendenze.

WP Rocket descrive l'esecuzione ritardata di JavaScript come una delle sue più potenti ottimizzazioni JavaScript: gli script vengono ritardati fino a quando l'utente interagisce, in modo da dare priorità al rendering della pagina. Questa funzionalità è molto potente, ma comporta un maggiore rischio di incompatibilità.

Soluzione: Sostituire la pompa di carburante.

  • Attivazione in fasi: prima la cache, poi le immagini, quindi i CSS e infine i JS.
  • Aggiungere delle eccezioni agli script chiave (pagamento, moduli, menu, tracciamento)
  • Ogni volta che viene apportata una modifica, è necessario eseguire un test di regressione.

Caso 6: Ho installato solo LiteSpeed Cache, ma non mi sembra che sia molto utile.

Fenomeno:

  • Ho attivato LiteSpeed Cache, ma il TTFB non è diminuito molto.
  • Anche il tasso di successo non è particolarmente evidente.

Cause più comuni:

  • Il tuo server non è LiteSpeed/OpenLiteSpeed, quindi non puoi utilizzare le funzionalità principali di LSCache.
  • O forse hai attivato un sacco di ottimizzazioni, ma non hai impostato la “strategia di caching delle pagine/preloading/esclusione”.

Soluzione: Sostituire la pompa di carburante.

  • Prima di tutto, verifica la pila dell'host: se è LiteSpeed/OpenLiteSpeed (questo è un presupposto).
  • Rifocalizzare il lavoro su “strategia di caching delle pagine + pre-riscaldamento + esclusione + pulizia”.”
  • Se non si tratta di un host LiteSpeed: prendere in considerazione WP Rocket o WP Super Cache.