Tīmekļa vietnes kešatmiņas optimizācija

Vietnes “lēnuma” galvenais iemesls parasti nav konkrēts attēls, bet ganPieprasījuma saite + servera ģenerēšana + statiskā resursu sadalesuperimpozīcijas dēļ:

• Lietotāji ir pārāk tālu no jūsu serveriem, tīkla RTT ir liels (vairāk jūtams starp kontinentiem).
• WordPress palaiž PHP, pārbauda datubāzi un katram pieprasījumam atveido veidni → TTFB (laiks līdz pirmajam baitetam) līdz
• Lapas ielādē arī JS/CSS/fonus/trešo pušu skriptus, tādējādi palēninot atveidošanu un mijiedarbību.

Kešatmiņas spraudnisRisinājuma būtība ir saglabāt “divreiz uzskaitīto” lapu rezultātus, lai serverim tos nevajadzētu katru reizi pārrēķināt, un ievērojami samazināt TTFB, ļaujot vairāk lietotājiem izmantot kešatmiņu, ja tiek izmantota pareiza stratēģija.WordPress oficiālā dokumentācijaTika arī norādīts, ka tādi spraudņi kā W3 Total Cache un WP Super Cache var kešēt lapas kā statiskus failus un pēc tam tos pasniegt tieši lietotājam, tādējādi samazinot servera apstrādes slodzi.

Pirms lasāt šo lapu, atcerieties 3 stingrus noteikumus.

1. Lapas kešatmiņas spraudņi vienlaicīgi tikai viens

Visbiežāk vairāku kešēšanas spraudņu vienlaicīgas aktivizēšanas rezultāts nav ātrāks:

• Savstarpēja kešatmiņas noteikumu pārrakstīšana, savstarpēja kešatmiņas dzēšana, kešatmiņas trāpījumu skaita samazināšanās.
• Dinamiskais saturs, piemēram, pieteikšanās valsts/valoda/karte/cena, tiek ievietots kešatmiņā, kā rezultātā notiek “nepareiza satura” incidenti.
  Daudzos spraudņu dokumentācijas/instrukciju norādījumos būs ierosināts, ka, izmantojot noteiktu kešatmiņas spraudni.Atslēgt citus kešēšanas spraudņuslai izvairītos no konfliktiem.

2. E-komercijas/dalības/daudzvalodu vietnes: kešēšana nav “ieslēgšanas/izslēgšanas slēdzis”, tā ir “noteikumu sistēma”.”

WooCommerce Oficiālā veiktspējas dokumentācijaSkaidrs atgādinājums: kešatmiņas spraudnis, lai pārliecinātos, ka Iepirkumu grozs / Kase / Konts Ieteicams arī izvairīties no JavaScript faila saspiešanas (jo tā parasti rada savietojamības problēmas).

3. “Cache plug-in ≠ CDN”, bet kešatmiņas spraudnis ir CDN pamats.

Kešatmiņas spraudnis, lai atrisinātu “avota stacijas nepietiekamas uzskaites” problēmu;CDN Risiniet problēmu “saturs tuvāk lietotājiem”. Attiecības starp abiem tiek pārklātas: vispirms tiek nospiests avota TTFB, un pēc tam statiskie resursi tiek nodoti CDN izplatīšanai, kas ir visstabilākais maršruts globālajiem lietotājiem.

Ātrā izvēle: 4 visbiežāk sastopamie vietņu scenāriji

Ja nevēlaties lasīt visu rakstu, varat izvēlēties šādus 4 variantus:

1. Vēlaties ietaupīt naudu, būt stabils un pielāgots globālai piekļuvei. → WP Rocket(Apmaksāts)
2. Hostings ir skaidri LiteSpeed/OpenLiteSpeed → LiteSpeed kešatmiņa(bezmaksas, bet ļoti atkarīgs no servera jaudas): Kešatmiņas funkcijai nepieciešama LiteSpeed servera komponentistrādāt tikai tad
3. Satura vietnes/blogi/dokumentu vietnes, kas vēlas būt brīvas un stabilas. → WP Super Cache(statiskā HTML kešatmiņa): Ģenerēt statiskus HTML failus, lai tos sniegtu lielākajai daļai nepieslēgtu lietotāju.
4. Jums ir tehniskās komandas, kas var veikt precīzu vadības regulēšanu (CDN/objektu kešēšana/multi-moduļi). → W3 Total Cache(spēcīgs, bet sarežģīts): Uztur visaptverošu veiktspējas sistēmu ar CDN integrāciju.

Ko tieši kešatmiņa saglabā kešatmiņā?

“Kāpēc dažas vietnes joprojām ir lēnas ar kešatmiņu”, mēs sadalījām WordPress veiktspēju 5 slāņos:

1. pārlūkprogrammas kešatmiņa: Sekundārās piekļuves paātrināšana lietotājiem (statiskās resursu kešatmiņas galvenes, versiju numuri).
2. lapas kešatmiņa: Kešatmiņas lapas izvade kā HTML (šīs lapas galvenais raksturs)
3. objektu kešatmiņa: Datu bāžu vaicājumu rezultātu objektu kešatmiņa (dinamiskās stacijas ir vērtīgākas)
4. PHP OPcache: Kešatmiņa PHP baitkods (parasti konfigurē serveris, nevis spraudnis)
5. CDN/malas kešatmiņa: Resursu izvietošana lietotājam tuvāk esošos mezglos

Šī raksta fokuss: lapas kešēšanas spraudnis;
Taču jums nepārtraukti tiek atgādināts, ka vietnēm bieži vien ir nepieciešama kombinācija 2 + 5, lai tās būtu “patiešām ātras”.

1 spraudnis:WP Rocket(Maksas) - integrētas programmas “prāta glābšanai”

WP Rocket ir populārs “WordPress” ainā ne tāpēc, ka tas ir maģisks, bet tāpēc, ka tas padara trīs visbiežāk sastopamos veiktspējas darbu veidus “pārvaldāmās pakās”:

• Lapas kešēšana (samazina avota vietnes TTFB)
• kešatmiņas iepriekšēja ielādēšana/atkarsēšana (lai uzlabotu pirmā apmeklējuma pieredzi ar globāli sadalītu piekļuvi).
• Galvenās front-end optimizācijas (jo īpaši JS latentums, CSS apstrāde u. c.).

tāsoficiāls dokumentsTajā ir arī skaidri norādīts, ka, ieslēdzot iepriekšēju ielādēšanu, var tikt iedarbinātas/veicinātas noteiktas optimizācijas (piemēram, ar CSS/JS saistītas optimizācijas) pat tad, ja ir izslēgta lapas kešēšana.

1.1 Kam ir paredzēta WP Rocket

