A SWIFT Performance gyorsítótár-bővítmény nagyon izgatott volt, mert óriási változást hozott a webhelyeimen. Korábban 3 vagy 4 különböző gyorsítótár-bővítmény között jártam a különböző webhelyeken, de most már szinte mindegyiket le tudom cserélni erre az egyre (a másik kedvencem a LiteSpeed ​​Cache).

Az egyetlen hiányzó dolog a hivatalos dokumentáció volt, mivel sok felhasználó még mindig nem érti, hogy az egyes opciók mit csinálnak, és hogyan diagnosztizálják a problémákat. Mivel a hivatalos Swift csapat nagy része a bővítmény fejlesztésével van elfoglalva, úgy döntöttem, megírom a saját közösségi útmutatómat.

Olvassa el a legjobb SWIFT Performance beállítási tippjeimet!

Semmilyen módon NEM vagyok alkalmazott vagy hivatalos Swift fejlesztő. Ezt a nem hivatalos útmutatót azért írtam, hogy segítsek a Swift-felhasználóknak, mert nagy rajongója vagyok ennek a hihetetlen gyorsítótár-bővítménynek.

Több száz ügyféloldalon tettem vele sebességcsodákat, és rájöttem, hogy a felhasználók segítésével töltött idő felszabadíthatja a Swift-fejlesztőket, hogy a technikai támogatás helyett az én fantáziafunkcióim megvalósítására összpontosítsanak.

Az önerő és a hatékonyság jegyében olvassa el alábbi útmutatómat!

GYORS beállítási útmutató

Íme az 5 perces beállítási verzió elfoglalt emberek számára. Nem kell sok ahhoz, hogy fantasztikus eredményeket érjünk el ebből a csodálatos, #1. rangú gyorsító pluginból . Csak győződjön meg róla, hogy nem vakon engedélyez mindent.

(MEGJEGYZÉS: Sokkal jobban szeretem a konfigurációimat, mint a hivatalos Swift automatikus konfigurációkat. A RÉSZLETES beállítási útmutatómban részletesen megtudhatja, miért választottam ezeket a beállításokat.)

1. Telepítse a  SWIFT Performance Lite -ot (ingyenes verzió) vagy a SWIFT Performance -t (prémium). Kattintson a KÉZI beállítások, majd a Speciális nézet elemre (jobb felső gomb).
2. Általános > Általános – engedélyezze a „Számítási API használata” lehetőséget, ha fizetős verziója van.
3. Általános > Tweaks – itt helyezze el a 301 HTTPS átirányítást az „Egyéni Htaccess” területre.
4. Média > Képek – tiltsa le a „Lazy Load Images” funkciót.
5. Média > Beágyazások – engedélyezze a „Youtube Smart Embed” és a „Lazy Load Iframes” funkciót, ha a Youtube beágyazása vagy a GoogleMaps NINCS az oldal tetején.
6. Optimalizálás > Általános – tiltsa le a „Csak előreépítés optimalizálása” és az „Érvénytelen HTML javítása” lehetőséget. Engedélyezze a „Hangulatjelek letiltása” lehetőséget, ha nem használja őket.
7. Optimalizálás > Szkriptek – tiltsa le a „Szkriptek egyesítése” lehetőséget.
8. Optimalizálás > Stílusok – tiltsa le a „Stílusok egyesítése” opciót.
9. Gyorsítótár > Általános – válassza a „Lemezgyorsítótár újraírással” lehetőséget a gyorsítótárazási módhoz, és a „Művelet alapú módot” a gyorsítótár lejárati módhoz. Az „Időalapú módot” csak akkor használnám, ha webhelyén gyakran vannak nem tartalmi frissítések (például új megjegyzések vagy a termékállapot változásai).
10. Gyorsítótárazás > Tweaks – tiltsa le az „Avoid Mixed Content” opciót.
11. Gyorsítótárazás > Kivételek – kizár minden bejegyzéstípust, kivéve azokat a bejegyzéseket/oldalakat/termékeket, illetve bármely más bejegyzéstípust, amelyeket a kezelőfelületen saját URL-címükkel böngésznek. A kapcsolatfelvételi űrlapokat tartalmazó oldalak kizárása. Ha rendelkezik WooCommerce szolgáltatással, zárja ki a Fiók/Kosár/Pénztár oldalakat.
12. Gyorsítótárazás > Bemelegítés – válassza a „Korlátlan” lehetőséget az Előkészítési sebességhez, ha rendelkezik ezzel a lehetőséggel, és webhelye legfeljebb 1000 oldalas.
13. Bővítmények > WooCommerce – engedélyezze a „Cache Empty Minicart”, de a „Ne tiltsa le” lehetőséget a Kosártöredékek letiltása esetén, és tiltsa le a WooCommerce Session Cache (BÉTA) funkciót.
14. CDN – írja be az adatait, ha rendelkezik CDN-nel.
15. Nyomja meg a [VÁLTOZÁSOK MENTÉSE] gombot, majd a [CLEAR CACHE] gombot , és kész a Swift beállítása!
16. Ellenőrizze a bemelegítési táblázatot – győződjön meg arról, hogy az összes fontos oldal fel van sorolva, és az előre gyorsítótárazott. Kattintson a „Start Prebuild Cache”, vagy lépjen a Gyorsítótárazás > Bemelegítés és a „Távoli előreépítési gyorsítótár engedélyezése” elemre, ha nem. (Rendben van, ha néhány furcsa elem jelenik meg, vagy néhány elem nem tárolódik a gyorsítótárban.)
17. Ellenőrizze, hogy a webhely gyorsítótárazott -e – bejelentkezés nélkül keresse fel webhelyét a Chrome inkognitóablakban. Kattintson a jobb gombbal az oldal tetszőleges pontjára, kattintson az „Oldal forrásának megtekintése” elemre, és görgessen lefelé. Ha a „Cached with Swift Performance Lite” üzenetet látja, akkor működik! (Ha nem, próbálja meg frissíteni az oldalt.)
18. Élvezze a gyors sebességet! – vagy olvassa el a további tippeket és hibaelhárítási lépéseket.

Ha problémái vannak:

• A Swiftnek szupergyorsnak kell lennie!  – Ha nem kap azonnali oldalbetöltést, menjen vissza, és állítsa be újra a dolgokat! (PS: nagyon sokat segít a  jó webtárhely .)
• Az oldal kialakítása vagy funkciója megszakad valahol? – a Szkriptek egyesítése és a Stílusok egyesítése letiltása. Vagy engedélyezze őket egyenként a problémák elkülönítése érdekében. (Ne felejtse el kiüríteni a CDN-t vagy a Lakkot a tartalom/gyorsítótár módosítása után!)
• Probléma a https/SSL átirányítással? (vagy furcsa URL-ek jelennek meg a kezelőfelületen) – a htaccess helyett tegye a 301-es HTTPS-átirányításokat a „Tweaks > Custom Htaccess” menüpontba.
• Nem működnek a kapcsolatfelvételi űrlapok? Zárja ki a kapcsolati oldalt a gyorsítótárazásból, vagy váltson át Caldera űrlapokra. A Contact 7-tel voltak problémáim (és utálom, hogy minden oldalon betöltődik).
• A „Swift gyorsítótárazva” nem jelenik meg az oldal forrásában? – Lehet, hogy az oldal nem gyorsítótáraz, de azt is jelentheti, hogy valami kihúzza a HTML megjegyzéseket. (A Cloudflare néha ezt teszi.)
• Még mindig segítségre van szüksége? – kövesse az alábbi részletes lépéseimet. Ingyenes támogatás érhető el a Swift tudásbázison ,  a WP repo -n , a Facebook -csoporton vagy a jegytámogatáson (prémium felhasználók számára).

RÉSZLETES beállítási útmutató

1. LÉPÉS – Telepítse a SWIFT Performance bővítményt

Telepítse a SWIFT Performance Lite -ot (ingyenes verzió) vagy a SWIFT Performance -t (prémium).

A Swiftnek kevés követelménye van, de akkor is működhet, ha ezek közül néhány nem elérhető:

• Apache modulok – mod_deflate, mod_filter, mod_setenvif…mind a 3 általában elérhető a legtöbb szerveren.
• Loopback – ekkor látogathatja meg magát a szerver. Néha nem érhető el, ha letiltja a robotokat vagy az indexelést a webhely feltérképezésében.

A modulokra nincs szükség, de a legjobb teljesítményt nyújtják. A legtöbb megosztott hosting fiók már rendelkezik ilyenekkel; egyes VPS-ek nem, kérje meg a webhost/sys-admin telepítését. Legtöbbjüknek nem lesznek plugin-ütközései vagy átírási problémái, és ha igen, a Swift elmondja, hogyan javíthatja ki. (MEGJEGYZÉS: a szkript nem észleli a LiteSpeed ​​szervereket, így a telepített modulok nem észlelik, nincs semmi baj.) Még ha hibákat is lát, akkor is folytassa; A Swiftnek még működnie kell.

2. LÉPÉS – Menjen a Swift Performance Settings menübe

Nyissa meg a Swift beállításait , és kattintson a jobb felső sarokban található [Speciális nézet] lehetőségre.

Végignéztem az összes beállítást, és alább hagyom róluk a részletes gondolataimat. Bármit elfelejtek megemlíteni, azt jelenti, hogy az alapértelmezett beállításokon hagytam.

Tábornok:

• Általános > Lábnyomok elrejtése – letiltva, így láthatom a Swift megjegyzéseket a forráskódban. (Tájékoztatás: A Cloudflare eltávolíthatja a HTML megjegyzéseket.)
• Általános > Számítási API használata (prémium) – fantasztikus funkció, engedélyezze! Felgyorsítja a gyorsítótár előépítését és csökkenti a CPU-használatot. Különösen hasznos nagy oldalakon (több mint 400 oldal) és/vagy lassú szervereken.
• Általános > Gyorsítótár törlése – az alapértelmezés szerint jó, hacsak nem szeretné engedélyezni a szerkesztőknek vagy más felhasználóknak a gyorsítótár törlését a webhely módosítása után.
• Általános > Rendszergazdai értesítések letiltása – engedélyezve. Távolítsa el a fizetős verzió megvásárlását kérő hirdetéseket.
• Általános > Eszköztár letiltása – engedélyezze, ha nem használja a Swift opciókat a felső eszköztáron.
• Általános > Oldalspecifikus szabályok – lehetővé teszi a globális Swift-beállítások oldalankénti felülbírálását. Nagyon klassz funkció, de csak a rendkívül felduzzasztott webhelyek finomhangolásához szükséges.
• Általános > Bétatesztelő (prémium) – lehetővé teszi a legújabb funkciók kipróbálását. Gyártóhelyeknek nem ajánlom. De szórakoztató lehet a saját személyesed számára, amelyeket napi szinten karbantartasz.
• Általános > Anonimizált adatok gyűjtése – számomra le van tiltva.
• Általános > Hibakeresési napló – csak a problémák diagnosztizálásánál engedélyezze.
• Általános > Cookie-k letiltása – nem használom. Ez a GDPR célja; ha más mechanizmust/szűrőt használ a cookie-k betöltésére csak a GDPR elfogadása után. A cookie-k csak az alkalmazásgyorsítótárhoz és a felhasználó azonosításához használhatók a GA Bypass-hoz, ezeket a funkciókat NEM EL kell ellenőrizni. A sebességet egyik esetben sem befolyásolja.
• Általános > Bétatesztelő – ne engedélyezze a termelési helyeken. Eleget mondott.
• Tweaks > Custom Htaccess – tegyen ide 301 HTTPS átirányítást . (Ez sokkal előnyösebb, mint az SSL-bővítmény használata!) Ha bármilyen okból ez összezavarja webhelyét vagy csúnya URL-eket hoz létre, próbálja meg inkább közvetlenül a htaccess-be helyezni az átirányításokat (a Swift szakasz FELÜTT bárhol javaslom).
• Tweaks > Háttérkérések – még nem használtam, de fantasztikus! Megakadályozza, hogy a szükségtelen AJAX kérések lelassítsák az oldalbetöltést. (Például a felhasználók számára nem kritikus ajax kérések eltávolítása… bejegyzések megtekintése stb.).
• Heartbeat > Heartbeat letiltása – hagyja figyelmen kívül ezt, kivéve, ha az adminisztrációs terület lassú (bizonyos beépülő modulok és/vagy sok bejelentkezett felhasználó miatt). A WordPress Heartbeat API egy nagyszerű funkció, amely nyomon követi a felhasználói munkameneteket az adminisztrátorban, és automatikusan elmenti a tartalmat szerkesztéskor, de az adminisztrátori és a frontend oldalakon nagy CPU-erőforrást igényelhet. Az összeset letilthatja, kivéve a bejegyzéseket/oldalakat. Ha bizonyos adminisztrátori/front-end beépülő modulok nem működnek, hagyja az egészet bekapcsolva, de növelje a gyakoriságot. (Ehelyett használhatja a Heartbeat Control beépülő modult a részletesebb beállítások érdekében.)
• Heartbeat > Heartbeat Frequency – rendben, továbbra is szeretné csökkenteni a szívverés hatását a szerveren, de nem szeretné letiltani? Egyszerűen növelje a frekvenciát. Úgy gondolom, hogy a 120 másodperc biztonságos, de őszintén szólva, ha szívverési problémái vannak, csak jobb webtárhelyet kell készítenie .
• Cronjobs > Limit WP Cron – A WordPress szükségtelenül tölti be a cront minden gyorsítótár nélküli oldalbetöltéskor. Ennek csökkentése nagyszerű ötlet, ha magas a cron aktivitása.
• Cronjobs > Enable Remote Cron – általában le van tiltva. Engedélyezze, ha webhelye olyan cron-feladatokra támaszkodik, amelyek meghibásodnak, mert A) a gazdagép letiltotta a WP Cront, B) minden oldala gyorsítótárban van, vagy C) szinte soha nem jelentkezik be a WP-adminba.
• Google Analytics > A Google Analytics megkerülése – nagyszerű ötlet a Google Analytics JS-szkriptjének helyi gyorsítótárazására és a webhely JS-vel való egyesítésére (elméletileg eltávolít egy külső hívást a Google felé). Sebesség szempontjából nem sokat segített, de magasabb oldalsebesség-pontszámot ad (felületi előny). Az egyetlen probléma az, hogy a GA nem működik gyorsítótárazott/kizárt állapotban. A 100%-os GA funkció garantálása érdekében a gyorsítótár-előkészítés során és a gyorsítótárazott oldalakon a CAOS beépülő modulnál vagy a témámnál ragaszkodtam a GA kezeléséhez.
• Whitelabel (prémium) – hasznos ügynökségek vagy webhosztok számára, akik megpróbálják elrejteni a gyorsítás titkait. Lehetővé teszi a Swift beépülő modul és leírás átnevezését, hogy az ügyfelek ne tudják megállapítani, hogy Swiftet használ.

Média:

• Képek > Képek optimalizálása feltöltéskor (a következő 4 beállítást is engedélyezi) – Jobban szeretem a ShortPixelt a képtömörítéshez, de a Swift segítségével sok pénzt takaríthat meg, és egy újabb beépülő modult nem használhat a webhelyen.
• Képek > Képforrás – Médiatár az alapértelmezett beállítás. De a wp-content könyvtár nagyon jó, ha más képek is vannak a wp-content könyvtárban, és nincsenek az alapértelmezett WP médiakönyvtárhoz csatolva. Nagyon klassz lehetőség.
• Képek > Képoptimalizáló – kísérletezzen, és derítse ki, mi illik a legjobban webhelyéhez. Jó lenne, ha lenne egy összehasonlító ötletem arra vonatkozóan, hogy hány százalékos minőség egyenlő a ShortPixel LOSSY vagy GLOSSY tömörítésével… de nem teszem. Teszteld magad.
• Képek > Nagy képek átméretezése – hasznos a nem technikusok számára, akik túlméretezett képeket töltenek fel közvetlenül a fényképezőgépről. De egyébként hagyja ki, ha szándékosan nagy képeket szeretne HiDPI (retina) képernyőkre.
• Képek > Eredeti képek megtartása – hagyja bekapcsolva, ha később vissza szeretné állítani az eredetiket, és egy másik beépülő modullal újra szeretné optimalizálni, vagy eltérő méretű hordozót szeretne létrehozni. Vagy legalább tartsa meg őket, amíg meg nem találja a legjobb tömörítési beállításokat.
• Képek > GenerateWebP – általában engedélyezve van. WebP verziót hoz létre az összes képről.
• Képek > WebP kiszolgálása – a „képelemek” használata a preferált lehetőség; stílusproblémák esetén használja az újraírási lehetőséget. Az újraírási lehetőség is meghiúsulhat CDN vagy Cloudflare használata esetén. Gondosan tesztelje.
• Képek > Kép előtöltése URL alapján – nagyszerű a fontos képek (például az oldal tetején) előzetes betöltéséhez, hogy gyorsan megjelenjenek.
• Képek > Kép előtöltése CSS-osztálynév szerint – hatékonyabb módja a fontos képek előzetes betöltésének, a CSS-osztályok azonosításával.
• Képek > Lazyload Images – tiltsa le! Utálom a lazyloadot . Ez az intuitív ellentétes taktika az oldalbetöltés felgyorsítására azáltal, hogy nem tölt be mindent. Találd ki, mit?… ha nem tölt be mindent, akkor minden lassabban tölt be! Gyenge felhasználói élmény és lassabbnak érzi magát ; bosszantó, amikor gyorsan görget a forgalmas webhelyeken vagy üzletekben. De hiábavaló, ha a legtöbb oldalon csak kevés kép található, és szörnyű, ha a hajtás felett vannak képek. Szükségtelen, ha ingyenes CDN-t (Cloudflare) használ, bár pénzt takaríthat meg, ha fizetős CDN-t használ. Vannak ritka felhasználási esetek , például ha nagyon nagy képei és/vagy sok képei vannak ÉS a látogatói nem görgetnek gyorsan… de az esetek 99%-ában úgy tűnik, hogy webhelye gyorsabban töltődik be lusta betöltés nélkül !
• Képek > Képek URL kizárása – a képek kizárása a lazyloadból az url karakterlánc alapján.
• Képek > Képek kizárása CSS-osztálynév alapján – hatékonyabb módszer a képek lusta betöltésből való kizárására CSS-választóik használatával.
• Képek > A Lazyload szabványok tiszteletben tartása – mindenképp ENGEDÉLYEZVE kell, hacsak nem szeretné felülírni ezeket a beállításokat máshonnan.
• Képek > Előtöltési érzékenység – megadja, hogy mennyi időn belül kell betölteni a lusta betöltött képeket, amikor a felhasználó rájuk görget. Az 50 pixeles alapértelmezett beállítás rendben van, de bármikor növelheti, ha a felhasználók gyorsan görgetnek (és szeretné, hogy a képek hamarabb megjelenjenek).
• Képek > Képek betöltése felhasználói interakció esetén – nagyszerű taktika, hogy csak akkor töltsön be képeket, ha a böngésző interakcióba kerül. Jó módszer a szerverterhelés csökkentésére, és valószínűleg javítja az oldalpontszámokat is. Valószínűleg nem sokat számít, ha már lusta a képek betöltése.
• Képek > Inline Lazy Load Images – csökkenti a HTTP-kéréseket azáltal, hogy a beágyazott képkérést base64 kódba helyezi. Ezt le kell tiltani az IMO-ban a modern böngészőkben.
• Képek > Lazyload Placeholder – válassza ki a helyőrző kép stílusát. A legtöbb webhely a felhasználók számára átlátható. A Medium.com webhely az elmosódottat kedveli. Mások gyenge minőségű képet készítenek. Valójában személyes preferencia alapján. A tartalom szempontjából nem kulcsfontosságú képek nem igazán számítanak. De ha igen, akkor valószínűleg legalább átlátszót vagy gyenge minőségűt szeretne.
• Képek > Lazyload Background Images – a pokolba! Ne engedélyezze ezt. Szüksége van ezekre a hátterekre (különösen a felül lévőkre), hogy azonnal megjelenjenek, különben a webhely lassabbnak tűnik!
• Képek > Hiányzó méretek javítása – hasznos a lassú képbetöltés miatti elrendezés eltolódásának megelőzése érdekében. De nekem személy szerint nincs rá szükségem.
• Képek > Reagáló képek kényszerítése – a legtöbb témában már vannak reszponzív képek. Engedélyezze, ha a téma/oldalkészítő (utállak, Thrive Architect) pazarlóan tölt be nagy képeket a mobilra. Ha ez a funkció nem tudja érzékenysé tenni a képeket, hagyja ki.
• Képek > Gravatar gyorsítótár – általában le van tiltva. Csak akkor hasznos, ha folyamatosan sok megjegyzése van. Népszerű bejegyzéseimnél (500+ megjegyzés) a gyorsítótárazott megjegyzés-avatarok a betöltési idő 60%-át teszik ki. De akkor is, miért vesződsz valami olyasmi gyorsítótárazásával, ami amúgy is betöltődik a bejegyzéseid végén?
• Képek > Gravatar gyorsítótár lejárata – hosszú időt használnék, például 1 hónapot, mivel a legtöbb ember soha nem frissíti a Gravatar képeit. És még ha meg is tennék, kit érdekel… számítana, ha a gyorsítótár nem frissül azonnal.
• Képek > Beágyazott kis képek – fantasztikus funkció, számos érv mellett és ellen. Hagyja BEVEZETÉS nélkül, ha nem tudja, mi az, a kis képei nem a webhely tetején találhatók, sok oldaluk van, vagy ha törődik a gyorsabb gyorsítótár-előkészítéssel (mint én). Próbálja ki ELLENŐRIZVE, ha sok kis kép van a tetején (közösségi vagy e-kereskedelmi ikonok), nem használ betűformátumot (FontAwesome), lassú képhívások vagy nagyon kevés oldal. Valószínűleg jobb kis webhelyekhez.
• Embeds > Youtube Smart Embed (engedélyezi a következő opciót) – okos! Tetszik. Létrehoz egy képbélyegképet (ugyanúgy jelenik meg, mint egy Youtube beágyazási mezőben, de nem tölti be az összes késleltetett elemet), amely kattintásra betölti a videót.
• Beágyazások > Youtube-videók kizárása – letiltja az „okos beágyazás” funkciót a kiválasztott videókon. Hasznos, ha videóid vannak a webhely tetején, és/vagy szeretnéd, hogy azok automatikusan lejátsszanak.
• Beágyazások > Előtöltési érzékenység – megadja, hogy mennyi időn belül töltődjenek be a lusta betöltött YouTube beágyazott iframe-ek, amikor a felhasználó rájuk görget. Az 50 képpontos alapértelmezett beállítás rendben van, de mindig növelheti, ha a felhasználók gyorsan görgetnek (és szeretné, hogy az iframe hamarabb megjelenjen).
• Beágyazások > Iframe-ek lusta betöltése (engedélyezi a következő 2 lehetőséget) – okos! Imádom a Swiftet ezért. Hasznos, ha több iframe videó/videó beágyazása van egy oldalon ÉS/VAGY messze a hajtás alatt helyezkednek el. Ne engedélyezze, ha oldalai tetején iframe-ek vannak, ez késlelteti az észlelt oldalbetöltést! A gyakori iframe-ek a Youtube beágyazások, a Googlemaps vagy a Facebook-dobozok.
• Beágyazás > Iframe-ek kizárása URL alapján – fantasztikus! Használja, hogy kizárja a fontos iframe-eket (például a webhely tetején lévőket) a lusta betöltésből.
• Beágyazások > Iframe-ek kizárása CSS-osztálynév alapján – hatékonyabb módszer a YT iframe-ek lusta betöltésből való kizárására CSS-választóik használatával.
• Embeds > Respect Lazyload Standards – valószínűleg ENGEDÉLYEZNI kell, hacsak nem szeretné felülbírálni a beállításokat máshonnan, és használni szeretné a lusta betöltési beállításokat.
• Beágyazások > Előtöltési érzékenység – megadja, hogy mennyi időn belül töltődjenek be a lusta betöltött YouTube beágyazott iframe-ek, amikor a felhasználó rájuk görget. Az 50 képpontos alapértelmezett beállítás rendben van, de mindig növelheti, ha a felhasználók gyorsan görgetnek (és szeretné, hogy az iframe hamarabb megjelenjen).
• Beágyazások > Iframe-ek betöltése felhasználói interakció esetén – csak azután tölti be az iframe-eket, hogy a felhasználó rákattintott vagy görgetett az oldalon. Kiváló az oldal alsó részén található iframe-ekhez.

