inizio fig./guida/Ottimizzazione del sito web/Dettagli sul contenuto

La causa principale della “lentezza” di un sito web di solito non è un'immagine particolare, ma piuttostoCollegamento di richiesta + Generazione del server + Distribuzione statica delle risorsecausati dalla sovrapposizione:

  • Gli utenti sono troppo lontani dai vostri server, l'RTT della rete è alto (più evidente nei continenti)
  • WordPress esegue PHP, controlla il database e crea il modello per ogni richiesta → TTFB (tempo al primo byte) su
  • Le pagine caricano anche JS/CSS/fonts/scritture di terze parti, rallentando il rendering e l'interazione.

Plugin di cachingIl cuore della soluzione consiste nel salvare i risultati delle pagine “doppiamente contate”, in modo che il server non debba ricalcolarli ogni volta, e nel ridurre in modo significativo il TTFB, consentendo a un maggior numero di utenti di accedere alla cache con la giusta strategia.Documentazione ufficiale di WordPressÈ stato inoltre sottolineato che plugin come W3 Total Cache e WP Super Cache possono memorizzare nella cache le pagine come file statici e poi servirle direttamente all'utente, riducendo il carico di elaborazione del server.

Prima di leggere questa pagina, ricordate 3 regole ferree

1. Plugin di caching della pagina contemporaneamente solo uno

Il risultato più comune dell'attivazione di più plugin di caching allo stesso tempo non è una maggiore velocità:

  • Sovrascrittura delle regole di cache dell'altro, cancellazione delle cache dell'altro, diminuzione del tasso di hit della cache
  • I contenuti dinamici come lo stato di login/la lingua/la macchina/il prezzo vengono memorizzati nella cache, con conseguenti incidenti di “contenuto errato”.
    Molte documentazioni/istruzioni sui plugin suggeriscono che quando si usa un certo plugin per la cacheDisattivare altri plugin di cachingper evitare conflitti.

2. Siti di e-commerce/membership/multilingue: il caching non è un “interruttore on/off”, ma un “sistema di regole”.”

Documentazione ufficiale sulle prestazioni di WooCommercePromemoria esplicito: nel plugin della cache assicurarsi che Carrello / Cassa / Account Si raccomanda inoltre di evitare la compressione dei file JavaScript (poiché tende a causare problemi di compatibilità).

3. “Plug-in di cache ≠ CDN”, ma il plug-in di cache è la base dell'CDN.

Plugin di cache per risolvere il problema del “sottoconteggio delle stazioni sorgente”;CDN Risolvere il problema del “contenuto più vicino agli utenti”. Il rapporto tra i due è sovrapposto: in primo luogo, la stazione di origine TTFB viene premuta, quindi le risorse statiche vengono consegnate a CDN per la diffusione, che è il percorso più stabile per gli utenti globali.

Scelte rapide: 4 scenari più comuni per i siti web

Se non volete leggere tutto l'articolo, non potete sbagliare con le seguenti 4 scelte:

  1. Desiderano risparmiare denaro, essere stabili e orientarsi verso l'accesso globale → WP Rocket(Pagato)
  2. L'hosting è esplicitamente LiteSpeed/OpenLiteSpeed → Cache LiteSpeed(gratuito ma fortemente dipendente dalla capacità del server)La funzione di caching richiede Componenti del server LiteSpeedlavoro solo allora
  3. Siti di contenuti/blog/siti di documenti che vogliono essere liberi e stabili → WP Super Cache(cache HTML statica)Generare file HTML statici da fornire alla maggior parte degli utenti non loggati.
  4. Disponete di un team tecnico con un controllo preciso (CDN/object caching/multi-modulo) → W3 Total Cache(forte ma complesso)Mantiene un quadro di prestazioni completo con l'integrazione di CDN

Che cosa memorizza esattamente la cache?