WP Rocket ir īpaši piemērots šīm stacijām:

• Korporatīvā vietne, zīmola vietne, satura mārketinga vietne, mērķlapa (datplūsma no vairākām valstīm un reģioniem)
• Es gribu “iet dzīvot ātri, stabilitāte vispirms”, nevēlos uzrakstīt daudz bezmaksas spraudnis kombinācija
• Nav specializētu operētājsistēmas/izpildes inženieru, bet ir pieredze un SEO prasības.
• WooCommerce To var arī izmantot, bet ar lielāku piesardzību (par to vairāk šajā sadaļā).Noteikumi un riski）

1.2 Tās galvenā vērtība tīmekļa piekļuves scenārijos (ne tikai kešatmiņas pārslēgšanas funkcija).

A. Kešatmiņas iepriekšēja ielāde: “nestabilu pirmo apmeklējumu problēmu risināšana, ko izraisa sadalīta piekļuve tīmekļa vietnēm”.”

Ja vietnes lietotāji ir izkliedēti, jūs pieredzēsiet ļoti tipisku palēnināšanos:
Lietotājs reģionā atver lapu pirmo reizi, un gadās, ka tā ir izdzēsta no kešatmiņas vai nekad nav uzsildīta → šis lietotājs sedz pilnas PHP/DB atveidošanas izmaksas.
Priekšslodzes mehānismsTas ir svarīgi:“pirmās paaudzes” izmaksu segšana avansāProgrammas pirmais apmeklējums būs “jūrascūciņa”, tādējādi samazinot "pirmā apmeklējuma kā jūrascūciņas" iespējamību.

• Nav iepriekšējas ielādes: kurš pirmais piekļūst, cieš
• Ar iepriekšēju ielādi: sistēma fonā vienoti ģenerē kešatmiņu, pirmā apmeklējuma pieredze ir stabilāka.

B. Atliktā JavaScript izpilde: visvienkāršākā funkcija, kas ļauj “justies nekavējoties” vietnes apmeklējuma laikā, bet arī visriskantākā.

WP Rocket oficiāli liek “Aizkavēta JS izpilde” to raksturo kā spēcīgāko JS optimizāciju: tā atliks skripta izpildi līdz brīdim, kad lietotājs būs veicis mijiedarbību (pārvietojis peli, pieskāries ekrānam, ritinājis, nospiedis taustiņu utt.), lai piešķirtu prioritāti lapas atveidošanai.

Tas ir svarīgi tīmekļa vietņu piekļuvei, jo skriptu ielādēšanas un izpildes bloķēšana var pastiprināties starpkontinentālajos tīklos:

• Lēnāka resursu lejupielāde → galvenais pavediens biežāk tiek aizkavēts ar skriptiem.
• Trešo pušu skripti (statistika, reklāmas, tērzēšanas spraudņi) biežāk pasliktina INP/interakcijas kavēšanos.

Taču tas var arī radīt problēmas:

• Aizkavēts JS var ietekmēt: izvēlnes, rotācijas, uznirstošos logus, veidlapu validāciju, maksājumus, apbedījumu izsekošanu.
• Tāpēc tā ir piemērota stratēģijai “soli pa solim + izslēgšana no melnā saraksta”.

C. Savietojamība ar citiem spraudņiem/tēmām: “nulles konflikts” nav tas pats, kas "miers".”

WP Rocket ir oficiāli uzskaitīti “Nesaderīgi spraudņi/tēmas” sarakstā, tādu iemeslu dēļ, kas ietver tādus mehānismus kā izvades buferēšana, kas ietekmētu WP Rocket kešēšanu/optimizāciju.

• Ja jūsu vietnei ir ļoti daudz spraudņu un tēmu, domājiet par “veiktspējas optimizāciju” kā par mini projektu, kas paredzēts, lai sāktu darbību: regresijas testēšana katrai izmaiņai (veidlapām, pieteikumiem, maksājumiem, vairāku valodu pārslēgšanai utt.).

1.3 Īpašs atgādinājums WooCommerce/dinamiskajai vietnei

Galvenais atgādinājums no oficiālās WooCommerce dokumentācijas, konfigurējot kešēšanas spraudni, ir:

• Iepirkumu grozs / Kase / Konts Nelietojiet kešatmiņu
• turklāt ir ieteicams.Izvairīšanās no JS failu saspiešanas

Kāpēc? Šādu iemeslu dēļ:

• Spēcīga atkarība no groza, izrakstīšanās, konta lapas cookie / sesija / nonce
• Tiklīdz kešatmiņā šīs lapas tiks uzskatītas par “statiskām lapām”, pogas nedarbosies, un cenu/inventāra/konta informācija tiks izjaukta.
• Lūk, baisākā daļa: vienā reģionā testēšana var noritēt labi, bet citā var rasties problēmas CDN/ kešatmiņas trāpījumu neatbilstību dēļ!

1.4 Kešatmiņas spraudņa stratēģijas līmeņa ieteikumi

第 1 层：基础安全收益（几乎所有站都该做）

• Iespējot lapas kešēšanu
• atverPriekšpiegāde kešatmiņā(Pirmā apmeklējuma stabilitātes uzlabošana)
• Saprātīga pārlūkprogrammas kešatmiņas politika (WP Rocket/Server/CDN Var īstenot jebkuru no slāņiem).

第 2 层：中等收益，中等风险（适合大多数内容站）

• Aizkavēta attēlu ielāde/iframe (attēlu optimizācijas lapa turpinās)
• CSS apjoma kontrole (piemēram, neizmantotā CSS noņemšana).

第 3 层：高收益但高风险（必须有回归测试清单）