Optimalizálás > Általános:

• Server Push engedélyezése – Javaslom, hogy tiltsák le. Felgyorsítja a webhelyeket azáltal, hogy előre betölti a CSS/JS-eszközöket a többi oldalhoz, így azok gyorsabban töltődnek be, amikor rájuk kattintanak. Ez előnyösebb a sok CSS/JS-t használó webhelyeken, de nagyobb valószínűséggel okoz problémákat a sok CSS/JS-t tartalmazó webhelyeken (törött elemek, késleltetett terhelés, magas CPU-használat). Gondosan tesztelje, ha engedélyezi. Az oldalpontszámok lassabbnak tűnhetnek, mivel minden oldalbetöltés több elemet tölt be. Azt is feleslegesnek tartom, ha az oldalad minden oldalhoz ugyanazt a CSS/JS-t tölti be (amely már a böngésző gyorsítótárában van).
• Csak előreépítés optimalizálása – törölje a jelölést, hogy webhelye mindig optimalizáljon. Engedélyezze a gyorsítótár felépítésének korlátozását (a legtöbb webhelyen nem szükséges).
• Optimalizálás a háttérben – általában le van tiltva, de hasznos lehet nagy webhelyeknél és/vagy VPS-szervereknél. Számos webhelyem van 100-200 bejegyzéssel VPS-en, és jól megvagyok nélküle. Játszhatsz vele magadnak. Ezáltal a Swift úgy működik, mint azok az „on-the-fly” gyorsítótár-bővítmények, ami tagadja a gyorsítótár előépítésének előnyeit.
• Optimalizálja a 404 oldalt – hagyja LETILTVA, hogy helyet takarítson meg a szerveren. Amúgy 404 oldalhoz nincs szükség oldaloptimalizálásra (CSS, JS stb.).
• Prebuild Booster – Jobban szeretem a fogyatékkal élőket. A CPU helyett memória-erőforrásokat használ előre. Erős szervereken inkább kikapcsolom. Valószínűleg hasznos a megosztott tárhelyen (a CPU-korlátok elkerülése érdekében).
• Hangulatjelek letiltása – tiltsa le, ha nem használ hangulatjeleket a tartalomban vagy a megjegyzésekben. A böngészők amúgy is mutatnak már hangulatjeleket.
• Egyidejű szálak korlátozása – tiltsa le, ha van saját szervere vagy kis webhelye (100 oldal vagy kevesebb). Engedélyezze és állítsa 1-re, 2-re vagy 3-ra, ha megosztott kiszolgálón van, vagy meg szeretné akadályozni, hogy a webhely elkapja a szerver erőforrásait. Ideális esetben minden erőforrást fel kíván használni a gyorsítótár gyors előépítésére.
• Eszközök egyesítése bejelentkezett felhasználók számára – tiltsa le, ha Ön az egyetlen adminisztrátor felhasználó. Elméletileg felgyorsítja a sok bejelentkezett felhasználóval rendelkező webhelyeket (tagság/fórum/stb) a CSS/JS kombinálásával és késleltetésével. De valójában teljesen távol kell maradnia ettől az esetleges hibás stílusok vagy funkciók miatt. Ez sem segít az oldalpontszámokon, mivel nem érik el a bejelentkezett területeket.
• DNS előzetes lehívása – hagyja ENGEDÉLYEZVE. Előre betölti és csökkenti a DNS várakozási idejét a harmadik féltől származó tartományok látogatására vagy az onnan hívott eszközökre.
• Domain gyűjtése szkriptekből – általában engedélyezett. Átvizsgálja és előtölti a javascriptekben található külső tartományokat, felgyorsítva a külső kéréseket. Letilthatja, hogy elkerülje a dolgok előzetes aktiválását (követési célból).
• DNS előzetes lehívásának kizárása – kizárja a tartományokat a DNS előzetes lehívásából. Lehetséges, hogy letiltok bizonyosakat, hogy korlátozzam a terheléseket/kiváltásokat harmadik féltől származó eszközkérelmek miatt?
• A statikus erőforrások normalizálása – haszontalan, ha „Szkriptek egyesítése” és „Stílusok egyesítése” funkciót használ. Javítja a magasabb oldalsebesség pontszámokat, de nem a tényleges sebességet. Engedélyezem ezt, de soha nem olyan webhelyeknél, amelyek gyakran frissítik a megjelenésüket. Sok gyorsítótárazó motor (a Cloudflare is) már intelligensen gyorsítótárazza a statikus eszközöket lekérdezési karakterláncokkal.
• DOM Parser Max Buffer – soha nem foglalkozom ezzel.

Optimalizálás > Szkriptek:

• Szkriptek egyesítése  (egyéb opciók engedélyezése/letiltása) – A helyedben nem egyesíteném a JS-t . Az összes JS-fájlt egyetlen fájlba egyesíti, és betölti. Van egy furcsa egyensúly; biztonságosabb a használata, ha kevesebb szkriptje van (de kisebb a hatása), nagyobb hatással van sok szkriptre, de nagyobb az ütközés esélye vagy az oldalbetöltés késleltetése is. A legjobb felhasználási mód bizonyos szkriptek késleltetése/lusta betöltése. A legrosszabb felhasználás magasabb oldalteszt-pontszámok esetén.
• Aync Execute –  az aszinkron végrehajtás jól hangzik  , de alapértelmezés szerint nincs bejelölve. Talán megszakítja a funkcionalitást, ha a JS nem töltődik be sorrendben. Hagyd ki, vagy csak alaposan próbáld ki.
• Harmadik féltől származó szkriptek kizárása – alapértelmezés szerint ki van kapcsolva, de ez attól függ. Úgy gondolom, hogy a kompromisszum a harmadik féltől származó szkriptek egyesítése (a külső betöltési idő csökkentése), illetve a VS között van, hogy az összesített összevont szkriptek könnyebbek legyenek. Minél több szkriptje van összességében, és/vagy ezek a harmadik féltől származó szkriptek nem befolyásolják az általános terhelést, annál inkább hagyja ki őket. Ellenkező esetben ezeknek a harmadik féltől származó szkripteknek az egyesítése gyorsabb oldalsebesség-pontszámot eredményez, DE lelassítja a valódi felhasználók észlelt betöltési idejét.
• Szkriptek kizárása –  EZTÉRT KÉSZÜLT KÉZI ZÁRJA ki a JavaScript-kérelmeket az egyesítésből. Írjon be egy külön szót vagy szöveges karakterláncot a teljes URL helyett. (pl. a „special” elhelyezése megakadályozza a „https://domain.com/…/special-123.js” betöltését.) A szkriptek kizárásának fő okai 1) a hibás függvények javítása, vagy 2) a szkript betöltődésének fenntartása az eredeti sorrendben, pl. ne egyesítsen egy csúszka szkriptet, hogy az előbb tölthessen be, és gyorsabban jelenítse meg a webhely tetejét. Az egyesített szkriptek általában az oldal végére halasztásra kerülnek. Valószínűleg kizárnék mindent, ami az oldalkészítőjével vagy az űrlapjaival kapcsolatos.
• Footer Scripts – szeretem ezt a funkciót, de még nem használtam. Megakadályozza, hogy a nem kritikus szkripteket előre betöltődő szkriptekkel kombinálják, és tovább késleltesse a kezdeti betöltést. Őszintén szólva, ezeken az apróságokon érdemes gondolkodni, hogy miért nem javaslom a szkriptek összevonását!
• Elhalasztott szkriptek – ne egyesítse ezeket a szkripteket, hanem tartsa halasztva. Jó minden olyan szkripthez, amely problémákat okoz a kombináláskor, de nem szeretné, hogy először betöltsék őket (ha kizárják a kombinálásból).
• Inline Scriptek kizárása – csakúgy, mint fent, csak a beágyazott szkriptek esetében. Lehet, hogy van Google Címkekezelője vagy más szkriptjei, amelyeknek a kód pontos helyéről kell betölteniük (fejléc/törzs/lábléc). Zárja ki őket egy, a kódban található, különálló szöveges karakterlánc beírásával, például „tagmanager” a GTM-hez. Ha nem működik, egyszerűen ne egyesítse a JS-t.
• Footer Inline Scripts – ezzel nem foglalkoznék. Ha benne vannak, annak valószínűleg jó oka van. Ez fejlett cucc!
• Szkriptlokalizációk kizárása – alapértelmezés szerint engedélyezve van, és nem tudom, mi az, ezért békén hagyom.
• Javascriptek minimalizálása – megnöveli a gyorsítótár előépítési idejét, ezt letiltanám, ha sok oldalad van, vagy Cloudflare-t használsz (ami már csinálja).
• Minifikálás API-val – csak akkor jelölje be, ha a fenti alapértelmezett JS kicsinyítési beállítás hibát okoz.
• Proxy 3rd Party Assets – letiltom; ez egy hiúság. Megoldja a hosszabb lejárati időt a harmadik fél JS/CSS-jén (Pingdom/GTmetrix panasz), de tönkreteheti a dolgokat.
• Csökkentett mód – javíthatja a hibákat a JS-kombináció során.
• Külön szkriptek – okos ötlet arra, hogy minden oldalhoz különböző egyesített JS-eket állítsunk elő ahelyett, hogy egy globálisan egyesített JS-t minden oldalhoz (a szkriptek betöltése még azokon az oldalakon is, ahol nem használják őket). Hasznos, ha sok különböző típusú bejegyzésed van (oldalkészítő, termékek, portfólió, galéria, fórumok stb.). Az egyetlen probléma az, hogy késlelteti a gyorsítótár felépítését, és sok helyet elfogyaszthat, ha sok oldala van.
• Egyesített szkriptek nyomtatása soron belül – fantasztikus ötlet a JS betöltésének elhalasztására a végére! Akkor működik a legjobban, ha nincs sok JS-je, és a webhely teteje nem használja a JS-t (menük, képcsúszkák, kritikus előugró ablakok stb.. Ha vannak, zárja ki őket). SZÜKÍTSD MEG, ha a JS-re van szükség a kezdeti oldalelemekhez, vagy szereted-e a gyorsabb előreépítést (mint én).
• Lazy Load Scripts – elképesztő, hogy megakadályozza, hogy a harmadik féltől származó szkriptek lekéssék a webhely betöltését (pl. Tawk.to, hirdetések, kaldera stb.). Gyönyörűen működik, és javítja az oldal pontszámait anélkül, hogy befolyásolná a kezelőfelület működését. Ne használja GA/GTM-hez!
• Include Scripts – Soha nem használtam, de úgy gondolom, hogy olyan szkripteket kell belefoglalnom, amelyeket más, Ön által kizárt szkriptekből hívnak meg.
• Szkriptek blokkolása – blokkolja a szkriptek betöltését. Arra az esetre, ha nincs szüksége rájuk, vagy máshol szeretné átépíteni (például fejlécben vagy láblécben).
• A jQuery Migrate letiltása – minden frissített témákat/bővítményt használó webhely biztonságosan engedélyezheti ezt. A jQuery migrate egy JavaScript-könyvtár a régebbi JS-kódok működésének megőrzéséhez.
• Szkriptek előtöltése – ezzel töltheti be az oldalmegjelenítéshez szükséges lassú/felduzzasztott JS-szkripteket (például a webhely tetején található vizuális elemeket).
• Egyéni fejléc JavaScript – hasznos a JS kézi hozzáadásához a fejléchez a JS-kombinációval kapcsolatos problémák megoldása érdekében. Persze eleve inkább nem kombinálom a JS-t!
• Egyéni lábléc JavaScript – hasznos a JS kézi hozzáadásához a lábléchez a JS-kombináció problémáinak megoldása érdekében. Persze eleve inkább nem kombinálom a JS-t!

Optimalizálás > Stílusok:

• Stílusok egyesítése (más opciók engedélyezése/letiltása) – akárcsak a JS esetében, a  helyedben nem tenném . Az összes CSS-fájlt egy fájlba egyesíti. Van egy furcsa egyensúly; biztonságosabb használni kevesebb stíluslappal (de kisebb hatással), a legelőnyösebb több stíluslappal, de nagyobb az esély a törött stílusokra is. A legjobb megoldás a teljes CSS gyorsítótárba helyezése hosszú lejárati idővel, így a felhasználóknak nem kell folyamatosan letölteniük. A legrosszabb felhasználási mód a GTmetrix/Pingdom pontszámok megszerzése. Mivel a CSS nagyon fontos az oldalmegjelenítéshez, nem javaslom az összevonását (vagy legalábbis ne a témához kapcsolódó CSS-t).
• Kritikus CSS létrehozása – felgyorsítja az „észlelt betöltési időt”, először a webhely tetejét jeleníti meg. Szerintem ez manapság felesleges, FOUT problémákat okoz és lelassítja a teljes betöltési időt. Teszteld be és ki magad. Mindig jobban szeretem. Szerintem a „nem használt CSS” biztonságosabb, de egyben kevésbé agresszív is; míg a nézet gyorsabb, de elhagyhat néhány szükséges stílust. Ez a funkció nagyobb hasznot húz a túlzottan felduzzasztott webhelyeknél.
• Extra kritikus CSS – adjon hozzá minden olyan CSS-t, amelyet mielőbb betölteni kell az oldalbetöltéskor, és amely kimaradt az automatikusan generált kritikus CSS-ből.
• Extra CSS – a kritikus CSS helyett adjon hozzá extra CSS-t a normál CSS-hez.
• Kritikus CSS nyomtatás soron belül – a kritikus CSS-t a fejlécbe helyezi külön fájl helyett. Csak akkor ajánlom ezt, ha a CCSS nagyon kicsi, és/vagy csak nagyon kevés oldal van a webhelyén (például 3). Mert különben szükségtelen CSS-súlyt ad hozzá minden HTML-kérelemhez, amikor a CSS önmagában is gyorsítótárazható lenne statikus eszközként.
• Nyomtasson teljes CSS-t soron belül – nem ajánlom, hacsak az oldal nem rendkívül könnyű.
• Külön stílusok – nagyszerű taktika, amely minden oldalhoz különböző egyesített CSS-t generál az összes oldalhoz tartozó globális CSS helyett (stílusok betöltése még azokon az oldalakon is, ahol nem használják őket). Hasznos, ha sok különböző oldaltípussal rendelkezik (pagebuilder, WooCommerce, fórumok stb.). Az egyetlen probléma az, hogy esetleg késlelteti a gyorsítótár felépítését, és sok helyet foglal el, ha sok oldala van. Inkább csak kisebb weboldalakon, több oldalváltozattal; nagy oldalakat, nem egyesítek.
• CSS minimalizálása – ragaszkodnék az „alaphoz”, ha egyáltalán használni fogom. Válassza a „Nem kicsinyítés” lehetőséget, ha a gyorsabb gyorsítótár-építést részesíti előnyben, és/vagy már engedélyezte a Cloudflare-ből. Nincs hatással a kisebb oldalakra.
• CSS importálás megkerülése – ésszerűbb, ha alapértelmezés szerint engedélyezve van.
• Harmadik fél CSS-jének kizárása – próbálja ki ezt, ha CSS-problémái vannak.
• Stílusok kizárása – manuálisan zárja ki a CSS-t innen, ha CSS-problémái vannak. Írjon be egy külön szót a teljes tartalom URL-je helyett. (pl. a „https://domain.com/theme/special-file.css” helyett a „speciális” szót írja be.) A stílusok kizárásának fő okai 1) a hibás stílus javítása, vagy 2) a gyorsabb betöltése, pl. nem egyesíti a CSS csúszkát, így az töltődik be először, és gyorsabban jeleníti meg a webhely tetejét. Az egyesített stílusok betöltése lassabb, mert meg kell várni, amíg a teljes kombinált CSS betöltődik.
• Inline Styles kizárása – megoldhatja a CSS-egyesítési problémákat. Egyes témák/bővítmények tartalmazzák a beágyazott CSS-t, de a Swift eltávolítja és egyesíti a globális CSS-sel. A soron belüli stílusok visszaállításához írja be a CSS-kódban található külön szöveget. Ha nem tudja, hogyan oldja meg mindezt, egyszerűen ne egyesítse a CSS-t.
• Include Styles – okos, de nem használom. Manuálisan tartalmazza a CSS-t, lehetővé téve, hogy megakadályozza az adott JS betöltését anélkül, hogy elveszítené a benne lévő CSS-hívásokat.
• Stílusok előtöltése – ezzel töltheti be a kulcsfontosságú CSS-fájlokat, ideális esetben az általános tématervhez és az ATF-elemekhez kapcsolódókat.
• Force Swap Font Display (engedélyezi a következő opciót) – véleményem szerint LETILTVA! Megoldja a FOIT problémát azáltal, hogy FOUT problémát ad, ami szerintem sokkal rosszabb UX. (A legtöbb ember ezt használja a magasabb oldalpontszám érdekében.)
• Exclude Force Swap Font Display (Kényszercsere betûtípus megjelenítése ) – a kényszercserebõl kizárandó font-család neve. Jó használati eset lenne az oldal tetején betöltődő menübetűtípusok. Mivel a betűtípus újratöltése különösen idegesítő lenne a látogatók számára.
• A teljes CSS letiltása – ügyes módszer minden szükségtelen CSS letiltására, de légy óvatos! Előfordulhat, hogy kihagyja a szükséges CSS-t, ezért alaposan tesztelje. Ha problémái vannak, próbálja meg hozzáadni a hiányzó CSS-t az „extra kritikus CSS-hez”, vagy teljesen letiltani.
• A kritikus CSS tömörítése – lerövidíti a szuperhosszú CSS-osztályneveket néhány bájt megtakarítása érdekében. Hasznos, ha túlzottan hosszú CSS-osztálynevekkel/azonosítókkal rendelkező beépülő moduljai vannak (pl. „ubermenu-item ubermenu-item-type-post_type ubermenu-item-object-page ubermenu-item-has-children ubermenu-item-9544 ubermenu-item- level-0 ubermenu-column ubermenu-column-auto ubermenu-has-submenu-drop ubermenu-has-submenu-mega”)… lol, igen. Ez egy igazi osztálynév.
• Kulcskockák eltávolítása – távolítsa el a CSS-kulcskocka-animációkat a kritikus CSS-ből. Biztonságos engedélyezni, kivéve, ha a webhely tetején JS helyett CSS-kulcskockákra támaszkodó animációkat vagy diavetítéseket tartalmaz. Csak tesztelje és nézze meg.

Optimalizálások > Betűtípusok:

• Betűtípusok kézi előtöltése – döntse el, milyen betűtípusokat kíván előre betölteni. Valószínűleg nem szükséges IMO. Hacsak nem rendelkezik rengeteg lassan betöltődő betűtípussal.
• Helyi betűtípusok használata – ha bármilyen webes betűtípust tölt be (külső forrásból), akkor ez helyileg menti és betölti azokat. Gyönyörű tulajdonság!
• Helyi betűtípusok kizárása – arra az esetre, ha valamelyiket ki szeretné zárni a helyi tárolásból. Úgy gondolom, hogy ez csak azokra a betűtípusokra vonatkozik, amelyek furcsán jelennek meg az Ön webhelyén, amikor helyileg betöltik, vagy olyan betűtípusokra, amelyeket ritkán használnak vagy hívnak meg az egész webhelyen.
• Force Swap Font Display – tartalék betűtípust jelenít meg, ha az egyéni betűtípusok betöltése túl sokáig tart… elkerülve a FOIT problémát. Ha azonban sok valós tapasztalattal rendelkezik, akkor tudni fogja, hogy a FOIT közel sem olyan rossz, mint a FOUT… ez történik, ha használja ezt a funkciót. Ezért ezt nagyon NEM ajánlom! (Komolyan, gondoljon bele. Minden olyan szöveget, amelyet valóban ilyen gyorsan kell megjeleníteni…, valószínűleg nem szabad tartalék betűtípust használni!)
• Force Swap Font Display kizárása – adott betűtípusok kizárása a csere-tartalék megjelenítési módszerből. Én ezt nem használom, mert egyáltalán nem vesződöm a cserélhető kijelzővel.

Optimalizálások > HTML:

• Érvénytelen HTML javítása – Letiltottam, mert feltételezem, hogy késlelteti a gyorsítótár létrehozását. Csak akkor engedélyezze, ha a webhelyen probléma van.
• HTML minimalizálása – Feltételezem, hogy késlelteti a gyorsítótár létrehozását (és nincs észrevehető előnye), ezért letiltom, ha sok oldalam van vagy lassú a szerverem. A Cloudflare már minimalizálja a HTML/CSS/JS-t is.

Gyorsítótár > Általános:

• Gyorsítótárazás engedélyezése – ezt ENGEDÉLYEZNI kell . Ha nem látja ezt a lehetőséget, vagy akár a „Gyorsítótárazás” lapot sem, akkor valószínűleg a gazdagép letiltja a gyorsítótár-bővítményeket. A WPengine és néhány más gazdagép ezt csinálja.
• Gyorsítótárazási mód – a lemezgyorsítótár újraírással a leggyorsabb, a php-vel rendelkező lemezgyorsítótár valamivel lassabb, de előfordulhat, hogy kevesebb probléma van. Egyes gyorsítótár-bővítmények (CometCache) a php útvonalat részesítik előnyben. Azt állítják, hogy jobb, de engem csak az érdekel, mi a leggyorsabb. A PHP-vel való memcached-nek szintén nagyon gyorsnak kell lennie, de a tárhely környezetétől függ. A Memcached jobban működik VPS-en, mint megosztott tárhelyen.
• Early Loader – ellenőrizni kell.
• Gyorsítótár elérési útja – ellenőrizze ezt a könyvtárat, ha a gyorsítótárazás vagy az előépítés nem működik; lehet, hogy rossz elérési út a régi szerverről. (A megfelelő elérési útért lépjen a cPanel „Fájlkezelő” oldalára.)
• Gyorsítótár lejárati mód – a webhelyek 99%-ánál jobban szeretem a „műveletalapú módot”. Kiválaszthatja az „Időalapú módot”, ha webhelyén gyakran vannak nem tartalmi frissítések (például új megjegyzések vagy a termékállapot változásai).
• Nonce megkerülése – csak akcióalapú lejárati mód használata esetén érhető el. Alapvetően a nonce élettartam meghosszabbítása, hogy megfeleljen a gyorsítótár lejáratának. Néha a webhelyfunkciók (pl. a gyorsítótárazott űrlapok) nem működnek megfelelően, mert a nonces beépülő modul lejár a gyorsítótár lejárta előtt. Ez a funkció megoldja ezt a problémát.
• Gyorsítótár lejárati ideje – általában az Action Based Mode-ot használom a lejáratra, ami alapvetően az „örökké” lejárati idő. Tehát ha időalapú lejárati módot használ, akkor válassza ki azt az időközt, amikor úgy gondolja, hogy a webhely gyorsítótárát frissíteni kell. Ez a te hívásod.
• A Nonce Life kiterjesztése – néha a webhelyfunkciók (pl. a gyorsítótárazott űrlapok) nem működnek megfelelően, mert a nonces beépülő modul lejár a gyorsítótár lejárta előtt. Ez a funkció megoldja ezt a problémát.
• Törölje a gyorsítótárat az oldalankénti bejegyzés frissítésénél – nem használom. A Swift gyakran törli a gyorsítótárat.
• Gyorsítótár törlése a frissítési bejegyzésnél URL alapján – Soha nem kellett ezt használnom, mivel a műveletalapú módot használom, amely automatikusan törli a változtatásokat. Az időalapú módot használó emberek minden olyan oldalt törölhetnek, amely dinamikus tartalmat mutat. (Például a kezdőlap vagy a blogkategória oldalainak törlése, hogy azokon a legfrissebb bejegyzések jelenjenek meg.)
• Gyorsítótár törlése a bejegyzés frissítésénél egyéni szabállyal – sokkal hatékonyabb regex/wildcard mód több oldal egyéni törlésére a bejegyzések frissítésekor.
• Gyorsítótár törlése frissítés után – valószínűleg jobb, ha ezt ENGEDÉLYEZVE hagyja. Érdemes lehet letiltani, ha a webhely hatalmas (örökké vagy sok szervererőforrást vesz igénybe az előtöltéshez), és olyan sok témát vagy beépülő modult tartalmaz, amelyek automatikusan frissülnek.
• Gyorsítótárazás engedélyezése a bejelentkezett felhasználók számára – a biztonság kedvéért csak akkor engedélyezze, ha sok bejelentkezett felhasználója van. Ne engedélyezze a „Bejelentkezett gyorsítótár megosztása” funkciót, hacsak nem minden bejelentkezett felhasználónak ugyanazt a tartalmat kell látnia, különben keresztezi a felhasználói adatokat (pl. A felhasználó látja B felhasználó adatait). A fiók/profil oldalakat általában ki kell zárni a gyorsítótárazásból!
• Külön mobileszköz gyorsítótár – tiltsa le! Csak akkor használható, ha engedélyezve van az AMP témán/bővítményen, vagy speciális kialakításon vagy mobillátogatók számára készült hirdetéseken keresztül. Ha nem tudja, mi az AMP, ne engedélyezze!
• Böngésző gyorsítótár engedélyezése – engedélyezze! Segíti a teljesítményt.
• Gzip engedélyezése – hagyja engedélyezve!
• 304-es fejléc küldése – letiltása.
• 404-es oldalak gyorsítótárazása – csak akkor engedélyezze, ha kicsi a webhelye, és/vagy gyakran felkeresik ugyanazokat a nem létező URL-eket. Ellenkező esetben gyorsan eltömítheti a bemelegítő asztalt.
• Gyorsítótár webhelytérkép – tetszik ez a funkció! Adjon meg egy webhelytérkép URL-t, hogy az előtöltő intelligensebben tárolja a dolgokat. A régi időkben a Swift véletlenszerűen kereste az Ön webhelyét URL-ek után, és gyakran először a nem fontos oldalakat töltötte be előre.
• Engedélyezze a dinamikus gyorsítótárazást – a Swift egyik elképesztő fejlett funkcióját, most hagyja békén. (Fejlesztőknek és profiknak készült.) Gyorsítótárat tud tárolni, vagy lehetővé teszi az olyan funkciókkal való kompatibilitást, mint a több pénznem stb. Ezt később elmagyarázom.
• Gyorsítótárazható AJAX-műveletek – egy másik hihetetlen fejlett funkció. Hagyják békén.
• AJAX gyorsítótár lejárati ideje – hagyja békén… hacsak nem tudja, hogy hosszabb ideig szüksége van rá.
• Lekérdezési karakterlánc figyelmen kívül hagyása – hagyja ezt bejelöletlenül!

Gyorsítótár > Tweaks:

• Enable Proxy Cache – érdekes funkció, amit még nem használtam. A Cloudflare „mindent gyorsítótáraz” szabályát használja az oldalak gyorsítótárazásához és a szupergyors betöltéshez. Az egyetlen probléma az, hogy hogyan lehet törölni ezeket az oldalakat változások vagy frissített információk esetén.
• Proxy Cache Maxage – „max-age”-nek kell írnia. Az alapértelmezett beállítás egy nap. Jónak tűnik, de a hosszabb is megfelelő, ha a webhely nem frissül sokat.
• Csak proxy gyorsítótár – a gyorsítótárazott fájlokat csak a proxyra menti. Ez egy jó módja annak, hogy lemezterületet takarítson meg nagy webhelyek vagy korlátozott tárhelycsomaggal rendelkező webhelyek számára. De feltételezem, hogy a webhelye lassabban töltődik be, ha a proxy-gyorsítótár törlődik, és nincs helyi gyorsítótár?
• GET paraméterek figyelmen kívül hagyása – ezzel bizonyos URL-paramétereket figyelmen kívül hagyhat. Az összes szabványos FB, UTM, GA alapértelmezés szerint figyelmen kívül marad. De előfordulhat, hogy az Ön által használt hirdetési hálózatoktól vagy harmadik felek hivatkozásaitól több is érkezik.
• Kerülje a vegyes tartalmat – letiltva. Problémákat okozhat az eszköz URL-jeinél! Csak akkor szükséges, ha webhelye továbbra is HTTP-t használ, de van néhány harmadik féltől származó HTTPS-kérelem (például a GoogleMaps). A legtöbb webhely már teljes HTTPS-t használ!
• Az eredeti fejlécek megtartása – engedélyezve hagyom.
• Fejlécek kizárása – adott fejlécek kizárása a gyorsítótárazott oldalakról.
• Kis- és nagybetűket nem ismerő URL -ek – letiltva hagyom. Soha nem volt rá használati lehetőség. Minden URL-nek kisbetűsnek kell lennie.
• Strict Host – alapvetően csak a webhelydomain egy verziójához hoz létre gyorsítótárat (www-vel vagy anélkül). Ez valószínűleg segít megelőzni a problémával kapcsolatos megjelenítési problémákat, de tárhelyet is megtakarít. Jó ötlet használni, de ügyeljen arra, hogy állandó webhely-átirányítást biztosítson, hogy a felhasználókat a webhely domainjének megfelelő verziójára kényszerítse.
• Ajaxify Placeholder – megjeleníti a lusta betöltött elemeket. Használhatja az alapértelmezett „rejtett” beállítást, amely üres a betöltésig, vagy egy „elmosódott” mezőt, mint például a Közepes, vagy a „gyorsítótárban lévő megjelenítést”, amely a gyorsítótárazott verziót mutatja, amíg az nem frissül az élő verzióra.
• A lekérdezési karakterlánc figyelmen kívül hagyása – nem használom. A lekérdezési karakterláncokat tartalmazó URL-ek okkal léteznek… kockázatos figyelmen kívül hagyni őket, ha nem tudod, mit csinálsz.

Gyorsítótár > Ajaxify:

WOW, ez az egész rész rettenetesen menő és okos!!!

• Lazyload Shortcodes – csak olyan rövid kódokhoz használja, amelyeket nem használnak ATF-tartalomhoz.
• Lazyload Template Parts – nagyon okos! Gyakorlatilag lusta berakhat mindent az ATF alá. Ügyeljen arra, hogy ne befolyásolja a SEO-ját.
• Lazyload Nav Menus – bármely menühöz használható, kivéve azokat, amelyek a webhely tetején töltődnek be.
• Lazyload Blocks – a legnehezebb/legkésettebb Gutenberg-blokkjainak lusta betöltésére használja, vagy azokat, amelyek rossz oldalpontszámot okoznak.
• Lazyload widgetek – a lassú betöltésű vagy rossz oldalpontszámokat okozó widgetek lazyload pozíciói.
• Előtöltési érzékenység – határozza meg, hogy mennyi időn belül kell betölteni a lusta betöltött elemeket, amikor a felhasználó rájuk görget. Az 50 pixeles alapértelmezett beállítás rendben van, de bármikor növelheti, ha a felhasználók gyorsan görgetnek (és szeretné, hogy a képek hamarabb megjelenjenek).
• Ajaxify Placeholder – megjeleníti a lusta betöltött elemeket. Használhatja az alapértelmezett „rejtett” beállítást, amely üres a betöltésig, vagy egy „elmosódott” mezőt, mint például a Közepes, vagy a „gyorsítótárban lévő megjelenítést”, amely a gyorsítótárazott verziót mutatja, amíg az nem frissül az élő verzióra.
• Lazyload elemek – okos taktika a lazyload használatával a webhely azon részei dinamikus betöltésére, amelyeket nem szabad gyorsítótárazni. Például: legutóbbi megjegyzések, kapcsolódó bejegyzések, nemrég megtekintett termékek, űrlapok stb. Bárki, aki objektum-gyorsítótárat szeretne, vagy oldala bizonyos részei gyorsítótárának törlésére vágyik, használhatja ezt a funkciót.

Gyorsítótár > Kivételek:

• Bejegyzéstípusok kizárása – minden bejegyzéstípust ki kell zárni, KIVÉVE a bejegyzéseket, oldalakat, termékeket, és minden olyan bejegyzéstípust, amely a kezelőfelületen saját egyedi URL-jellel jelenik meg. (Ha nem zár ki egyetlen bejegyzéstípust sem; a webhely az összes elemet akkor is gyorsítótárazza, ha azok nem jelennek meg a kezelőfelületen, tovább késleltetve a gyorsítótár-előkészítést a kritikus elemekhez. A nagy webhelyeknek mindenképpen ki kell zárniuk a felesleges bejegyzéstípusokat!) Pro tipp: gyorsabb beírni az elemek első betűjét vagy megnyomni a lefelé mutató nyilat a billentyűzeten, mint körbe-körbe kattintani.
• Oldalak kizárása – ki kell zárnia minden olyan oldalt, amelyek „élő információval”, „privát adatokkal” rendelkeznek, vagy amelyek gyorsítótárban nem működnek megfelelően. Jó példák erre az űrlapokat tartalmazó oldalak, a dinamikus WooCommerce (számla, kosár, pénztár, kívánságlista), a divatos értékesítési oldalak (követő szkriptekkel) és bármely más dinamikus/privát oldal.
• URL-ek kizárása – zárjon ki minden olyan URL-t, amelyet nem lehetett kiemelni a fenti bejegyzéstípusok vagy oldalak használatával. A REGEX segítségével egyszerre több URL-t is kizárhat. (Erősen javaslom a „#revision#”, „#autosave#” és „#json#” hozzáadását ide, hogy megakadályozzuk ezeknek az elemeknek a gyorsítótárazását. Hozzáadhat „/feed”-et vagy másokat is.)
• Cookie-k kizárása – megakadályozza, hogy a megadott cookie-kkal rendelkező felhasználók lássák a gyorsítótárazott oldalakat. Hasznos élő/frissített oldalak megjelenítéséhez bizonyos felhasználók számára.
• Tartalmi részek kizárása – hasznos bizonyos tartalmak vagy bejegyzéstípusok kizárásához, amelyek több oldalon jelennek meg. Írjon be külön szöveget, hogy bizonyos tartalmak ne kerüljenek gyorsítótárba.
• Felhasználói ügynökök kizárása – megakadályozza, hogy bizonyos eszközök lássák a gyorsítótárazott oldalakat.
• Feltérképező robotok kizárása – megakadályozza, hogy meghatározott keresőmotorok vagy bejárók lássák a gyorsítótárazott oldalakat. Látják a nem gyorsítótárazott oldalakat a legfrissebb tartalommal, de növelhetik a szerverterhelést is, ha gyakran látogatnak.
• Szerzői oldalak kizárása – ezt bejelölöm. A szerzői oldalakat nem látogatják gyakran, ezért a gyorsítótárazási mechanizmust más oldalakra összpontosítsa.
• Archívum kizárása – Jobban szeretem az UNCHECKED. A blogkategória oldalait gyakran látogatják, és ha nem tárolják a gyorsítótárban, lassan futnak. Ha nem gyorsítótárazza őket, akkor a legfrissebb bejegyzések megjelennek, de ez szükségtelen, mivel a Swift gyakran újraépíti a gyorsítótárat.
• REST URL-ek kizárása – ELLENŐRIZVE. Nem kell ezeket az elemeket előre gyorsítótárazni.
• Hírcsatorna kizárása – ELLENŐRIZVE. Nem kell ezeket az elemeket előre gyorsítótárazni. Elég gyorsan betöltődnek, és nem látogatják gyakran. Ráadásul megduplázhatja a gyorsítótár-táblázat elemeinek számát (milyen rendetlen).

Gyorsítótár > Bemelegítés:

• Gyorsítótár automatikus előépítése – általában be van jelölve, a Swift egyik legfontosabb funkciója. (Csak olyankor ne használja az előépítést, amikor annyi oldala van, például több mint 1 000, a szerver mindig az előépítéssel van elfoglalva, vagy olyan nagy a forgalom, hogy már előre felépítik az oldalakat.)
• Előkészítési sebesség – mindig próbálja meg a „Korlátlan” opciót használni, ha saját szervere/VPS-je van, vagy nincs sok oldala (400 vagy kevesebb). Ha erőforráskorlátozott megosztott tárhelyet használ, válasszon egyet a többi lehetőség közül, különben a gazdagép megbüntetheti Önt „Magas CPU/erőforrás használat” miatt.
• Fedezze fel az új oldalakat – jobb, ha nincs bejelölve, de engedélyeznie kell ezt, ha a Swift nem találja meg az összes oldalt. Az egyetlen probléma az, hogy néha sok szükségtelen elemet gyorsítótáraz, de így is kizárhatja őket.
• Warmup Table Source – az automatikus kisebb vagy könnyű, kevés oldalas webhelyekhez megfelelő. De ha sok oldala van és/vagy lassú a szervere, akkor erősen ajánlom az oldaltérkép opciót, hogy először a fontos oldalakat részesítse előnyben. Néha a Swift előkészítő mechanizmusa az alacsony prioritású elemeket helyezi előtérbe (például a címkéket), ami azt jelenti, hogy a kulcsoldalak tárolása hosszabb ideig tart a törlés után.
• URL-oldal oldal – döntse el, hogy hány URL jelenjen meg a bemelegítő táblázatban. Magasabb szám, ha gyors szerveren dolgozik és/vagy rengeteg oldallal rendelkezik. Alacsonyabb szám, ha a bemelegítő oldal betöltése örökké tart.
• Bemelegítési prioritás – ezt el lehet húzni, de az alapértelmezett beállítás a legjobb IMO!
• Távolítsa el az átirányításokat – ezt valószínűleg engedélyezni kell. És ha látja őket, meg kell találnia és le kell cserélnie ezeket az elavult URL-karakterláncokat webhelye adatbázisában.
• Szerzői oldalak előépítése – UNCHECK. Ez az opció előre gyorsítótárazza a szerzői oldalakat, de én inkább csak akkor tárolom a gyorsítótárban, ha ténylegesen meglátogatják őket.
• Előkészített archívum – ezt ELLENŐRIZNI kell az előre gyorsítótárazott kategóriaoldalakon.
• Kifejezések előkészítése – csak akkor ellenőrizze, ha úgy gondolja, hogy a felhasználók gyakran kattintanak a kifejezésoldalakra (pl. címkék). Ellenkező esetben hagyja letiltva, ha azok közé a webhelyek közé tartozik, amelyek csak 100 bejegyzést tartalmaznak, de 1000 címkét! (Alapvetően nem szeretné, hogy az előre elkészített idő a tartalom helyett a címkeoldalak gyorsítótárazására pazaroljon.)
• REST URL -ek előre elkészítése – nálam nincs bejelölve. Ezeket nem szükséges előre megépíteni.
• Prebuild Feed – nálam szintén nincs bejelölve. Nem szükséges!
• Távoli előre elkészített gyorsítótár engedélyezése (prémium) – általában LETILTVA! Csak akkor használja, ha a kiszolgáló nem tudja meglátogatni magát, és nem tudja előépíteni a gyorsítótárat; talán azért, mert letiltottad a botokat vagy az indexelést? A beállítástól függően felgyorsíthatja vagy lelassíthatja az előépítést, gyakran javítva az előépítéssel kapcsolatos problémákat.

Gyorsítótár > Lakk:

• Automatikus tisztítás engedélyezése – engedélyezze, ha lakkot használ. Automatikusan törli a Varnish gyorsítótárát, így nem kell minden alkalommal manuálisan megtennie, amikor a Swift törli a gyorsítótárat.
• Egyéni gazdagép – általában nem szükséges, hacsak nem Cloudflare-t vagy más DNS-proxyt használ. Ide írja be a Varnish szerver IP-címét és portját.

Gyorsítótár > Appcache:

Hihetetlen funkció, de 99,99%-otok nem szabad ezzel foglalkozni!!! Lelassíthatja az előépítést anélkül, hogy észrevehető előnyökkel járna. A funkció az első látogatáskor letölti webhelyét a felhasználó böngészőjébe, jelentősen felgyorsítva a navigációt. Tartsa szem előtt az eszközök alapértelmezett appcache-méretét (100 MB asztali számítógépen, 5 MB mobil esetén) a hivatalos Swift-dokumentáció szerint.

A 100 MB-os asztali korlát valójában a legtöbb kisebb webhelyen elfér ( főleg , ha nem egyesíti a CSS-t/JS-t). Az 5 MB-os mobilkorlát belefér a teljes webhelyre, de lehet, hogy nem. Van, ahol jól jön, ha csak bizonyos oldalakat tárol el. Őszintén szólva, ez az alkalmazásgyorsítótár funkció önmagában olyan szépen átgondolt, hogy lehetett volna saját beépülő modulja vagy legalábbis fizetős kiegészítő. Örökké hálás vagyok a Swiftnek, amiért olyan különleges funkciókat tartalmazott, mint ez!

PS: Egyáltalán nem használok appcache-t a saját webhelyeimhez! A Swift rendszeres gyorsítótárazási funkciói elképesztőek voltak! (Emellett a webhelyeim már szuper karcsú kódolásúak.)

• Enable Appcache for Desktop – jelölje be a funkció engedélyezéséhez.
• Appcache mód – a webhely méretétől függ. Válassza a „Teljes webhely” lehetőséget, ha a teljes webhely gyorsítótár 100 MB-on belül elfér, vagy használja az Oldalak kizárása funkciót az elhelyezéshez. Válassza a „Csak meghatározott oldalak” lehetőséget, ha webhelye jóval nagyobb, mint 100 MB, vagy csak bizonyos oldalakat részesít előnyben az alkalmazás-gyorsítótár számára… majd használja az Oldalak belefoglalása funkciót a kiválasztásához. Szerintem a legtöbb webhelynek csak a fő oldalakat kellene kiválasztania. Ez lehetővé teszi az alkalmazásgyorsítótár gyorsabb felépítését/betöltését a felhasználók böngészőibe, a leglátogatottabb oldalakra összpontosítva. (Tájékoztatás: a webhely gyorsítótárának mérete a Swift Dashboardon található.)
• Asztali maximális mérete – nem biztos benne, hogy ez hogyan vonatkozik. békén hagyom.
• Oldalak kizárása – okos kiegészítés! Nagyszerű, ha kizárja a szükségtelen oldalakat az asztali alkalmazás gyorsítótárából. Emlékeztető: az asztali alkalmazás gyorsítótára összesen 100 MB-ot tesz lehetővé.
• Karakterláncok kizárása – az URL-karakterlánc alapján az elemeknek az asztali alkalmazásgyorsítótárból való kizárásának hatékonyabb módja.
• Enable Appcache for Mobile – jelölje be az engedélyezéshez. (MEGJEGYZÉS: több adatot használ.)
• Appcache mód – mivel a mobilalkalmazás-gyorsítótár korlátja csak 5 MB, valószínűleg a „Csak meghatározott oldalak” opciót kell használnia, és ki kell választania a legfontosabb oldalakat.
•  Mobil Max Size – nem vacakolok vele.
• Oldalak kizárása – nagyon hasznos, mivel a mobilalkalmazás-gyorsítótár mindössze 5 MB-os, ezért csak a legfontosabb oldalakat válassza ki.
• Karakterláncok kizárása – ismét használja, hogy kizárjon elemeket a mobilalkalmazás-gyorsítótárból.

Beépülő modulok:

Mint mindig, a Swift ismét egy következő szintű szarban van! Speciális optimalizálási beállításokkal rendelkeznek, amelyek megmutatják, ha bizonyos bővítmények telepítve vannak.

• Érintkező Forma 7> Smart Enqueue Assets – Szeretem! Az egyik leghosszabb álló panaszom a CF7-ről az volt, hogy minden oldalra betölti a CSS / JS-t, még akkor is, ha nem használja az űrlapokat! Mindig is elmondtam mindenkinek, hogy átkapcsoljon Caldera-ra, de ezzel a beállítással nem kell (ha szereted a cf7-et). Engedélyezze ezt, de óvatosan ellenőrizze, ha a SWIFT nem érzékeli megfelelően az összes CF7 űrlapot. Mégis azonban át kell váltani Caldera-ra!
• Elrendor> Lazyload YouTube háttér – Engedélyezze ezt, hacsak a videó beágyazásait használja a webhely hős részében. Egy másik lehetőség, akkor engedélyezze ezt, de használják a lazyload kizárási attribútumait a hős beágyazza.
• WooCommerce > Cache Empty Minicart – engedélyezze!
• WooCommerce > Kosártöredékek letiltása (prémium) – Általában letiltom! Felgyorsítja azt a bosszantó WooCommerce admin-ajax hívást, amely késlelteti a vízesés jelentéseit, DE letiltja a minikosár számlálását (a kis szám a kosár ikonjában a webhely tetején). Minden oldalon letilthatod, csak egyeseken letilthatod, vagy bekapcsolva hagyhatod, ha nem nagyon érinti az oldalt/szervert. A te döntésed. (Igen, ez a funkció helyettesítheti a LittleBizzy Kosártöredék letiltása bővítményét.)
• WooCommerce > WooCommerce Session Cache (BÉTA – prémium) – tiltsa le. Gyorsítótárazza a felhasználók bevásárlókosárban lévő tételeit, de nem működik tökéletesen. A webhely néha lassabbnak tűnik, ha ez be van kapcsolva, és néha összekeveri a kosár munkameneteit a felhasználók között. Gondosan tesztelje, ha használja.
• Woocommerce> Ajaxify árak – csak akkor szükséges, ha webhelye különböző árait mutatja a különböző felhasználóknak (például a helyszínen alapuló, stb.). IT Lazyloads árak Az Ajax-ot használja a gyorsítótárazott oldaladatok után.

CDN:

• Általános > CDN engedélyezése – ellenőrizze, hogy CDN-t használ-e. Ez a funkció NEM helyettesíti a CDN-bővítményt; hagyja engedélyezve a CDN-bővítményt, ha rendelkezik ilyennel. A Swift CDN-beállításai csak a CDN tisztítására szolgálnak, aktiválására nem! (PS: A Cloudflare nem tekinthető a hagyományos értelemben vett CDN-nek; használja inkább a Cloudflare lapot.)
• Általános > CDN gazdagépnév – adja meg a gazdagépnév URL-jét a „https://” nélkül. Valami ilyesminek kell lennie: „cdn.sajatdomain.com” vagy „sajatdomain.cdn-neve.com”.
• Általános> Különböző gazdagépnevek használata – Abban az esetben, ha a CDN más gazdanevet használ az eszközök SSL tartományi verziójához. Soha nem láttam ezt.
• Általános > SSL CDN gazdagépnév – valószínűleg üresnek kell lennie, mivel a legtöbb CDN ugyanazt a gazdagépnevet használja, függetlenül a http vagy https protokolltól.
• Általános > CDN egyéni fájltípusok – adja meg, hogy mely fájlok (bővítmények) legyenek gyorsítótárazva a CDN-n. Nem értem, miért van erre szükség, nem tudom, hogy ez egy fehérlista vagy mi. Tesztelje vele és anélkül, és nézze meg.
• Általános> kizárja a fájltípusokat a CDN-ről – kizárja a fájlokat a CDN-ről különböző okokból. Talán a CDN-költségek miatt, vagy azért, mert a fájl gyorsabban (vagy megbízhatóbb) van betöltve a kiszolgálón?
• CloudFlare> Automatikus tisztítás engedélyezése – Ellenőrizze, ha CloudFlare van. Ellenkező esetben a CloudFlare gyorsítótárat manuálisan kell megadnia, amikor módosítja a webhelyét vagy a gyorsítótárat. (Győződjön meg róla, hogy megadja a fiók e-mailjét és az API kulcsát .)
• CloudFlare> CloudFlare auth módszer – Azt hiszem, attól függ, hogy melyikéhez tartozik .
• Cloudflare> Cloudflare fiók e-mail – Töltse ki a fiók e-mail címét.
• Cloudflare > Cloudflare API-kulcs – írja be a Cloudflare globális API-kulcsát .
• Cloudflare > Cloudflare Host – adja meg domain nevét (a www nélkül).
• MaxCDN (StackPath) > Alias/Key/Secret – töltse ki, ha MAXCDN-t használ.

Import Export:

Soha nem használom ezt, mivel a különböző webhelyek beállításai eltérőek. A Swiftet egyébként 2 perc alatt be tudom állítani. **TIPP: a beállítások importálásakor ellenőrizze a „Gyorsítótár > Általános > Gyorsítótár elérési útja” lehetőséget, hogy megbizonyosodjon arról, hogy a megfelelő címet adja meg.

• Import/Export from FILE – a legbiztonságosabb lehetőség, letölti a beállításokat a számítógépére. Fájl importálásához először nyissa meg a számítógépén a kódszerkesztővel (például Notepad++ Windows rendszerben vagy TextWrangler OSX rendszerben), másolja ki az összes szöveget, majd írja be a Swift importálási mezőjébe.
• Importálás/exportálás URL -ből – a leggyorsabb lehetőség, gyorsan átmásolhatja a beállításokat egyik webhelyről a másikra. (Ismét ne felejtse el ellenőrizni a gyorsítótár elérési útját!)

Nyomja meg a [VÁLTOZÁSOK MENTÉSE] gombot, törölje a gyorsítótárat, és kész a Swift beállítása!

Játsszon a kezelőfelülettel (inkognitó böngészőben vagy bármely olyan böngészőben, amelyik nincs bejelentkezve), és tesztelje a sebességet. Vagy folytassa az olvasást, ha további teljesítményt szeretne elérni.

3. LÉPÉS – Ellenőrizze a bemelegítési táblázatot

Ellenőrizze a SWIFT Warmup Table-t, hogy megbizonyosodjon arról, hogy az összes oldalát gyorsítótárazza-e.

1. Kattintson a Swift Performance linket az Ön dashbar (felső) vagy admin oldalsó panel (bal) Eszközök> Swift Performance.
2. GÖRGÖZSEN LE a Warmup Table -ig , és nézze meg, hogy gyorsítótáraz-e minden tartalmat (bejegyzéseket, oldalakat, termékeket stb.). A nagy webhelyek több időt vesznek igénybe.
3. GYORSÍTÁSI KATEGÓRIÁK – ha egyes kategóriaoldalak alapértelmezés szerint nem tárolnak gyorsítótárat, engedélyezze a gyorsítótár beállításainál az „Előre épített archívumot”.
4. Várja meg a Prebuild -ot – A Prebuilds automatikusan futnia kell, de ha nem, kattintson a „Prebuild Cache” gombbal, vagy akár „Reset Warmup table”. A webhely méretétől függően percekig órákig tarthat. Szinte készen állsz repülni!
5. A gyorsítótár nem épül fel? – Ne fújjon ki, ha látja a furcsa URL-t, vagy hogy nem minden oldal tárolódott. Ez normális viselkedés és fantasztikus, hogy a SWIFT rendelkezik ezzel a felmelegedési táblával, hogy diagnosztizálja a problémákat. (FYI: Sok más gyorsítótárpugasz nem kap semmit sem, de hiányzik egy kényelmes asztal, hogy tudd ezt.) Diagnosztikai lépésként manuálisan kattintson a „Cache oldal” gombra a nem kívánt elemekre, vagy meglátogathatja őket a Elülső vég.
6. ELLENŐRIZZE, hogy webhelye gyorsítótáraz -e – nyissa meg a Chrome inkognitóablakát, és bejelentkezés nélkül keresse fel webhelyét. Kattintson a jobb gombbal bárhová, és kattintson az „Oldal forrásának megtekintése” elemre, majd görgessen lefelé. Ha a „Cached with Swift Performance Lite” üzenetet látja, akkor működik! *EGÉSZSÉGÉRE*

4. LÉPÉS – Problémák tesztelése

A bejelentkezés nélkül keresse meg webhelyét az asztalon és a mobilon. Mindennek kell lennie gyors, nézd meg és működjön normálisan. Ha minden tökéletes, ugorjon a következő lépésre. Ha valami megtört, akkor mindig 99% szinte mindig azért, mert engedélyezte az „Merge Scripts / Styles” lehetőséget. (Ha azt szeretné, hogy tanácsom, ne keverje össze a CSS / JS -t .)

Broken Styling problémák? (általában Woocommerce Stores vagy PageBuilders)
… vagy törött funkcionalitás? (formák, csúszkák vagy dolgok, amelyek nem működnek, amikor kattintanak) … Olvassa el az alábbiakat:

1. Nyissa meg a Beállítások > Optimalizálás > Szkriptek/stílusok menüpontot
2.  A „Szkriptek egyesítése” és a „Stílusok egyesítése” letiltása
3. Próbálja újra a kezelőfelületet. Ha minden működik, itt megállhat (a gyorsítótárazás továbbra is nagyon gyors lesz), vagy folytathatja az elkülönítést és a probléma megoldását.

Néhányan továbbra is ragaszkodnak az összevonáshoz, mert azt a hiúsági oldal pontszámot akarják. Ugh… mondom, ez nem a teljesítmény legjobb gyakorlata! De a következőket teheti, ha ragaszkodik hozzá:

1. Egyenként engedélyezze újra a „Szkriptek egyesítése”, majd a „Stílusok egyesítése” lehetőséget a probléma elkülönítéséhez.
2. Általában csak egy CSS-stíluslap vagy egy JS-szkript okozza a problémát. Megpróbálhat játszani a többi szkript/stílus optimalizálási lehetőséggel, hogy megnézze, megoldják-e a problémát, de ez nekem soha nem működött. A megfelelő módszer az, hogy kizárja a problémás CSS/JS-t (bármelyik is az) az összevonásból.

A problémás szkriptek/stílusok megkeresése és kizárása az egyesítésből:

1. 1. elkülönítési módszer – hagyja engedélyezve a MERGE SCRIPTS-t és/vagy MERGE STYLES-t, nyissa meg a webhelyet a Chrome > Fejlesztői eszközök > Hálózat (lap) menüpontban, és töltse be újra az oldalt. Kattintson a kis piros hibakörre, hogy megnézze, melyik CSS/JS hiányzik. Zárd ki őket az összevonásból, és nézd meg, működnek-e a dolgok.
2. 2. elkülönítési módszer – tiltsa le a MERGE SCRIPTS-t és/vagy a MERGE STYLES-t (vagy akár a gyorsítótárat is), és ellenőrizze webhelyét a Pingdomban . Görgessen le a vízeséshez, és rendezze a betöltött elemeket fájltípus szerint (az összes CSS/JS rendben megjelenítésével). Most térjen vissza a Swift beállításaihoz, és egyesítse újra a szkripteket/stílusokat, de manuálisan zárja ki azt a CSS/JS-t, amelyről úgy gondolja, hogy a problémát okozza. (Tipp: bármi is tönkremegy, valószínűleg a problémához kapcsolódik. Egy bizonyos bővítmény vagy témafunkció nem működött? Próbáld meg letiltani ezeket a  CSS-eket/JS-eket.) Igen, sok próbálkozást és hibázást igényel. Bárhol lehet; talán egy plugin, esetleg egy téma.

Sok mindent nem írok le, mert ez nagyon technikai jellegű, és haladó felhasználóknak kell kezelniük. Ha ekkora problémái vannak a CSS/JS egyesítésével, akkor ezt nem szabad megtennie. Ez senki hibája… nem a tiéd, nem a gyorsítótár-bővítmény, sem a többi beépülő modul/téma. (Természetesen kipróbálhat egy másik CSS/JS egyesítési bővítményt, például az Autoptimize-t, és lehet, hogy működni fog a jelenlegi beállításnál, de aztán egy másik napon megszakad.) Tényleg nem ajánlom a CSS/JS összevonását!

A helyzet az, hogy minden WordPress-bővítmény működéséhez saját kódkészletre van szükség, és ha különböző kódokat kever össze, konfliktusok léphetnek fel. A hosszú távú legjobb gyakorlatok érdekében semmi esetre sem érdemes összevonni a CSS/JS-t!

5. lépés – Egyéb jellemzők

Szívesen megtekintheti a többi eszközt is, de ügyeljen arra, hogy legyen óvatos, és készítsen biztonsági másolatot, ha nem tudja, mit csinál. Ezeket egy fejlettebb útmutatóban fogom áttekinteni!

• Képoptimalizáló (prémium) – Én jobban szeretem a ShortPixelt, de ez is működik.
• Adatbázis-optimalizáló – hasznos, de vigyázz, nehogy összetörjön! A sebességet nem befolyásolja nagyban, hacsak nincs több ezer automatikusan betöltött tranziens. Inkább az adatbázis méretének csökkentését szolgálja, mint a sebességet. (Igen, ez helyettesítheti a WP Optimize-t.)
• Kritikus betűtípus (prémium) – igazán okos funkció! Nem hiszem el, hogy Swift erre gondolt… ha minden egyedi ikonfont szolgáltatás ilyen egyszerű lenne! A legtöbb felhasználó számára ez segít, ha Font Awesome 4.x vagy régebbi verziója van. Csak a szükséges ikonok felhasználásával állítja elő újra az ikon-betűtípusokat, így nem vesztegeti a 150 ms-ot a teljes, 5000 ikonból álló Font Awesome könyvtár betöltésével minden oldalon. (Az újabb FA 5 SVG-t használ.)
• Plugin Organizer – egyszerűen hihetetlen funkció, és melengeti a szívemet. Nem hiszem el, hogy ezt ingyen adták. Prémium bővítménynek kell lennie, vagy legalábbis nem hagyhatja figyelmen kívül a közösség. Könnyen használható, de gyorsítótárazási szempontból ezt a fejlett gyorsító stratégiát tartom szem előtt, ezért ebben az útmutatóban nem térek ki rá.
• Frissítsen PRO-ra – meg kell tennie? Megéri? Csak azért, hogy támogassa ezt a hihetetlen bővítményt, igen, megéri. De ami azt illeti, hogy mely funkciók érik el a legnagyobb hatást… Számítási API (csökkenti a szerver CPU-használatát), Távoli előépítés engedélyezése (sok nehéz gyorsítótárazási problémát megold), Képoptimalizáló (pénzt takaríthat meg a képoptimalizálással), WooCommerce gyorsítótár (további szolgáltatások), Whitelabel (elrejtés) a gyorsítás titkai), kritikus betűtípus (felgyorsítja a régebbi FontAwesome-ot).

6. LÉPÉS – Végső funkciók ellenőrzése

Győződjön meg róla, hogy semmi sem törött!

• Törölje a gyorsítótárat, és törölje le a CDN-t vagy a Varnish-t is (ha van).
• Várja meg, amíg a gyorsítótárazás befejeződik, majd ellenőrizze az összes oldalt.
• ELSŐ VÉG ELLENŐRZÉSE: bejegyzések, oldalak, űrlapok, bevásárlókosár, affiliate nyomon követése.
• Vissza End Check: PageBuilders, egyéb adminisztrátori eszközök.
• Caching : A táblázatban található elemek? Látja a gyors megjegyzéseket a forrásban? (Néha az elemek nem jelennek meg, mint az asztalnál, de valójában az elülső végén vannak.)

Ismert problémák?

• A weboldal még mindig lassú – vagy a webhosting nagyon rossz, a weboldal túlságosan dagadt, vagy rossz beállításai vannak. Ellenőrizze más bővítményeket is. Bármi átirányítással, biztonsággal, e-kereskedelemmel, vagy sok adatbázis lekérdezés lassíthatja a webhelyet.
• Törött stílusok (CSS) vagy függvények (JS)  – tiltsa le a szkriptek/stílusok egyesítését. Győződjön meg arról is, hogy a téma vagy más teljesítményt nyújtó beépülő modulok nem próbálnak egyesülni. (Kerülje el, hogy ugyanazt a funkciót több teljesítményű bővítmény végezze.) A Swift appcache funkció szintén tönkreteheti a CSS-t. Megpróbálhatja újra létrehozni a CSS-t a témában és más beépülő modulokban is.
• Törött vizuális elemek – jelölje be az „Optimalizálás > Általános > Érvénytelen HTML javítása” pontot.
• Furcsa karakterek/szimbólumok – tiltsa le a GZIP-t a gyorsítótárazási lehetőségek közül.
• A kapcsolatfelvételi űrlapok nem működnek  – zárja ki a kapcsolatfelvételi oldalt a gyorsítótárazásból. Próbáljon meg átváltani a Caldera űrlapokra. A Contact 7-tel voltak problémáim (és utálom, hogy minden oldalon betöltődik).
• Furcsa görgetés vagy képernyőfrissítés  – tiltsa le a „sima görgetést” vagy más görgetési effektusokat a témabeállításokban. És ha a képernyőfrissítés nem megy el, hagyja abba a JS egyesítését. (Vagy legalább kizárja az ezt okozó JS-t.)
• A kizárt/nem kívánt elemek továbbra is gyorsítótárban vannak – a nem kívánt elemek megjelennek a bemelegítő táblázatban? Próbálja meg a [Reset Warmup Table] elemre kattintani. Próbálja meg kikapcsolni a „Cache 404 pages” funkciót.
• Az elemek nem tárolódnak a gyorsítótárban? – győződjön meg arról, hogy a gyorsítótár címtárának címe helyes és írható. Próbáljon meg eltávolítani néhány elemet a „Bejegyzéstípusok kizárása” közül.
• Az elemek nem tárolnak előre – győződjön meg arról, hogy az „Gyorsítótár automatikus előépítése” engedélyezve van. Kipróbálhatja a „Távoli előreépítési gyorsítótár engedélyezése” lehetőséget vagy más gyorsítótárazási módokat (kevésbé ideális). Győződjön meg arról, hogy a robots.txt fájl nem blokkol mindent a „Disallow: /” (gyakran az átmeneti webhelyeken).
• A halál fehér képernyője (WSOD) vagy hiba 500  – ez szerencsétlen, de nem minden plugin kompatibilis másokkal. A webhelyet a SWIFT szakasz törlésével visszaállíthatja a Swift részben, törölheti a „WP-Content / Cache” könyvtár törlését, törölje a „WP-Content / Plugins / Swift-Performance” könyvtár törlését, szintén törölje a „Swift-Performance-Loader.php” programot a WP-ben -Content / mu-plugins könyvtár. Egy másik trükk, amit találtam, hogy megváltoztassa a PHP verziót, majd változtassa meg a Vissza.
• Magas CPU-használat – egyesek panaszkodnak, hogy a Swift magas CPU-használatot okoz, de ez nem pontos. A Swift agresszív (nagyon gyors) gyorsítótárazási mechanizmussal rendelkezik, amely minden rendelkezésre álló erőforrást felhasznál az oldalak előzetes gyorsítótárazására. Sokkal gyorsabb, mint más gyorsítótár-bővítményeknek, amelyek örökké tartanak a webhely előzetes gyorsítótárazásához (például 10 oldal/óra). Néhány népszerű megoldás: korlátozza az egyidejű szálakat 1-3-ra, kapcsolja ki a Szkriptek/stílusok egyesítése, kapcsolja ki a HTML kicsinyítését. Le is tilthatja az építés előtti gyorsítótárat, de akkor az első látogatás lassabb lesz.
• A Swift Dashboard vagy Warm-up Table nem töltődik be – ez megtörténhet hatalmas webhelyeken, amelyek több ezer gyorsítótárban tárolt elemet tartalmaznak. Módosítsa a „max_input_vars” értéket valami magasra (például 5000-re). Megkérheti webtárhelyét, hogy segítsen ebben. De akárhogy is legyen… mindaddig, amíg hozzáfér a Swift beállításaihoz, és az oldalak gyorsítótárban vannak a kezelőfelületen, jól van!
• A „Cached with Swift” nem jelenik meg az oldal forrásában  – ez azt jelentheti, hogy az oldal nem gyorsítótárazott, de azt is jelentheti, hogy valami eltávolítja a HTML megjegyzéseket. Lehet, hogy a Cloudflare engedélyezve van? Ideiglenesen tiltsa le, és nézze meg, megjelenik-e a megjegyzés.
• Furcsa www vagy nem www URL-problémák – helyezze el a megfelelő htaccess átirányításokat. Megteheti a Swift egyéni htaccess-jében, vagy nyissa meg a htaccess-ét, és helyezze el a kódot a legfelső Swift htaccess kód fölé.
• A gyorsítótár mérete HATALMAS – törölje a „Separate Scripts” és a „Separate Styles” opciót, vagy jobb, ha nem egyesíti őket. Ne tároljon gyorsítótárat a bejelentkezett felhasználók számára. Szintén zárja ki a felesleges bejegyzéstípusokat.
• A webhely továbbra sem töltődik be a Swift törlése után – ha problémái vannak, és törölni szeretné a Swiftet, feltétlenül törölje a Swiftet a beépülő modulok könyvtárából, a mu-bővítményeket is, és távolítsa el a Swift .htaccess szabályait is. Ezután futtassa manuálisan a WP-cron triggert. Láttam már olyan esetet, amikor a Swift megakadályozta a WP-cron futtatását, és sok cron-feladat mentett, és a kiszolgáló egy kicsit lemaradt még a törlés után is. A WP-cron manuális aktiválása után 5-10 perc is eltelhet, mire a webhely újra használható állapotba kerül.