“Perché alcuni siti sono ancora lenti con la cache”, abbiamo suddiviso le prestazioni di WordPress in 5 livelli:

  1. cache del browserRendere l'accesso secondario più veloce per gli utenti (intestazioni statiche della cache delle risorse, numeri di versione).
  2. pagina cache: Output della pagina di cache come HTML (carattere principale di questa pagina)
  3. cache degli oggettiCache degli oggetti dei risultati delle query del database (le stazioni dinamiche sono più preziose)
  4. PHP OPcacheCache PHP bytecode (di solito configurato dal server, non dall'obiettivo del plugin)
  5. CDN/cache di bordoMettere le risorse nei nodi più vicini agli utenti

L'obiettivo di questo articolo: il plugin per il caching delle pagine;
Ma vi viene costantemente ricordato che spesso i siti web hanno bisogno di una combinazione di 2 + 5 per essere “veramente veloci”.

Plug-in 1:WP Rocket(a pagamento) - Programmi integrati “salva-mente”.

WP Rocket è popolare nella scena “WordPress” non perché sia magico, ma perché trasforma i tre tipi più comuni di prestazioni in “pacchetti gestibili”:

  • Caching della pagina (riduce il TTFB del sito di origine)
  • Precaricamento/riscaldamento della cache (per migliorare l'esperienza della prima visita con accesso distribuito a livello globale)
  • Ottimizzazioni chiave del front-end (in particolare latenza JS, gestione CSS, ecc.).

il suodocumento ufficialeViene inoltre indicato esplicitamente che l'attivazione del precaricamento può innescare/guidare alcune ottimizzazioni (ad esempio quelle relative a CSS/JS) anche se si disattiva la cache della pagina.

1.1 Per chi è WP Rocket

WP Rocket è particolarmente adatto a queste stazioni:

  • Sito web aziendale, sito di branding, sito di content marketing, landing page (traffico da più paesi e regioni)
  • Voglio “andare in onda rapidamente, la stabilità prima”, non voglio scrivere un sacco di combinazione di plugin gratuito
  • Non ci sono ingegneri Ops/Performance dedicati, ma abbiamo esperienza e requisiti SEO
  • WooCommerce Può anche essere utilizzato, ma con maggiore cautela (per saperne di più in questa sezione).Regole e rischi）

1.2 Il suo valore chiave negli scenari di accesso al web (non solo un “cache switch”)

A. Precaricamento della cache: risolvere il problema delle “prime visite instabili a causa dell'accesso distribuito ai siti web”.”

Si verificherà un rallentamento molto tipico quando gli utenti del sito sono sparsi:
Un utente in una certa regione apre per la prima volta una pagina che si dà il caso sia fuori dalla cache o non sia mai stata riscaldata → quell'utente sostiene l'intero costo di rendering PHP/DB.
Meccanismo di precaricaIl significato di questo è:Pagare in anticipo i costi di “prima generazioneLa prima visita del programma sarà una “cavia”, riducendo la probabilità di una "prima visita da cavia".

  • Nessun precaricamento: chi accede per primo subisce
  • Con il precaricamento: il sistema in background genera in modo unificato la cache, e l'esperienza della prima visita è più stabile.

B. Esecuzione differita di JavaScript: la funzione più semplice per “sentirsi immediati” nella visita di un sito web, ma anche la più rischiosa.

WP Rocket mette ufficialmente “Esecuzione ritardata di JS” la descrive come la sua ottimizzazione JS più forte: rinvia l'esecuzione degli script fino a quando l'utente non ha avuto un'interazione (ha mosso il mouse, ha toccato lo schermo, ha fatto scorrere la pagina, ha premuto un tasto e così via) per dare priorità al rendering della pagina.

Questo è importante per l'accesso ai siti web, perché il blocco del caricamento e dell'esecuzione degli script è più probabile che venga amplificato sulle reti transcontinentali:

  • Download di risorse più lento → il thread principale ha più probabilità di essere impantanato dagli script
  • Gli script di terze parti (statistiche, annunci, plugin di chat) hanno maggiori probabilità di peggiorare i ritardi di INP/interazione.

Ma può anche causare problemi:

  • Il ritardo di JS può influire su: menu, rotazioni, popup, convalida dei moduli, pagamenti, tracciamento delle sepolture.
  • È quindi adatto a una strategia di “esclusione graduale + blacklist”.

C. Compatibilità con altri plugin/temi: “zero conflitti” non equivale a "tranquillità".”

WP Rocket ha ufficialmente inserito nell'elenco “Plugin/temi incompatibili”, per ragioni che includono meccanismi come il buffering dell'output che influirebbero sulla cache/ottimizzazione di WP Rocket.

  • Se il vostro sito è molto ricco di plugin e temi, pensate all“”ottimizzazione delle prestazioni" come a un mini progetto di go-live: test di regressione per ogni modifica (moduli, login, pagamenti, passaggio a più lingue, ecc.).

1.3 Promemoria speciale per WooCommerce/Sito dinamico

Il promemoria principale della documentazione ufficiale di WooCommerce per la configurazione del plugin di caching è:

Perché? Per:

  • Forte dipendenza da carrello, checkout, pagina dell'account cookie / sessione / nonce
  • Una volta che la cache tratta queste pagine come “pagine statiche”, i pulsanti non funzioneranno e le informazioni sui prezzi, sull'inventario e sul conto saranno alterate.
  • Ecco la parte spaventosa: i test potrebbero andare bene in una regione e avere problemi in un'altra a causa delle discrepanze tra CDN e hit della cache!

1.4 Raccomandazioni per la strategia dei plugin di cache

Livello 1: prestazioni di sicurezza di base (quasi tutte le stazioni dovrebbero farlo)

  • Abilitare la cache della pagina
  • aprePrecaricamento della cache(Miglioramento della stabilità della prima visita)
  • Politica di caching del browser sensata (WP Rocket/Server/CDN Entrambi i livelli possono essere implementati)

Livello 2: Media ricompensa, medio rischio (adatto alla maggior parte dei siti di contenuti)

  • Ritardo nel caricamento delle immagini/iframe (la pagina di ottimizzazione delle immagini è più approfondita)
  • Controllo del volume dei CSS (ad es. rimozione dei CSS inutilizzati)

Tier 3: Alto rendimento ma alto rischio (deve avere una lista di controllo per i test di regressione)

1.5 Prezzi e autorizzazioni

  • WP Rocket è una licenza a pagamento, con licenze diverse a seconda del numero di siti.

Plugin 2:LiteSpeed Cache (LSCWP)--La premessa di “free tops” è che il server è in realtà LiteSpeed.

Molte persone hanno un'idea sbagliata su LiteSpeed Cache: pensano che sia solo un plugin per WordPress che potete installare e che funzionerà come WP Rocket su qualsiasi host con piena potenza. Non è così.

Documentazione ufficiale di LiteSpeedSpiegazione chiara: la funzione di caching di LSCWP richiede LiteSpeed Server perché comunica con la cache delle pagine integrata nel LiteSpeed Web Server (LSCache); il plugin è responsabile di dire al server quali pagine sono memorizzabili nella cache, per quanto tempo, e di attivare la pulizia con i tag.

La forza principale di LiteSpeed Cache deriva da “Caching delle pagine a livello di server (LSCache)”. Senza i server LiteSpeed/OpenLiteSpeed, non c'è questo vantaggio fondamentale.

2.1 Cache LiteSpeedper chi

In forma:

  • Il vostro pannello di hosting è chiaramente etichettato LiteSpeed / OpenLiteSpeed(ad esempio, molti host cPanel scriveranno)
  • Volete “una soluzione gratuita che possa funzionare anche con TTFB e concurrency”.”
  • Siete disposti ad accettare: è molto potente, ma anche più concettuale (TTL, Tag, Purge, ESI, Crawler...).

Non proprio:

  • Non siete sicuri di quale sia il server web dell'host, o confermate che si tratta di Nginx/Apache (a meno che non vogliate utilizzare solo alcune delle sue funzioni di ottimizzazione del front-end, ma in questo caso il prezzo/prestazioni e la complessità non sono necessariamente convenienti)
  • Siete un sito complesso di e-commerce/membership/multi-lingua, ma non avete un processo di test (LSCWP è forte, ma è anche più facile “mettere in cache il contenuto sbagliato”)

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

Si potrebbe scrivere la meccanica di LiteSpeed Cache come una “spiegazione ingegneristica”:

  • WP Rocket / WP Super Cache Si tratta più che altro del lato WordPress/PHP della cache e dell'ottimizzazione;
  • LSCWP Si tratta di una combinazione tra il pannello di controllo di WordPress e la LSCache integrata di LiteSpeed Server: il plugin è responsabile dell'emissione delle regole e dei segnali di pulizia, mentre il vero e proprio caching ad alta velocità delle pagine avviene nel pannello di controllo di WordPress.livello server。

Questo ha un impatto diretto sull'esperienza del sito web: lo spit caching a livello di server è di solito più leggero, più veloce e più concomitante (soprattutto in caso di picchi di traffico e di visite ad alta frequenza da parte dei crawler dei motori di ricerca).

2.3 Il “modo giusto” di aprire l'LSCWP per gli scenari di utilizzo del sito web”

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

Livello 1: Politica di cache della pagina (determina se il TTFB può davvero diminuire)

  • Chiarire quali pagine possono essere memorizzate nella cache (la maggior parte delle pagine di contenuto pubblico).
  • Chiarire quali pagine non dovrebbero mai essere memorizzate nella cache (login, account, carrello, checkout, pagine di cambio lingua/valuta che si basano su cookie forte).
  • Impostare un TTL ragionevole per la cache (più frequentemente il contenuto viene aggiornato, più breve è il TTL, più lungo è il TTL).
  • Creare una strategia di pulizia: ripulire i tag rilevanti dopo l'aggiornamento dei contenuti (piuttosto che una pulizia brutale dell'intero sito).

Questo livello, se realizzato correttamente, è più direttamente visibile al sito web come il TTFB in calo, prima schermata più stabile。

Strato 2: Warm-up/Crawler (determina la “prima visita lenta a una pagina fredda”)

Una comune “incoerenza di esperienza” nell'accesso al sito web deriva dalle “differenze caldo/freddo” nella cache:

  • Le pagine più visitate vengono sempre visitate e la cache è sempre calda
  • Le pagine fredde non vengono cliccate da molto tempo e chi clicca per la prima volta è lento.

Il riscaldamento non è la ciliegina sulla torta, ma la chiave per un'esperienza coerente dei visitatori del sito web.

Layer 3: Programmi di sicurezza per contenuti dinamici (e-commerce/membership/multilinguismo)

La potenza di LSCWP è che offre molti “strumenti avanzati”, ad esempio:

  • Strategie di caching differenziate per utenti loggati, utenti di commenti, ecc.
  • L'idea di base dell'Edge Side Inclusion (ESI) è quella di dividere la pagina in "corpo pubblico memorizzabile nella cache" e "frammenti dinamici non memorizzabili", che vengono elaborati separatamente e poi giuntati ai nodi edge.

Livello 4: Servizi online e miglioramenti opzionali

Molti webmaster troveranno utili i servizi online di QUIC.cloud (ad esempio i servizi di ottimizzazione delle pagine) nell'ambito del LSCWP.Documentazione QUIC.cloudÈ scritto esplicitamente che fornisce servizi di ottimizzazione delle pagine a LSCWP, tra cui Critical CSS (CCSS), Unique CSS (UCSS), Viewport Images (VPI) e altri.

  • Questo tipo di servizio è facoltativo: è possibile utilizzare solo la cache del server e non abilitare l'ottimizzazione online.
  • Una volta abilitati i servizi online, le risorse del sito e i link per l'elaborazione delle pagine cambieranno (si tratta di un'informazione importante per le aziende e i clienti sensibili alla privacy).