• Kavēta JavaScript izpilde (prioritāte ir atveidošana, bet tas var ietekmēt mijiedarbību).
• JS/CSS saspiešana/salipināšana: esiet īpaši uzmanīgi ar e-komerciju/dalībniekiem/daudzvalodīgajiem (WooCommerce arī brīdina par JS saspiešanas risku）

1.5 Cenas un atļaujas

• WP Rocket ir maksas licence ar dažādām licencēm atkarībā no vietņu skaita.

Spraudnis 2:LiteSpeed kešatmiņa (LSCWP)--Bezmaksas topi“ priekšnoteikums ir tāds, ka serveris patiešām ir LiteSpeed.

Daudziem cilvēkiem ir nepareizs priekšstats par LiteSpeed Cache: viņi domā, ka tas ir tikai WordPress spraudnis, kuru var instalēt un iegūt visu jaudu jebkurā mitinātājā, tāpat kā WP Rocket. Tas tā nav.

LiteSpeed oficiālā dokumentācijaSkaidrs paskaidrojums: LSCWP kešēšanas funkcijai ir nepieciešams LiteSpeed Server, jo tā sazinās ar LiteSpeed Web Server iebūvēto lapu kešatmiņu (LSCache); spraudnis ir atbildīgs par to, lai serverim norādītu, kuras lapas ir kešējamas un cik ilgi, kā arī par tīrīšanas aktivizēšanu ar tagiem.

LiteSpeed kešatmiņas galvenā priekšrocība ir “Servera līmeņa lapu kešatmiņa (LSCache)”. Bez LiteSpeed/OpenLiteSpeed serveriem šādas priekšrocības nav.

2.1 LiteSpeed kešatmiņakam

Piemērots:

• Jūsu hostinga panelis ir skaidri marķēts LiteSpeed / OpenLiteSpeed(piemēram, daudzi cPanel saimnieki rakstīs)
• Jūs vēlaties “bezmaksas risinājumu, kas var palaist arī spēcīgu TTFB un vienlaicīgumu.”
• Jūs esat gatavi pieņemt: tas ir ļoti spēcīgs, bet arī vairāk konceptuāls (TTL, Tag, Purge, ESI, Crawler...)

Ne gluži tā:

• Jūs neesat pārliecināts, kāds ir tīmekļa serveris, vai apstiprināt, ka tas ir Nginx/Apache (ja vien nevēlaties izmantot tikai dažas no tā front-end optimizācijas funkcijām, bet tad cena/ veiktspēja un sarežģītība ne vienmēr ir rentabla).
• Jums ir sarežģīta e-komercijas/dalības/daudzvalodu vietne, bet nav testēšanas procesa (LSCWP ir spēcīgs, bet ir arī vieglāk “kešēt nepareizu saturu”).

2.2 Kešēšanas mehānisms: kāpēc tas drīzāk ir “daļa no servera jaudas”.”

LiteSpeed kešatmiņas mehāniku varētu uzrakstīt kā “inženiertehnisku skaidrojumu”:

• WP Rocket / WP Super Cache Tas vairāk attiecas uz WordPress/PHP kešatmiņas un optimizācijas pusi;
• LSCWP Tā ir WordPress vadības paneļa + LiteSpeed Server iebūvētā LSCache kombinācija: spraudnis ir atbildīgs par noteikumu un tīrīšanas signālu izdošanu, un reālā ātrgaitas lapu kešēšana notiek serverī.servera slānis。

Tam ir tieša ietekme uz tīmekļa vietnes lietošanas pieredzi: servera līmeņa izspiešanas kešatmiņa parasti ir vieglāka, ātrāka un vienlaicīgāka (jo īpaši, ja ir liela datplūsma un biežāki apmeklējumi no meklētājprogrammu pārlūkiem).

2.3 “Pareizais veids”, kā atvērt LSCWP tīmekļa vietnes lietotāja scenārijiem”

Mēs esam sadalījuši “pareizo atvēršanas veidu” 4 līmeņos:

1. slānis: lapas kešatmiņas politika (nosaka, vai TTFB patiešām var samazināties).

• Precizēt, kuras lapas var būt kešatmiņā (lielākā daļa publiskā satura lapu).
• Noskaidrojiet, kuras lapas nekad nedrīkst būt kešatmiņā (pieteikšanās, konts, iepirkumu grozs, izrakstīšanās, valodas/valūtas pārslēgšanas lapas, kas balstās uz spēcīgu cookie).
• Iestatiet saprātīgu TTL kešatmiņai (jo biežāk saturs tiek atjaunināts, jo īsāks TTL, un jo garāks TTL).
• Izveidojiet tīrīšanas stratēģiju: pēc satura atjaunināšanas iztīriet attiecīgo birku (nevis veiciet tīrīšanu ar brutālu spēku visā vietnē).

Ja šis slānis ir pareizi izveidots, tas ir vistiešāk redzams tīmekļa vietnē kā TTFB uz leju, pirmais ekrāns stabilāks。

2. slānis: Warm-up/Crawler (nosaka “lēnu pirmo aukstās lapas apmeklējumu”).

Bieži sastopama “pieredzes nekonsekvence” tīmekļa vietnes piekļuvē, ko rada “karstās un aukstās atšķirības” kešatmiņā:

• Populārās lapas vienmēr tiek apmeklētas un kešatmiņa vienmēr ir karsta.
• Uz aukstajām lapām nav klikšķināts ilgu laiku, un pirmo reizi klikšķinātāji klikšķina lēni.

Uzsildīšana nav glazūra uz tortes, tā ir atslēga uz konsekventu vietnes apmeklētāju pieredzi.

3. līmenis: drošības programmas dinamiskam saturam (e-komercija/dalība/daudzvalodība).

LSCWP jauda ir tā, ka tas sniedz jums daudz “uzlabotu rīku”, piemēram:

• Diferencētas kešēšanas stratēģijas pieteiktiem lietotājiem, komentāru lietotājiem u. c.
• Edge Side Inclusion (ESI) pamatideja ir sadalīt lapu "kešējamā publiskajā korpusā" un "kešēšanai nepieejamos dinamiskajos fragmentos", kas tiek apstrādāti atsevišķi un pēc tam sajaukti malas mezglos.

4. līmenis: tiešsaistes pakalpojumi un papildu uzlabojumi

Daudziem tīmekļa vietņu administratoriem LSCWP būs noderīgi QUIC.cloud tiešsaistes pakalpojumi (piemēram, lappušu optimizācijas tipa pakalpojumi).QUIC.cloud dokumentācijaIr skaidri norādīts, ka tā sniedz LSCWP lappušu optimizācijas pakalpojumus, tostarp Critical CSS (CCSS), Unique CSS (UCSS), Viewport Images (VPI) un citus.

• Šis pakalpojuma veids nav obligāts: varat vienkārši izmantot servera kešatmiņu un neieslēgt optimizāciju tiešsaistē.
• Kad tiešsaistes pakalpojumi ir iespējoti, mainīsies jūsu vietnes resursu/lapu apstrādes saites (šī ir svarīga informācija uzņēmumiem/privātumam jutīgiem klientiem).

2.4 LSKP kopīgā bedre

1. Serveris nav LiteSpeed, bet izmanto LSCWP kā pilnvērtīgu kešatmiņas spraudni.
   Rezultāts: kešēšana nav tik efektīva, kā gaidīts, un arī palielina konfigurācijas sarežģītību. Risinājums: Vispirms apstipriniet saimnieka kaudzes; ja tā nav. LiteSpeedPiemēram, aplūkojiet WP Rocket vai WP Super Cache.
2. Pārāk daudzu front-end optimizāciju aktivizēšana rada funkcionālas anomālijas.
   Lapas optimizācija (CSS/JS) bieži vien biežāk izraisa savietojamības problēmas nekā pati kešēšana. Ieteikums: vispirms palaidiet lapas kešatmiņu, pēc tam ieslēdziet optimizācijas vienu pēc otras un izveidojiet regresijas testu sarakstu (veidlapas, izvēlnes, maksājumi, izsekošana, valodas pārslēgšana utt.).
3. Dinamisko lapu izslēgšanas/šķelšanas stratēģiju trūkums
   Tipiski incidenti: iepirkumu grozs, izrakstīšanās, konta lapa ir kešatmiņā; vai nepareiza vairāku valodu/valūtu pārslēgšana. E-komercijas vietnēm tas ir jāņem vērā kā pirmspārbaude (un WooCommerce pārstāvji arī uzsver).Galvenās lappuses nav kešatmiņā）。

Spraudnis 3:WP Super Cache(Bezmaksas) - klasisks “zema riska un augsta ienesīguma” risinājums satura vietnēm.

WP Super Cache Kāpēc tā ir tik ilgi bijusi populāra? Tāpēc, ka tā risina problēmas ļoti tiešā un serverim draudzīgā veidā:
Statisku HTML failu ģenerēšana no dinamiskām WordPress lapāmPēc tam HTML faili tiek apkalpoti tieši no tīmekļa servera, apejot dārgo PHP apstrādi.

Arī spraudņa lapā ir minēts, ka: statiskais HTML tiks pasniegts lielākajai daļai nepierakstīto lietotāju, un ir sniegts ļoti intuitīvs paziņojums - “99% apmeklētājiem tiks pasniegti statiskie HTML faili”, un var tikt pasniegts viens kešatmiņas fails. tūkstošiem reižu.

3.1 Kam ir paredzēta WP Super Cache?

Ļoti ieteicams:

• Blogi, plašsaziņas līdzekļu satura vietnes, dokumentu vietnes, uzņēmumu prezentācijas vietnes, mērķlapu lapas
• Apmeklētāji galvenokārt ir nepierakstījušies lietotāji
• Vēlaties: bezmaksas, stabilu, ar zemām uzturēšanas izmaksām.

Piesardzība/nepieciešamas stingrākas stratēģijas:

• Ļoti dinamiska vietne: daudz personalizēta satura, lapas, kas mainās atkarībā no lietotāja stāvokļa.
• Liela e-komercija: tas var darboties, bet pārliecinieties, ka galvenās lapas nav kešētas un darbojas kopā ar testēšanas procesu.

3.2 Trīs kešatmiņas metodes:

WP Super Cache spraudņa aprakstā ir uzskaitītas 3 kešēšanas metodes pēc ātruma un paskaidrotas atšķirības:

• mod_rewrite (eksperts): ātrākais, pilnīgi apejot PHP, bet ir nepieciešams mainīt .htaccess, nepareiza konfigurācija var izraisīt vietnes nepieejamības risks ir lielāks!
• Vienkārša (ieteicamā pieeja): PHP nodrošinātie “Super cached” statiskie faili, kas ir tuvu mod_rewrite ātrumam, bet vieglāk konfigurējami.
• WP-Cache kešatmiņa: elastīgāks zināmiem lietotājiem, URL ar parametriem, abonēšanas plūsmām utt., bet lēnāks.

Ieteicamā izvēle:

• Iesācēji/seeking stability: izmantojiet ieteicamo metodi (vienkārša)
• Jūs esat iepazinies ar servera noteikumiem un esat gatavs uzņemties risku tos pārrakstīt: vēlreiz apsveriet ekspertu modeli!
• Nepieciešama elastīgāka “Zināma lietotāja/ar parametriem” apstrāde: WP-Cache pozīcijas izpratne

3.3 WP Super Cache stiprās un vājās puses

Priekšrocības:

1. Ideāli piemērots lietošanai kopā ar CDN.
   Tā kā tas būtībā ir “statiskā HTML ģenerēšana”, tas dabiski atbilst CDN/malas kešatmiņas idejai.
2. Avota stacijas CPU/datubāzes spiediena uzlabojumi ir ļoti vienkārši.
   Ja vietnes datplūsma ir izkliedēta, meklētājprogrammas un sociālo mediju pārlūki var nākt no visas pasaules. Statizācija ir efektīva cīņā pret “atkārtotu atveidošanu”.

Īsais dēlis:

1. Tas nav “viss vienā veiktspējas optimizācijas komplektā”.”
   Tas galvenokārt ir spēcīgs lapas kešēšanā, un dziļa CSS/JS optimizācija nav tik liela kā WP Rocket. Iespējams, jums būs nepieciešams uzņemties vairāk “Attēlu optimizācijas lapā” un “Frontend optimizācijas lapā” (vai izmantot citas spraudņa/temas līmeņa optimizācijas).
2. Piesardzīgāk izturieties pret “dinamisko personalizāciju”
   Piemēram, dažāda satura rādīšana atkarībā no reģiona, dažādu cenu/valodu/ieteikumu rādīšana atkarībā no lietotāja statusa utt. Šajā brīdī jums ir vai nu jāizveido izslēgšanas politika, vai jāievieš piemērotāka "slice-and-dice" kešēšanas shēma.

3.4 WooCommerce savietojamība: kāpēc tā ir “drošāka”

Oficiālā WooCommerce palīdzībaPieminēts: WooCommerce ir saderīgs ar WP Super Cache, un WooCommerce nosūta ziņojumu WP Super Cache, lai pēc noklusējuma netiktu kešētas Grozs, Izrakstīšanās, Mans konts lapas.

• Pat ja esat jauns WP Super Cache + WooCommerce lietotājs, ir daudz mazāk ticams, ka jūs uzkāpsiet uz “galveno kešēto lapu” mīnas!
• Tomēr pirms darbības uzsākšanas joprojām ir ieteicams veikt regresijas testēšanu (maksājumi, kuponi, piegāde, nodokļu likmes, vairākas valūtas u. c.).

Spraudnis 4:W3 Total Cache (W3TC)--Visdaudzpusīgākā “veiktspējas sistēma” inženieru komandām.

W3 Total Cache WordPress.org ir nevis “vienas kešatmiņas spraudnis”, bet drīzāk “tīmekļa vietnes veiktspējas optimizācijas sistēma”: tajā uzsvars tiek likts uz SEO, Core Web Vitals un vispārējās pieredzes uzlabošanu, izmantojot CDN integrāciju un labāko praksi. Vitālie rādītāji un vispārējā pieredze, izmantojot CDN integrāciju un labāko praksi.

Spraudņa aprakstā ir uzskaitītas dažādas iespējas: lapas/posteņa kešēšana, CSS/JS kešēšana, Feed kešēšana, meklēšanas rezultātu kešēšana, datubāzes objektu kešēšana, objektu kešēšana, fragmentu kešēšana (fragmentu kešatmiņa) un atbalsts dažādām kešēšanas metodēm, piemēram, Redis/Memcached/APC, bet ir iekļauta arī mobilo grupu kešēšana pēc UA/Referrer, AMP atbalsts, reversā starpniekservera (Nginx/Varnish) integrācija u. c.

4.1 Kam paredzēts W3 Total Cache?

Ideāli piemērots:

• Jums ir izstrādes/ekspluatācijas prasmes, un jūs esat gatavs veikt “iespējošanu + spiediena testēšanu + regresijas testēšanu”.”
• Jūsu vietne ir sarežģīta: vairāku valodu, vairāku tēmu pārslēgšana, mobilā diferenciācija, sarežģīta satura struktūra.
• Jums ir nepieciešama ne tikai lapu kešēšana, bet arī objektu kešēšana/fragmentu kešēšana sistēmā (īpaši dinamiskām vietnēm).

Tas neatbilst:

• Jūs vēlaties “instalēt un izmantot”, nevēlaties izprast kešatmiņas hierarhiju.
• Jums nav testēšanas procesa, bet jūs vēlaties ar vienu piegājienu ieslēgt tādus augsta riska elementus kā saspiešana un aizkavēti skripti.

4.2 Kāpēc tas ir “spēcīgs, bet sarežģīts”: tīmekļa vietnes vērtē “kontrolējamību”.”

W3TC vērtība nav tā, ka “tam jābūt ātrākajam par visiem pārējiem”, bet gan tā, ka tas sniedz pietiekami daudz vadības pogu, lai izstrādātu veiktspējas stratēģiju:

• Lapas kešatmiņa: var būt atmiņā, diskā vai CDN.
• Datubāzes objektu kešatmiņa, objektu kešatmiņa: pieejams Redis/Memcached utt.
• Fragmentu kešēšana: noderīga “daļēji dinamiskām lapām”
• Mobilo ierīču atbalsts: lapu kešēšana attiecīgi pēc novirzītāja vai lietotāja aģenta grupas.
• CDN pārvaldība: Pārredzama CDN multivides bibliotēku, tēmu failu u. c. pārvaldība.

Šīs iespējas ir īpaši vērtīgas tīmekļa vietnēm, kurās bieži sastopama globāla piekļuve:

• Vienas un tās pašas lapas varianti dažādās ierīcēs, dažādos reģionos, dažādās valodās.
• Daļu satura var ievietot kešatmiņā, daļai satura jābūt reālā laikā (piemēram, cena, krājumi, lietotāja statuss).

4.3. W3TC “Ieteicamais veicināšanas rīkojums”

Ieteicamais pasūtījums:

1. Sāciet, ieslēdzot tikai lapas kešēšanu
   Pārbaudiet: TTFB ir izslēgts, saturs ir konsekvents, pieteikšanās valsts/multilingvālā/elektroniskās komercijas galvenie procesi darbojas.
2. Pārlūka kešatmiņas atkārtota aktivizēšana
   Mērķis: padarīt ātrāku atkārtotu apmeklējumu un statisko resursu ielādi un samazināt atkārtotu lejupielāžu skaitu dažādos kontinentos.
3. Objektu kešatmiņas / datubāzes objektu kešatmiņas pārvērtēšana
   Piemērojams: dinamiska vietne (WooCommerce, dalības sistēma, sarežģīti vaicājumi).
   N/A: tikai satura stacijas var dot ierobežotu atdevi vai pat palielināt resursu patēriņu.
4. Galīgais pieskāriens Kompresija / Aizkavēšanās skriptēšana / Front End optimizācija
   Tā kā šajā slānī visdrīzāk var rasties funkcionālas anomālijas, ir jāizveido regresijas testu saraksts (maksājumi, veidlapas, iznirstošie logi, izvēlnes, valodas pārslēgšana u. c.).

WooCommerce atgādinājums par “Cache spraudņa konfigurāciju”: Kritiskās lapas netiek kešētas, un ir ieteicams izvairīties no JS faila saspiešanas.

Četru spraudņu salīdzināšanas matrica

Piezīme: runa nav par to, “kurš ir labāks”, bet gan par to, “kurš labāk atbilst jūsu scenārijam”.

dimensija (matemātika)	WP Rocket	LiteSpeed kešatmiņa	WP Super Cache	W3 Total Cache
pamatpozicionēšana	Ērta integrācija (kešēšana + optimizācija)	Servera līmeņa kešatmiņa (izmanto LSCache)	Statiskā HTML kešēšana	Veiktspējas sistēma (vairāki kešatmiņas slāņi + CDN)
no uzņēmējas puses atkarīga	Zems (universāls)	Augsts (nepieciešama LiteSpeed/OpenLiteSpeed, lai darbotos kā galvenā kešatmiņa)	Zems (universāls)	Vidēja (universāla, bet vairāk atkarīga no vides/konfigurējamības)
Mācību izmaksas	zems un vidējs	Vidēji	nolaist (galvu)	Augsts
Satura stacijas ieteikums	Ļoti augsts	Ļoti augsts (ar nosacījumu, ka tas ir izpildīts)	Ļoti augsts	Vidēji augsts - augsts (atkarībā no komandas)
E-komercijas/dalības vietne	Pieejams, bet izslēdziet ar piesardzību (WooCommerce galvenās lapas netiek kešētas).	Pieejams, bet vairāk nepieciešams izstrādāt noteikumus/dalīšanas stratēģijas.	ir pieejams, un WooCommerce norāda uz vietējo saderību un to, ka pēc noklusējuma netiek veikta galveno lapu kešēšana.	Pieejams un piemērots inženierijas kontrolei
budžets	segt izmaksas	bezmaksas programmatūra	bezmaksas programmatūra	Bezmaksas + maksas versija

“Kešatmiņas incidenti” un profilakses kontrolsaraksts

1. Trīs galvenie “nepareiza satura” cēloņi kešatmiņas dēļ

A. Attieksme pret “statusful” lapām kā pret “bezstāvokļa statiskajām lapām”.”

Raksturīgi: konta lapa, iepirkumu grozs, izrakstīšanās lapa tiek kešētas.WooCommerce Amatpersonas ir vairākkārt uzsvērušas Grozs/Rēķins/Akonts nedrīkst būt kešatmiņā.

B. Vairāku valodu/valūtu/reģionālie varianti netiek pareizi kešēti.

Ja jūsu vietnē tiek rādīts atšķirīgs saturs, pamatojoties uz cookie, vaicājuma parametriem un ģeogrāfisko atrašanās vietu, tad kešatmiņā ir jāņem vērā “variantu izmēri”. Pretējā gadījumā kešatmiņu, ko izveidojuši lietotāji reģionā A, var atkārtoti izmantot lietotāji reģionā B.

C. Front-end optimizācijas (JS/CSS) pārrakstīšana, kas rada funkcionālas anomālijas.

Jo īpaši JS saspiešana, apvienošana un izpildes atlikšana.Izvairīšanās no JS failu saspiešanas。

2. Kontrolsaraksts pirms palaišanas regresijas testēšanas

• Pieteikšanās/izrakstīšanās ir normāla
• Veidlapu iesniegšana (kontaktu forma, abonēšana, pieteikšanās reģistrācija) darbojas pareizi
• E-komercijas process: pievienot pirkumu → kupons → piegāde/nodokļi → maksājums → pasūtījuma lapa
• Daudzvalodu pārslēgšanas stabilitāte (saturs, URL, hreflang, valūta pēc pārslēgšanas)
• Mobilās izvēlnes, uznirstošie logi, ritināšana, slinkā ielāde darbojas pareizi.
• Izsekojiet, vai skripti joprojām tiek iedarbināti (GA, Meta Pixel, transformācijas notikumi).

bieži sastopamās problēmas

Q1：Kāpēc piekļuve ārzemēm joprojām ir lēna, lai gan es esmu instalējis kešēšanas spraudni?

Visbiežākais iemesls ir tas, ka esat atrisinājis tikai “dublējošās atveidošanas problēmu avotā”, bet ne “starpkontinentālā tīkla latentuma problēmu”.
Kešēšanas spraudņi ļauj serverim ātrāk izplūkt saturu (TTFB lejup), bet statiskie resursi (attēli, CSS, JS, fonti) un RTT globālām saitēm joprojām ir jāizmanto. CDN lai saīsinātu attālumu.
👉 Tātad pareizais ceļš ir:Vispirms nodrošiniet avota stacijas kešatmiņas stabilitāti.Un pēc tam CDN globālai izplatīšanai.。

2. jautājums: Kāpēc saturs neatjauninās pēc tam, kad to mainīju pēc kešēšanas?

Jo jūs redzat “veco kešatmiņu”. Risinājuma ideja:

• Izveidojiet tīrīšanas stratēģiju: pēc rakstu/lapu atjaunināšanas iztīriet atbilstošo kešatmiņu (nevis vietnes mēroga tīrīšanu).
• Scenārijiem ar iesildīšanos/skrējējiem: sakopiet un tad iesildieties, pretējā gadījumā pirmais apmeklējums būs lēns.
• Attiecībā uz CDN: jāņem vērā, ka CDN malas var būt arī veco resursu kešatmiņa.

3. jautājums: Vai es varu instalēt WP Rocket + WP Super Cache vienlaicīgi?

Nav ieteicams. Viens lapas kešēšanas spraudnis vienlaicīgi ir visstabilākais. Jūs varat saprast ideju “viens kešēšanai un viens optimizācijai” kā “darba dalīšanu”, taču realitātē tie bieži vien skar lapu kešēšanu/resursu pārrakstīšanu, un konfliktu iespējamība ir liela. Ieteicamāk ir izvēlēties “galveno kešēšanas spraudni”, citas vajadzības ar skaidrāku vienu rīku aizpildīt.

4. jautājums: Vai e-komercijas vietnēm nav bīstami izmantot kešēšanu?

Tas nav bīstami, bīstami ir “nav noteikumu”.WooCommerce ieteikumiĻoti skaidrs: grozs / kase / konts netiek kešēts un tiek novērsta JS saspiešana.
Turklāt WooCommerce arī norāda, ka tas darbojas ar WP Super Cache dzimtā saderībaun pēc noklusējuma izvairīties no kritisko lapu kešēšanas.
Tātad e-komercijas vietni var kešēt, bet tā ir jātestē kā “dzīvas izmaiņas”.

5. jautājums: Vai man vajadzētu izvēlēties LiteSpeed Cache vai WP Rocket?

• Vai esat pārliecināts, ka resursdators ir LiteSpeed/OpenLiteSpeed?: Prioritāte LiteSpeed Cache (bezmaksas un spēcīga, ar servera līmeņa LSCache galvenajām priekšrocībām).
• Jūs neesat pārliecināts par hostinga paketes izvēli / nevēlaties kompromisus / vēlaties integrēt un ietaupīt.: WP Rocket ir stabilāka
• Jūs esat satura vietne un jums ir svarīgs budžets.: WP Super Cache ir stabilāka un vieglāka.

Cache spraudnis ar CDN

Kešēšanas spraudnis atrisina problēmu “mazāka avota staciju skaitīšana un zemāks TTFB”; CDN atrisina problēmu “statiskie resursi un lapas tuvāk globālajiem lietotājiem”. Abu šo risinājumu superpozīcija ir kopējais optimālais risinājums globālai piekļuvei.

• Bieži sastopama satura staciju kombinācija:Lapas kešatmiņa + CDN statiskais sadalījums
• Biežāk sastopamās dinamisko staciju kombinācijas:Lapas kešatmiņa (stingra izslēgšanas kontrole) + objektu kešatmiņa (pēc pieprasījuma) + CDN statiskais sadalījums

👉 Lasīt:CDN paātrināšana (globālā mezgla un kešēšanas politika)

Ieteicamās kombinācijas vietnes kešēšanai

1. Satura vietne / emuārs / dokumentu vietne

Mērķis: Samazināt TTFB, padarīt pirmo ekrānu stabilāku, samazināt servera spiedienu, strādāt ar CDN globālai izplatīšanai.

1.1 Visvieglākais biznesa kombinācija

• WP Rocket (lapas kešēšana + priekšlāde + front-end optimizācija)
  • CDN (dodieties uz CDN lapas sarunu lapu)

Piemērojams:

• Jūs vēlaties “zemu iestatījumu, ātrus rezultātus un zemu risku”.”
• Tēmas/plugins daudz, vēlas samazināt saderību throwsing apkārt

Uzmanības punkti:

• Lai izvairītos no funkcionālām anomālijām (izvēlnes, veidlapas, izsekošana u. c.), front-end optimizācijas (īpaši JS latentuma) tiek iespējotas pakāpeniski.
• Bieži pārskatāmām/izvietojamām vietnēm ir jāizmanto “tīrīšanas + iesildīšanās” stratēģija, pretējā gadījumā pirmais "auksto" lapu apmeklējums būs lēns.

1.2 Bezmaksas un stabilas klasiskās kombinācijas

• WP Super Cache (statiskā HTML kešatmiņa): Ģenerēt statisku HTML no dinamiskām lapām, galvenokārt nereģistrētiem lietotājiem.
  • CDN

Piemērojams:

• Budžeta jutīgums, bet stabilitāte
• Apmeklētāji būtībā nepiesakās
• Kontrolēts satura atjauninājumu temps

Uzmanības punkti:

• Tā ir kombinācija “vispirms lapas kešēšana”, negaidiet, ka tā atrisinās visas CSS/JS sarežģītības!

---

2. Korporatīvā vietne / zīmola vietne / mērķlapa

Mērķis: Esi ātrs, bet vēl svarīgāk ir “optimizācijas dēļ nesabojāt konversijas saiti”.

2.1 Robustas un kontrolējamas (ieteicamās globālās izvietošanas/konversijas stacijas)

• WP Rocket
• + (pēc izvēles) viegla attēlu optimizācija (jums ir lapa “attēlu optimizācija”)
  • CDN

Kāpēc tas ir noderīgi konversijas stacijām:

• Konvertējamās vietnes baidās no “optimizācijas izkropļotajām formām/iznirstošajiem logiem/sekošanas skriptiem”.”
• WP Rocket ir vairāk “integrēta” tādā nozīmē, ka varat iespējot un regresa testu katru elementu sistēmā.

Uzņēmuma tīmekļa vietnes “tiešsaistes princips”:

• Veiktspējas optimizācija ir “darbības uzsākšanas izmaiņas”, un tai ir jābūt regresijas testu kontrolsarakstam.
• Jebkuri iestatījumi, kas saistīti ar JS kavēšanos/apvienošanu/saspiešanu, pirms palaišanas tiešraidē ir jāpārbauda pirmsizlaides vidē!

---

3. WooCommerce e-komercijas vietne (pasūtījumi + dinamiskā lapas drošība)

Mērķis: Ir svarīgi būt ātram, bet arī nodrošināt, lai iepirkumu grozs, izrakstīšanās un konta lapas būtu pilnīgi pareizas.

Oficiālie WooCommerce kešēšanas spraudņa punkti ir ļoti skaidri:Iepirkumu grozs / kase / konta lapa nav kešatmiņasIeteicams arī izvairīties no JavaScript failu saspiešanas, lai samazinātu savietojamības problēmas.

3.1 Bezmaksas un droši maršruti, kas ir draudzīgāki iesācējiem

• WP Super Cache + WooCommerce
  • CDN

Kāpēc tā ir minēta kā “drošāka vieta, kur sākt”:

• WooCommerce oficiāli norāda, ka tas ir saderīgs ar WP Super Cache, un informē WP Super Cache, ka pēc noklusējuma netiek kešētas galvenās lapas, piemēram, grozs/izrakstīšanās/konts.
• Vietnēm, kas sāk darboties e-komercijas jomā, “vispirms nav negadījumu” ir svarīgāk nekā “ārkārtēja veiktspēja”.

3.2 Ja izmantojat LiteSpeed hostu (bezmaksas, bet jaudīgs).

• LiteSpeed Cache (lai izmantotu servera kešatmiņas priekšrocības, jābūt LiteSpeed/OpenLiteSpeed mitinātājam).
• + (pēc izvēles) objektu kešēšana (Redis/Memcached, atkarībā no hostinga jaudas un vietnes lieluma).
  • CDN

Piemērojams:

• Saimnieka kaudze ir skaidra, un jūs esat gatavs izveidot kešēšanas noteikumus un izslēgšanas politiku.
• Pasūtījumu un preču apjoms ir liels, un ir nepieciešama spēcīgāka avota stacija, kas spēj izturēt spiedienu.

3.3 Inženieru komandas/kompleksa e-komercija (kontrolējama ar vairākiem moduļiem)

• W3 Total Cache (veiktspējas sistēma, vairāki kešatmiņas slāņi, integrēti ar CDN)
  • Objektu kešēšana (pēc pieprasījuma)
  • CDN

Piemērojams:

• Izmantojot Dev/Ops, jūs varat sākt dzīvot ar “moduļa pakāpenisku aktivizēšanu + spiediena testēšanu + regresijas testēšanu”.
• Nepieciešamība pēc fragmentu kešatmiņas / sarežģītākiem stratēģijas variantiem (piemēram, precīzas kešatmiņas pēc ierīces/reģiona/valodas).

---

4. Dalības vietne / kopiena / tiešsaistes kursi (daudzi pieteikumi, spēcīga personalizācija).

Mērķis: Publiskojiet saturu ātri, vienlaikus nodrošinot, ka “pieteikto lietotāju saturs netiek izkliedēts”.

4.1 Glābt, bet nepieciešamas stingras izslēgšanas stratēģijas

• WP Rocket
• + (pēc izvēles) objektu kešēšana (ja ir daudz dinamisko vaicājumu)
  • CDN

Galvenie punkti:

• No kešēšanas jāizslēdz “lietotāja veiktās izmaiņas” lapas: Personīgais centrs, Pasūtījumi, Mācību gaita, Ziņojumi, Iepirkumu grozs u. c.
• Šāda veida vietnes ir visvairāk pakļautas “citu cilvēku satura/nepareizo atļauju” skatīšanai, un riskiem ir jābūt izklāstītiem lapā.

4.2 LiteSpeed hostings + papildu politika

• LiteSpeed Cache (servera kešatmiņa + sarežģītāki politikas rīki)
• + (pēc pieprasījuma) objektu kešēšana
  • CDN

Galvenie punkti:

• Dalības vietnēm parasti ir vairāk nepieciešama mentalitāte “kešējams ķermenis + ne-kešējams fragments”.
• jāuzlabo iesildīšanās un tīrīšanas stratēģijas, citādi “lietotāji pēc atjaunināšanas joprojām redz veco saturu” būs ļoti bieži sastopama parādība.

Tīmekļa kešatmiņa “Demining Casebook”

1. gadījums: Uzstādīts kešēšanas spraudnis, ātrums ir gandrīz nemainīgs

Fenomens:

• Vietējais/reģionālais ātrums ir labs, bet ārzemēs (starpkontinentālais) joprojām lēns.
• TTFB ir uzlabojusies, bet kopējais ielādes laiks nav ievērojami samazinājies

Bieži sastopamie cēloņi:

• Jūs veicat tikai avota kešēšanu (TTFB), bet statiskie resursi (attēli/JS/CSS/fonti) joprojām tiek ielādēti no avota visā kontinentā.
• Trešo pušu skripti (reklāmas, tērzēšanas, statistikas dati) palēnina atveidošanu un mijiedarbību.
• Lēna lejupielāde lielu attēlu izmēru dēļ (kešēšana neatrisina “pirmās lejupielādes” lieluma problēmu).

Risinājuma ideja:

• Kešatmiņas spraudnis vispirms rūpējas par “avota nepietiekamu uzskaiti + trāpījumiem”.”
• Statiskie resursi iet CDN
• Attēla attālināta attēla optimizācija
• Trešo pušu skripti veic aizkavēšanas / sadalīšanas stratēģijas

Lasīšana:

• CDN paātrināšana: globālie mezgli un kešēšanas stratēģijas
• Attēlu optimizācija: formāts/kompresija/liega ielāde

---

2. gadījums: Pēc kešēšanas iespējošanas lapa tiek mainīta, bet frontend netiek atjaunināta.

Fenomens:

• Saturs/stils ir atjaunināts backend, bet frontend joprojām tiek rādīta vecā versija.
• Vai arī tiek atjaunināti tikai daži reģioni, bet citi paliek nemainīgi (parasti globālajām stacijām).

Bieži sastopamie cēloņi:

• Lapas kešatmiņa nav izdzēsta vai ir izdzēsta nepareizā apjomā
• Uzsildīšanās / pārlūkošana nedarbojas, iztīrītā kešatmiņa atdziest, kā rezultātā pirmais apmeklējums ir lēns, bet jūs kļūdaini domājat, ka atjauninājumu nav.
• Ja iespējojat CDN malas kešatmiņu, mala var saglabāt arī vecos resursus.

Risinājuma ideja:

• Izveidojiet “tīrīšanas stratēģiju pēc izlaišanas/atjaunināšanas”: attīriet attiecīgās lapas, nevis veiciet stingru tīrīšanu visā vietnē.
• Izveidojiet iesildīšanās stratēģiju svarīgām lapām (sākumlapai, galvenajām mērķlapām), lai izvairītos no “tīrīšana = palēnināšana”.”
• CDN Slānis, lai pēc vajadzības veiktu malu tīrīšanu

---

3. gadījums: Neizvietots saturs pēc vairāku valodu/valūtu maiņas

Fenomens:

• Pēc valodu pārslēgšanas lapā joprojām tiek rādīta iepriekšējā valoda
• Vai arī lietotājiem noteiktos reģionos tiek rādīta nepareiza valūta/nepareizs saturs.

Bieži sastopamie cēloņi:

• Kešatmiņā netiek izšķirti “variantu izmēri” (cookie / parametri / valodas prefiksi / apakšdomēni).
• Kešatmiņas trāpījums sniedz A valodas lapas rezultātus B valodas lietotājiem

Risinājuma ideja:

• Daudzvalodu programmas definēšana: direktoriji/apakšdomēni/parametri/cookie
• “Variantu politiku” pievienošana kešēšanas noteikumiem vai galveno lapu izslēgšana
• Dažām vietnēm ir nepieciešamas modernākas “slice and dice” kešēšanas idejas (W3TC ir labāk piemērots inženierijas kontrolei).

---

4. gadījums: Problēmas ar iepirkumu grozu/izrakstīšanos e-komercijas vietnē ar iespējotu kešēšanu

Fenomens:

• Iepirkumu grozs ar nepareizu daudzumu, nepareiza cena, nedarbojas izrakstīšanās poga
• Piesakoties un redzot saturu, kas jums nepieder (nopietni).

Bieži sastopamie cēloņi:

• Kritiskās lapas, piemēram, grozs/norēķini/mana konts, tiek kešētas.
• JS minify/merge izraisa maksājumu/dinamisko komponentu nesaderību

Risinājuma ideja:

• WooCommerce ir oficiāli: grozs/reģistrācija/konti nedrīkst tikt kešēti, un ir ieteicams izvairīties no JS faila saspiešanas.
• Vispirms palaidiet “lapas kešatmiņu + izslēgt”, pēc tam apsveriet front-end optimizāciju.
• Ja izmantojat WP Super Cache, WooCommerce norāda, ka tas ir saderīgs ar vietni un pēc noklusējuma izvairās no galveno lapu kešēšanas.

---

5. gadījums: izvēlnes/veidlapas/iznirstošie logi ir bojāti pēc tam, kad ir iespējota iespēja “Aizkavēt JS/saliedēt skriptus”.

Fenomens:

• Navigācijas izvēlne netiek atvērta
• Veidlapas validācija neizdevās vai to nevarēja iesniegt
• Iznirstošā loga/iznirstošā loga izņēmums
• Statistika/konversijas notikumi netiek aktivizēti (lielākā sāpju problēma palaišanas vietnēm).

Bieži sastopamie cēloņi:

• Atliktais JS maina skriptu izpildes grafiku: skripti netiek izpildīti, kamēr lietotājs ar tiem neiedarbojas, un dažas sastāvdaļas ir atkarīgas no “inicializēt lapas ielādes brīdī”.”
• Apvienošana/saspiešana var mainīt skriptu secību vai izjaukt atkarības.

WP Rocket oficiāli apraksta “atlikto JS izpildi” kā vienu no spēcīgākajām JS optimizācijām: skriptu izpilde tiek atlikta uz laiku pēc lietotāja mijiedarbības, lai piešķirtu prioritāti lapas renderēšanai. Tā ir lieliska iespēja, taču tā nozīmē arī lielāku savietojamības risku.

Risinājuma ideja:

• Iespējot pakāpeniski: kešatmiņu, pēc tam attēlus, pēc tam CSS, pēc tam JS.
• Izslēgumu pievienošana galvenajiem skriptiem (maksājumi, veidlapas, izvēlnes, izsekošana).
• Katrai izmaiņai veiciet regresijas testu kontrolsarakstu.

---

6. gadījums: ir instalēta tikai LiteSpeed kešatmiņa, taču nav sajūtas, ka tā darbojas.

Fenomens:

• LiteSpeed kešatmiņa ir ieslēgta, bet TTFB daudz nesamazinās.
• Arī trāpījumi nav acīmredzami

Bieži sastopamie cēloņi:

• Jūsu serveris nav LiteSpeed/OpenLiteSpeed un nevar izmantot galvenās LSCache iespējas.
• Vai arī jūs iespējojāt vairākas optimizācijas, bet “lapas kešēšanas politika/priekšsildīšana/izslēgšana” netika izveidota!

Risinājuma ideja:

• Vispirms pārbaudiet resursdatora kaudze: vai tas ir LiteSpeed/OpenLiteSpeed (tas ir priekšnoteikums).
• Atgriešanās pie “Lapas kešatmiņas politikas + Warm Up + Exclude + Clean Up”.”
• Ja neesat LiteSpeed hostētājs: Apsveriet WP Rocket vai WP Super Cache.