2.4 Fossa comune LSCWP

  1. Il server non è LiteSpeed, ma utilizza LSCWP come plugin di caching completo.
    Risultato: la cache non è efficace come previsto e aumenta la complessità della configurazione. Soluzione: Confermare innanzitutto lo stack dell'host; in caso contrario LiteSpeedSi pensi, ad esempio, a WP Rocket o WP Super Cache.
  2. L'abilitazione di troppe ottimizzazioni del front-end porta ad anomalie funzionali
    Le ottimizzazioni della pagina (CSS/JS) hanno spesso maggiori probabilità di causare problemi di compatibilità rispetto alla “cache stessa”. Suggerimento: eseguite prima la cache della pagina, quindi attivate le ottimizzazioni una per una e create un elenco di test di regressione (moduli, menu, pagamenti, tracciamento, cambio di lingua, ecc.)
  3. Mancanza di strategie di esclusione/slicing per le pagine dinamiche
    Episodi tipici: carrello della spesa, checkout, pagina dell'account memorizzati nella cache; o commutazione errata tra più lingue e più valute. I siti di e-commerce devono tenere conto di questo aspetto come controllo pre-lancio (e i responsabili di WooCommerce sottolineano anche che)Non memorizzare nella cache le pagine chiave）。

Plugin 3:WP Super Cache(gratuito) - Una classica soluzione “a basso rischio e alto rendimento” per i siti di contenuti.

WP Super Cache Perché è stato così popolare per così tanto tempo? Perché risolve i problemi in modo molto diretto, molto “server-friendly”:
Generare file HTML statici da pagine dinamiche di WordPressI file HTML vengono quindi serviti direttamente dal server Web, evitando la costosa elaborazione PHP.

La pagina del plugin menziona anche che: l'HTML statico sarà servito alla stragrande maggioranza degli utenti non loggati, e fornisce una dichiarazione molto intuitiva: “ai visitatori di 99% saranno serviti file HTML statici”, e un singolo file in cache può essere servito migliaia di volte.

3.1 Per chi è WP Super Cache?

Altamente raccomandato:

  • Blog, siti di contenuti multimediali, siti di documenti, siti vetrina aziendali, landing page
  • I visitatori sono per lo più utenti non registrati
  • Desiderate: gratuità, stabilità, bassi costi di manutenzione

Usare cautela/avere bisogno di strategie più forti:

  • Sito fortemente dinamico: molti contenuti personalizzati, pagine che cambiano in base allo stato dell'utente
  • Grandi e-commerce: può funzionare, ma assicuratevi che le pagine chiave non siano memorizzate nella cache e lavorate con il vostro processo di test.

3.2 I suoi tre metodi di caching:

La descrizione del plugin WP Super Cache elenca 3 metodi di caching in base alla velocità e ne spiega le differenze:

  • mod_rewrite (esperto): il più veloce, bypassando completamente l'PHP, ma è necessario modificare .htaccess, una configurazione impropria può portare a un rischio di indisponibilità del sito è più alto!
  • Semplice (approccio consigliato): file statici “Super cached” forniti da PHP, vicini alla velocità di mod_rewrite, ma più facili da configurare.
  • WP-Cache Cache: più flessibile per gli utenti noti, gli URL con parametri, i feed di sottoscrizione, ecc. ma più lento

Scelta consigliata:

  • Principianti/alla ricerca di stabilità: utilizzare il metodo consigliato (semplice)
  • Conoscete le regole del server e siete disposti a correre il rischio di riscriverle: prendete di nuovo in considerazione il modello esperto!
  • Serve una gestione più flessibile di “Utente noto/con parametri”: capire la posizione di WP-Cache

3.3 Punti di forza e di debolezza di WP Super Cache

Vantaggio:

  1. Ideale per l'uso con il modello CDN.
    Poiché si tratta essenzialmente di “generare HTML statico”, questo si adatta naturalmente all'idea di CDN/edge cache.
  2. I miglioramenti della pressione della stazione sorgente CPU/database sono molto semplici.
    Anche i motori di ricerca e i crawler dei social media possono provenire da tutto il mondo quando il traffico del sito web è disperso. La staticizzazione è efficace per combattere il “re-rendering”.

Tavola corta:

  1. Non si tratta di una “suite di ottimizzazione delle prestazioni tutto in uno”.”
    Si basa principalmente sulla cache della pagina e le ottimizzazioni profonde di CSS/JS non sono così complete come in WP Rocket. Potrebbe essere necessario intervenire maggiormente nella “Pagina di ottimizzazione delle immagini” e nella “Pagina di ottimizzazione del frontend” (o utilizzare altre ottimizzazioni a livello di plugin/tema).
  2. Siate più cauti con la “personalizzazione dinamica”.
    Ad esempio, è possibile mostrare contenuti diversi in base alla regione, mostrare prezzi/lingue/raccomandazioni diverse in base allo stato dell'utente, ecc. A questo punto è necessario creare una politica di esclusione o introdurre uno schema di cache più adatto.

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

Guida ufficiale di WooCommerceMenzionato: WooCommerce è nativamente compatibile con WP Super Cache e WooCommerce invia un messaggio a WP Super Cache in modo da non memorizzare nella cache le pagine del carrello, del checkout e del mio account per impostazione predefinita.

  • Anche se siete nuovi a WP Super Cache + WooCommerce, è molto meno probabile che vi troviate nella mina “pagine chiave in cache”!
  • Tuttavia, si consiglia di effettuare i test di regressione prima di andare in produzione (pagamenti, coupon, spedizioni, aliquote fiscali, multivaluta, ecc.)

Plugin 4:W3 Total Cache (W3TC)--Il più versatile “quadro delle prestazioni” per i team di ingegneri.

W3 Total Cache Piuttosto che un “singolo plugin per la cache”, WordPress.org si posiziona come qualcosa di più simile a un “framework per l'ottimizzazione delle prestazioni del sito”: pone l'accento sull'integrazione CDN e sulle best practice per migliorare il SEO, i Core Web Vitals e l'esperienza complessiva attraverso l'integrazione e le best practice CDN.

La descrizione del plugin elenca un'ampia gamma di funzionalità: caching di pagine/post, caching di CSS/JS, caching di feed, caching di risultati di ricerca, caching di oggetti del database, caching di oggetti, caching di frammenti (fragment cache) e supporto per una varietà di metodi di caching come Redis/Memcached/APC, ma include anche il caching di raggruppamenti mobili per UA/Referrer, AMP, integrazione con reverse proxy (Nginx/Varnish) e così via.

4.1 A chi si rivolge W3 Total Cache?

Perfetto per:

  • Avete competenze di sviluppo/operative e siete disposti a fare “enablement + pressure test + regression test”.”
  • Il vostro sito è complesso: multilingue, passaggio a più temi, differenziazione per i dispositivi mobili, struttura complessa dei contenuti.
  • Non si vuole solo la cache delle pagine, ma anche incorporare la cache degli oggetti e dei frammenti nel sistema (soprattutto per i siti dinamici).

Non si adatta:

  • Si vuole “installare e partire”, non si vogliono capire le gerarchie della cache.
  • Non avete un processo di test, ma volete attivare in un colpo solo elementi ad alto rischio come la compressione e gli script ritardati.

4.2 Perché è “forte ma complesso”: i siti web valorizzano la “controllabilità”.”

Il valore di W3TC non sta nel fatto che “deve essere più veloce di tutti gli altri”, ma nel fatto che offre un numero sufficiente di manopole di controllo per elaborare una strategia di prestazioni:

  • Cache di pagina: può essere in memoria, su disco o in CDN
  • Cache degli oggetti del database, cache degli oggetti: disponibile Redis/Memcached, ecc.
  • Caching dei frammenti: ottimo per le “pagine semidinamiche”.
  • Supporto per i dispositivi mobili: memorizzazione nella cache delle pagine in base al referrer o al gruppo dell'agente utente
  • Gestione CDN: gestione trasparente CDN delle librerie multimediali, dei file dei temi, ecc.

Queste funzionalità sono particolarmente preziose per i siti web, dove l'accesso globale è frequente:

  • Varianti della stessa pagina su diversi dispositivi, in diverse regioni, in diverse lingue
  • Alcuni contenuti possono essere memorizzati nella cache, altri devono essere in tempo reale (ad es. prezzo, inventario, stato dell'utente).

4.3 “Ordine di abilitazione consigliato” di W3TC”

Ordine consigliato:

  1. Iniziare attivando solo la cache della pagina
    Verificare: il TTFB è disattivato, i contenuti sono coerenti, i processi chiave di login/ multilingua/e-commerce funzionano.
  2. Riabilitare la cache del browser
    Obiettivo: rendere più veloci le visite di ritorno e le risorse statiche e ridurre i download ripetuti in tutti i continenti.
  3. Rivalutare la cache degli oggetti / la cache degli oggetti del database
    Applicabile: Sito dinamico (WooCommerce, Membership System, Query complesse).
    N.d.T.: Le stazioni di solo contenuto possono avere ritorni limitati o addirittura aumentare il consumo di risorse.
  4. Tocco finale Compressione / Scripting della latenza / Ottimizzazione del front-end
    Poiché questo è il livello che più facilmente può innescare anomalie funzionali, è necessario creare un elenco di test di regressione (pagamenti, moduli, tracciamento, pop-up, menu, cambio di lingua, ecc.)

Promemoria di WooCommerce per la “Configurazione del plugin Cache”.Le pagine critiche non vengono memorizzate nella cache e si raccomanda di evitare la compressione dei file JS.

Matrice di confronto dei quattro plug-in

Nota: non si tratta di “chi è migliore”, ma di “chi è più adatto al vostro scenario”.

dimensione (matematica)WP RocketCache LiteSpeedWP Super CacheW3 Total Cache
posizionamento del nucleoIntegrazione intelligente (caching + ottimizzazione)Caching a livello di server (si basa su LSCache)Caching HTML staticoStruttura delle prestazioni (più livelli di cache + CDN)
dipendente dall'ospiteBasso (universale)Alto (richiede LiteSpeed/OpenLiteSpeed per funzionare come core cache)Basso (universale)Medio (universale, ma più dipendente dall'ambiente/configurabilità)
Costi di apprendimentomedio-bassoMedio低Alto
Raccomandazione della stazione di contenutiMolaltoMolto alto (a condizione che sia rispettato)MolaltoMedio-alto (a seconda della squadra)
Sito di e-commerce/membershipDisponibile, ma da escludere con cautela (le pagine chiave di WooCommerce non sono memorizzate nella cache).Disponibile, ma con maggiore necessità di regole/strategie di affettamentoè disponibile e WooCommerce menziona la compatibilità nativa e l'assenza di caching delle pagine chiave per impostazione predefinita.Disponibile e adatto al controllo ingegneristico
bilanciocoprire i costifreewarefreewareVersione gratuita e a pagamento

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

1. Tre cause principali del “contenuto sbagliato” dovuto al caching

A. Trattare le pagine “stateful” come “pagine statiche senza stato”.”

Tipico: la pagina dell'account, il carrello e la pagina di checkout sono memorizzati nella cache.WooCommerce I funzionari hanno ripetutamente sottolineato Carrello/Checkout/Account non devono essere memorizzati nella cache.

B. Le varianti multilingue/multivaluta/regionali non vengono memorizzate correttamente nella cache

Se il sito visualizza contenuti diversi in base a cookie, parametri di query e posizione geografica, la cache deve tenere conto delle “dimensioni variabili”. Altrimenti, le cache generate dagli utenti della regione A potrebbero essere riutilizzate dagli utenti della regione B.

C. Ottimizzazione del front-end (riscrittura di JS/CSS) che porta ad anomalie funzionali

In particolare, la compressione JS, l'unione e l'esecuzione ritardata.Evitare la compressione dei file JS。

2. Lista di controllo dei test di regressione pre-lancio

  • L'accesso/uscita è normale
  • I moduli di invio (modulo di contatto, di iscrizione, di registrazione del login) funzionano correttamente
  • Processo di e-commerce: aggiungere l'acquisto → coupon → spedizione/tasse → pagamento → pagina dell'ordine
  • Stabilità della commutazione multilingue (contenuti, URL, hreflang, valuta dopo la commutazione)
  • I menu mobili, i pop-up, lo scorrimento e il caricamento pigro funzionano correttamente.
  • Tracciare se gli script si attivano ancora (GA, Meta Pixel, eventi di trasformazione)

problemi comuni

Q1: Perché l'accesso all'estero è ancora lento anche se ho installato il plugin di caching?

Il motivo più comune è che si è risolto solo il problema del “rendering duplicato all'origine”, ma non quello della “latenza di rete intercontinentale”.
I plugin per la cache permettono al server di distribuire i contenuti più velocemente (TTFB down), ma le risorse statiche (immagini, CSS, JS, font) e l'RTT per i link globali devono ancora essere CDN per ridurre la distanza.
👉 Quindi il percorso corretto è:Per prima cosa, rendere stabile la cache della stazione sorgente.E poi CDN per la distribuzione globale.。

D2: Perché il contenuto non si aggiorna quando lo modifico dopo la cache?

Perché si vede la “vecchia cache”. Idea di soluzione:

  • Creare una strategia di pulizia: ripulire la cache corrispondente dopo l'aggiornamento di articoli/pagine (invece della pulizia dell'intero sito).
  • Per gli scenari con warm-up/crawler: pulire e poi riscaldare, altrimenti la prima visita sarà lenta.
  • Per CDN: è necessario considerare che i bordi di CDN possono anche memorizzare nella cache le vecchie risorse.

D3: Posso installare WP Rocket + WP Super Cache contemporaneamente?

Non consigliato. Un plugin per la cache delle pagine alla volta è il più stabile. Si può capire l'idea di “uno per la cache e uno per l'ottimizzazione” come “divisione del lavoro”, ma in realtà spesso toccano la cache della pagina/la riscrittura delle risorse e la probabilità di conflitto è alta. È più consigliabile scegliere un “plugin principale per il caching”, mentre per le altre esigenze è necessario un singolo strumento più chiaro per colmare il divario.

D4: Non è pericoloso utilizzare la cache per i siti di e-commerce?

Non è pericoloso, è il “non avere regole” che è pericoloso.Raccomandazioni di WooCommerceÈ molto chiaro: carrello/checkout/account non vengono memorizzati nella cache e la compressione JS viene evitata.
Inoltre, WooCommerce indica anche che funziona con il sistema Compatibilità nativa di WP Super Cacheed evitare di memorizzare nella cache le pagine critiche per impostazione predefinita.
Quindi il sito di e-commerce può essere memorizzato nella cache, ma deve essere testato come una “modifica live”.

D5: Devo scegliere LiteSpeed Cache o WP Rocket?

  • Sei sicuro che l'host sia LiteSpeed/OpenLiteSpeed?: priorità a LiteSpeed Cache (gratuita e forte, con vantaggi fondamentali da LSCache a livello di server)
  • Non siete sicuri dello stack di hosting / non volete scendere a compromessi / volete integrare e risparmiare.WP Rocket è più stabile
  • Siete un sito di contenuti e siete sensibili al budgetWP Super Cache è più stabile e leggero.

Plugin di cache con CDN

Il plugin di caching risolve il problema del “minor conteggio delle stazioni di origine e del TTFB inferiore”; CDN risolve il problema delle “risorse statiche e delle pagine più vicine agli utenti globali”. La combinazione dei due è una soluzione ottimale comune per l'accesso globale.

  • Una combinazione comune di stazioni di contenuto:Cache di pagina + distribuzione statica CDN
  • Combinazioni comuni di stazioni dinamiche:Cache della pagina (stretto controllo dell'esclusione) + Cache degli oggetti (su richiesta) + Distribuzione statica CDN

👉 Leggere:CDN Accelerazione (nodo globale e politica di caching)

Combinazioni consigliate per il caching dei siti web

1. Sito di contenuti / blog / sito di documenti

Obiettivo: Ridurre il TTFB, rendere più stabile la prima schermata, ridurre la pressione del server, lavorare con CDN per la distribuzione globale.

1.1 Il business mix più semplice da realizzare

  • WP Rocket (caching della pagina + precaricamento + ottimizzazione del front-end)
    • CDN (vai alla pagina CDN)

Applicabile:

  • Volete “un'impostazione bassa, risultati rapidi e rischi ridotti”.”
  • Temi/plugin a bizzeffe, si vuole ridurre la compatibilità con il lancio di un nuovo tema

Punti di attenzione:

  • Le ottimizzazioni del front-end (in particolare la latenza di JS) sono attivate per gradi per evitare anomalie funzionali (menu, moduli, tracciamento, ecc.).
  • I siti con revisioni/posting frequenti dovrebbero avere una strategia di “pulizia + riscaldamento”, altrimenti la prima visita alle pagine fredde sarà lenta.

1.2 Combinazioni classiche libere e stabili

  • WP Super Cache (cache HTML statica)Generare HTML statico da pagine dinamiche, soprattutto per gli utenti non registrati.

Applicabile:

  • Sensibile al budget ma stabile
  • I visitatori non effettuano il login
  • Ritmo controllato degli aggiornamenti dei contenuti

Punti di attenzione:

  • Si tratta di una combinazione di “page caching first”, non aspettatevi che risolva tutte le complessità CSS/JS lungo il percorso!

2. Sito aziendale / sito del marchio / landing page

Obiettivo: Siate veloci, ma soprattutto “non interrompete il legame di conversione a causa dell'ottimizzazione”.

2.1 Robusto e controllabile (stazioni di posizionamento/conversione globali raccomandate)

  • WP Rocket
  • + (opzionale) ottimizzazione leggera delle immagini (è disponibile la pagina “ottimizzazione delle immagini”)
    • CDN

Perché è un bene per le stazioni di conversione:

  • I siti di conversione hanno paura che “i moduli/popup/scritture di tracciamento vengano rovinati dall'ottimizzazione”.”
  • WP Rocket è più “integrato”, nel senso che è possibile attivare e testare ogni elemento di un sistema.

Il “principio on-line” del sito web aziendale:

  • L'ottimizzazione delle prestazioni è un “cambiamento da avviare” e deve avere una lista di controllo per i test di regressione.
  • Tutte le impostazioni che coinvolgono la latenza/la fusione/compressione di JS devono essere verificate in un ambiente di pre-rilascio prima di andare in produzione!

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

Obiettivo: È importante essere veloci, ma anche assicurarsi che le pagine del carrello, del checkout e dell'account siano assolutamente corrette.

I punti elenco ufficiali di WooCommerce per il plugin di caching sono molto chiari:Carrello / Cassa / Pagina dell'account non vengono memorizzati nella cacheSi raccomanda inoltre di evitare la compressione dei file JavaScript per ridurre al minimo i problemi di compatibilità.

3.1 Percorsi liberi e sicuri, più “a misura di principiante”

  • WP Super Cache + WooCommerce
    • CDN

Perché è indicato come “luogo più sicuro per iniziare”:

  • WooCommerce dichiara ufficialmente di essere nativamente compatibile con WP Super Cache e informerà WP Super Cache di non memorizzare nella cache pagine chiave come carrello/contratto/conto per impostazione predefinita.
  • Per i siti che iniziano l'attività di e-commerce, “nessun incidente prima di tutto” è più importante di “prestazioni estreme”.

3.2 Se si utilizza un host LiteSpeed (gratuito ma potente)

  • LiteSpeed Cache (deve essere un host LiteSpeed/OpenLiteSpeed per sfruttare la cache del server principale)
  • + (opzionale) cache degli oggetti (Redis/Memcached, a seconda della capacità dell'hosting e delle dimensioni del sito)
    • CDN

Applicabile:

  • Lo stack host è chiaro e si è disposti a stabilire regole di caching e politiche di esclusione.
  • Il volume degli ordini e delle merci è elevato e per sostenere la pressione è necessaria una stazione sorgente più forte.

3.3 Squadre ingegnerizzate/commercio complesso (controllabile da più moduli)

  • W3 Total Cache (framework per le prestazioni, livello multi-cache integrato con CDN)
    • Caching degli oggetti (su richiesta)
    • CDN

Applicabile:

  • Con Dev/Ops, si può andare in diretta con “Abilitazione del modulo passo per passo + Pressure Testing + Test di regressione”.
  • Necessità di caching di frammenti / varianti più complesse della strategia (ad es. caching a grana fine per dispositivo/regione/lingua)

4. Sito associativo / comunità / corsi online (molti accessi, forte personalizzazione)

Obiettivo: Rendere veloce il contenuto pubblico, assicurando al contempo che “il contenuto dell'utente loggato non venga strinato”.

4.1 Salvataggio, ma necessità di strategie di esclusione rigorose

  • WP Rocket
  • + (opzionale) cache degli oggetti (se le query dinamiche sono numerose)
    • CDN

Punti chiave:

  • È necessario escludere dalla cache le pagine “modificate dall'utente”: Centro personale, Ordini, Progressi, Messaggi, Carrello, ecc.
  • Questo tipo di sito è il più soggetto a “vedere contenuti altrui/permessi errati”, e i rischi dovrebbero essere esplicitati nella pagina.

4.2 Hosting LiteSpeed + Politica avanzata

  • LiteSpeed Cache (caching del server + strumenti di policy più sofisticati)
  • + caching degli oggetti (su richiesta)
    • CDN

Punti chiave:

  • I siti associativi tendono ad avere bisogno di una mentalità più “corpo memorizzabile nella cache + frammento non memorizzabile”.
  • Le strategie di riscaldamento e pulizia devono essere più raffinate, altrimenti “gli utenti vedono ancora i vecchi contenuti dopo l'aggiornamento” sarà molto frequente.

Web cache “Caso di sminamento”

Caso 1: Installato il plugin di caching, la velocità è quasi invariata

Fenomeno:

  • Velocità locale/co-regionale OK, all'estero (cross-continentale) ancora lenta
  • Il TTFB è migliorato, ma i tempi di caricamento complessivi non sono diminuiti in modo significativo.

Cause comuni:

  • Si effettua solo la cache della sorgente (TTFB), ma le risorse statiche (immagini/JS/CSS/font) vengono comunque caricate dalla sorgente attraverso i continenti.
  • Gli script di terze parti (annunci, chat, statistiche) rallentano il rendering e l'interazione
  • Download lenti a causa delle grandi dimensioni delle immagini (la cache non risolve il problema delle dimensioni del “primo download”)

Idea di soluzione:

  • Il plugin della cache si occupa innanzitutto del “sottoconteggio della fonte + hit”.”
  • Le risorse statiche vanno CDN
  • Ottimizzazione delle immagini
  • Gli script di terze parti eseguono strategie di ritardo/spaccatura

Lettura:

Caso 2: Dopo aver abilitato la cache, la pagina viene modificata ma il frontend non viene aggiornato.

Fenomeno:

  • Il contenuto/stile è stato aggiornato nel backend e la vecchia versione è ancora visualizzata nel frontend.
  • Oppure solo alcune regioni vengono aggiornate e altre rimangono invariate (comune per le stazioni globali).

Cause comuni:

  • La cache di pagina non è stata cancellata o è stata cancellata in modo errato
  • Il warm-up/crawler non funziona, la cache pulita si raffredda e la prima visita è lenta, mentre si pensa erroneamente che non ci sia alcun aggiornamento.
  • Se si abilita la cache dell'edge CDN, l'edge potrebbe anche conservare le vecchie risorse

Idea di soluzione:

  • Creare una “strategia di pulizia dopo il rilascio/revamping”: ripulire le pagine rilevanti, non una pulizia completa del sito.
  • Creare una strategia di riscaldamento per le pagine importanti (home page, pagine di destinazione principali) per evitare “pulizia = rallentamento”.”
  • CDN Strato per la pulizia dei bordi quando necessario

Caso 3: Contenuti fuori luogo dopo il passaggio da una lingua all'altra e da una valuta all'altra

Fenomeno:

  • La pagina mostra ancora la lingua precedente dopo il cambio di lingua
  • Oppure gli utenti di alcune regioni vedono una valuta sbagliata o un contenuto errato.

Cause comuni:

  • La cache non distingue tra le “dimensioni delle varianti” (cookie / parametri / prefissi linguistici / sottodomini).
  • Cache Hit dà i risultati della pagina di lingua A agli utenti di lingua B

Idea di soluzione:

  • Definire il programma multilingue: directory/sottodomini/parametri/cookie
  • Aggiunta di “politiche di variante” alle regole di caching o esclusione di pagine chiave
  • Alcuni siti richiedono idee di caching “slice and dice” più avanzate (W3TC è più adatto per il controllo ingegneristico).

Caso 4: Problemi con il carrello/checkout su un sito di e-commerce con la cache abilitata

Fenomeno:

  • Carrello con quantità errata, prezzo errato, pulsante di checkout non funzionante
  • Accedere e vedere contenuti che non appartengono all'utente (seriamente)

Cause comuni:

  • Le pagine critiche come Carrello/Checkout/Il mio account vengono memorizzate nella cache.
  • JS minify/merge causa incompatibilità tra pagamento e componente dinamico

Idea di soluzione:

  • WooCommerce è ufficiale: carrelli/checkout/conti non devono essere memorizzati nella cache e si raccomanda di evitare la compressione dei file JS.
  • Eseguire prima “page cache + exclude”, poi considerare l'ottimizzazione del front-end
  • Se si utilizza WP Super Cache, WooCommerce indica che è compatibile in modo nativo ed evita la memorizzazione nella cache delle pagine principali per impostazione predefinita.

Caso 5: Menu/form/popup interrotti dopo aver abilitato “Ritarda JS/Fusione script”.

Fenomeno:

  • Il menu di navigazione non si apre
  • La convalida del modulo non è riuscita o non è stato possibile inviarlo
  • Eccezione Popup/Rollup
  • Le statistiche/gli eventi di conversione non si attivano (il problema più grande per i siti in fase di lancio)

Cause comuni:

  • Deferred JS modifica la tempistica di esecuzione degli script: gli script non vengono eseguiti fino a quando l'utente non interagisce con essi e alcuni componenti si basano su “inizializzazione al caricamento della pagina”.”
  • La fusione/compressione può modificare l'ordine degli script o interrompere le dipendenze.

WP Rocket descrive ufficialmente l“”esecuzione differita di JS" come una delle sue ottimizzazioni JS più forti: gli script vengono differiti fino a dopo l'interazione con l'utente per dare priorità al rendering della pagina. Si tratta di un'ottima funzionalità, ma comporta anche un maggiore rischio di compatibilità.

Idea di soluzione:

  • Abilitare per gradi: cache, poi immagini, poi CSS, poi JS.
  • Aggiungere esclusioni agli script principali (pagamenti, moduli, menu, tracciamento)
  • Eseguire una lista di controllo dei test di regressione per ogni cambiamento

Caso 6: Solo LiteSpeed Cache è installato, ma non sembra funzionare.

Fenomeno:

  • LiteSpeed Cache è attivo, ma il TTFB non scende molto.
  • I risultati non sono ovvi

Cause comuni:

  • Il vostro server non è LiteSpeed/OpenLiteSpeed e non può utilizzare le funzionalità principali di LSCache.
  • O forse sono state attivate alcune ottimizzazioni, ma la “politica di caching della pagina/preheat/exclude” non è stata creata!

Idea di soluzione:

  • Controllare innanzitutto lo stack dell'host: è LiteSpeed/OpenLiteSpeed (è un prerequisito).
  • Riportare l'attenzione su “Page Cache Policy + Warm Up + Exclude + Clean Up”.”
  • Se non si tratta di un host LiteSpeed: considerare WP Rocket o WP Super Cache.