Perfmatters, konfigurációs útmutató

Ha holnap azt mondanák, hogy csak egy plugint vihetek magammal egy lakatlan szigetre, valószínűleg a Perfmatters-t vinném, és ha lenne rajongói klubom, feliratkoznék és elmennék az összes koncertjükre.

2021 januárja óta használom, és ez volt az egyik olyan plugin, amely a legtöbb problémát oldotta meg, és amely a legtöbbet és a legjobban hozzájárul a betöltési sebesség könnyítéséhez.

Essential

Egyike azoknak az eszközöknek, amelyeknél még a távoli lehetőség sem merül fel, hogy nem fizetsz, amikor eljön az éves megújítás napja. Ami egyébként nagyon gazdaságos egyetlen webhelyen történő használat esetén. Mindössze 24,95 dollárba kerül, és a későbbi megújításokra 15% kedvezményt ad. Tehát a második évtől kezdve már csak 21,21 dollárért.

Mivel néhány funkcióját külön is áttekintettem, egy alaposabb elemzés és beállítási bemutató még váratott magára. Ez a célja ennek a bejegyzésnek.

A konfigurációról

Felelősségi nyilatkozat: Mondanom sem kell, hogy az általam hozzáadott be- és kikapcsolt ikonok az én konfigurációmból származnak, ami a legjobb, amit ehhez a bloghoz kaphattam. Ez nem jelenti azt, hogy ez az ideális az Ön környezetéhez.

Minden forgatókönyv más és más. Minden egyes lehetőséget meg kell tanulmányoznia és meg kell értenie, kísérleteznie kell a viselkedésével, és el kell döntenie, hogy az Ön esetében mi a legjobb. Ehhez nincs is jobb, mint a lehetőségek egyenkénti tesztelése és az eredmények kiértékelése.

Egy másik dolog, amit szem előtt kell tartani, hogy a duplikált eszközök ütközni fognak. Vannak más pluginok, mint például a WP Rocket vagy a Litespeed szerver gyorsítótár plugin, amelyeknek néhány funkciója pontosan ugyanazt teszi. Ezek együttes aktiválása konfliktusokat okozhat. Ki kell értékelned, hogy melyik működik a legjobban, és csak az egyiknél kell maradnod.

Általános lap

Az általános fül tartalmazza a leggyakoribb eszközöket. Mindegyik mellett talál egy linket a hozzájuk tartozó súgóhoz. Ne féljen kipróbálni őket. Minden visszafordítható. A kapcsolóra kattintva minden visszaáll az eredeti állapotába, itt nem történt semmi

Emojik deaktiválása

A WordPress 2015-ös 4.2-es verziójában a régebbi böngészők számára az emojik támogatása bekerült a magba.

Bár nem túl súlyosak (18 KB plusz egyéb JS), de azért érdemes letiltani őket, mert a blogod minden oldalán betöltik a wp-emoji-release.min.js JavaScriptet, és egyel kevesebb kérés mindig eggyel kevesebb kérést jelent.

Dashicons letiltása

A dashicons a WordPress admin hivatalos ikon betűtípusa a 3.8-as verzió óta. Néhány sablon használja a front-endben a dashicons.min.css CSS betöltésével. Sok modern téma és bővítmény azonban már saját ikonokat, SVG-ket vagy egyáltalán nem használ ikonokat. Tehát ha nem használ dashicons-t, akkor letilthatja, mert a stíluslap feleslegesen növeli a betöltési időt és blokkolja a renderelést is.

A Perfmattersből történő letiltásuk nem érinti a WordPress admin panelt, amely használja őket. Csak a front-endben lévő dashiconok lesznek eltávolítva, ha nem vagy bejelentkezve.

Beágyazás letiltása (Embebs)

Amikor a szerkesztőben bármilyen linket beillesztesz a blogodból, a WordPress felismeri és ekként jeleníti meg (ha nem változtattad meg a stílusát).

Ha nem érdekelnek a beágyazások, akkor letilthatod őket, és ezzel egy kicsit könnyíthetsz a terheltségen. Én azért nem kapcsoltam ki őket, mert azt vettem észre, hogy az előnézettel ellátott linkek általában jó kattintási arányt érnek el, ha kapcsolódó linkként használják őket a bekezdések között.

A beágyazás vagy a beágyazások a WordPress 4.4-es verziójával érkeztek. A hátrányuk az, hogy egy extra kóddal érkeztek, amely egy újabb betölthető JavaScript beillesztésével egészül ki: wp-embed.min.js

A beágyazások letiltása a blogodon azt is megakadályozza, hogy más blogok beágyazzák a linkeket az oldaladról ezzel az előnézettel, azonban eltávolítja az oEmbed-specifikus JavaScriptet, letiltja az oEmbed eredmények szűrését, a
eltávolítja az oEmbed linkfelfedezést és az összes beágyazási átírási szabályt is.

XML-RPC letiltása

Az XML-RPC egy olyan protokoll, amelyet a WordPress 3.5-ben adtak hozzá a távoli kapcsolatok engedélyezéséhez, és hacsak nem a WordPress alkalmazást használod a blogod mobilról történő közzétételére vagy szerkesztésére, fontos letiltani, mert komoly biztonsági kockázatokat rejt magában.

Nagyon kevés bővítmény igényli, csak egy olyanról tudok, amelyik használja: a JetPack. Egy többfunkciós plugin, ami nem ajánlott, mert jelentősen hátráltatja a teljesítményt.

Miután az XML-RPC-t kikapcsoltad, csak ellenőrizd az állapotát a yourdomain.com/xmlrpc.php oldalon, hogy megbizonyosodj róla, hogy csak egy 403-as hibaüzenetet ad vissza.

Ezen az ellenőrzőprogramon is ellenőrizheti. Ha ilyen üzenetet kap, az azt jelenti, hogy az XML-RPC ki van kapcsolva.

A jQuery Migrate eltávolítása

A WordPress 3.6-ban került bevezetésre, és a WP 5.5 és újabb verziók óta már nincs alapértelmezetten engedélyezve.

Bár a legtöbb sablon és bővítmény nem igényli, még mindig van néhány, amelyiknek szüksége van rá valamilyen kisebb funkcióhoz. Az én esetemben két plugin használja, az Ultimate Membership Pro és a Rank Math egy statisztikák sávjához (amit én nem használok), ami csak az adminok számára jelenik meg. Néhány cookie-k beleegyezését kezelő plugin még mindig használta a közelmúltig.

a jQuery Migrate egy forrás a fejlesztők számára, amely lehetővé teszi, hogy a régebbi függőségekkel rendelkező kód kommunikáljon az új kóddal.

Valószínűleg nincs olyan pluginod, amelyiknek szüksége lenne rá, így a jQuery Migrate a jquery-migrate.min.js JavaScript felesleges overheadjét adja hozzá

Mégis, mielőtt letiltanád, nézd meg a bővítményeid dokumentációját, vagy kérdezd meg a fejlesztőiket (később megnézzük, hogyan lehet letiltani konkrét oldalak esetében).

WordPress verzió elrejtése

Ennek az opciónak nincs titokzatossága, egyszerűen csak biztonsági intézkedésként elrejti a telepített WordPress verzióját a kíváncsi szemek elől.

Ez, amit többféleképpen is megtehetsz, hasznos abban az esetben, ha későn frissítesz valamit, ahol a verzióval olyan sebezhetőségek jelennek meg, amelyeket ki lehet használni, vagy a magot lehet kompromittálni. Legalábbis a verzió elrejtésével kevésbé könnyíti meg a kiskapukat kereső támadók dolgát.

Bár csak egy sor kódot távolítunk el, és ezt elsősorban a biztonság érdekében tesszük, az optimalizálás szerelmeseinek ez csak egy újabb csipetnyi, ami hozzáadódik a kivonandó összeghez.

A wlwmanifest hivatkozás eltávolítása

Ez egy minden WordPress telepítésben megjelenő címke, amelyet a Windows Live Writer használt, és amelynek frissítése és támogatása 2017 januárjában megszűnt.

A fentiekhez hasonlóan ez is csak felesleges kód, tehát egy sorral kevesebb.

RSD link eltávolítása

Egy másik megmaradt tag, amely minden WordPress telepítésben megjelenik.

Ha böngészőből szerkeszted az oldaladat, egyáltalán nincs rá szükséged. Néhány harmadik féltől származó alkalmazás is használja, amelyek XML-RPC kéréseket használnak, amit már le kellene tiltanod. Szóval ez felesleges kód, amit el kell távolítani.

Távolítsa el a rövid linket

Ezt arra használják, hogy egy rövid linket hozzon létre számokkal az oldalakhoz és a posztokhoz, amelyek hozzáadják ezt a taget:

<link rel='shortlink' href='https://dominio.com?p=123' />

Ha "szép" rövid permalinkeket használsz, mint például domain.com/%postnév%, akkor nincs értelme ezt mindenféle használat nélkül megtartani, még több felesleges kód, amit el kell dobni.

RSS feed kikapcsolása

A WordPress alapértelmezés szerint különböző típusú RSS feedeket generál. Bár az RSS feedek még mindig hasznosak egy blog számára, ha az oldalad inkább statikus, vagy egyszerűen nem használod blogként, akkor letilthatod a feedeket.

Linkek eltávolítása az RSS-feedekből

Ahogyan a WordPress RSS feedeket generál, úgy generálja az oldalak, bejegyzések, hozzászólások, megjegyzések, kategóriák, címkék stb. linkjeit is az adott RSS feedekhez. Az RSS-feedeket engedélyezve hagyhatod, de az RSS-feed linkeket mégis eltávolíthatod. Ennek az a célja, hogy további és valószínűleg nem használt kódot távolítson el az oldaláról.

Automatikus visszacsatolások kikapcsolása

A pingback alapvetően egy automatikus, linkkel ellátott megjegyzés, amely értesítésként jön létre a blogodon, amikor egy másik blog rád hivatkozik. Az autopingback akkor jön létre, amikor a saját blogodon belül hivatkozol egy cikkre.

Manapság szinte senki sem használja őket, és az esetlegesen kapott külső pingbackek általában spamek, csak pazarolják az erőforrásokat, és akár rosszindulatú vagy ideiglenes, törött és ezért a SEO szempontjából káros linkeket is létrehozhatnak.
A trackbackekhez hasonlóan ezek is a blogok múltjába tartoznak, amikor a linkelés mint blogfilozófia a netiquette részeként hagyomány volt.

A REST API letiltása

A WordPress REST API API végpontokat biztosít a WordPress adattípusaihoz, amelyek lehetővé teszik a fejlesztők számára, hogy JSON objektumok küldésével és fogadásával távolról interakcióba lépjenek a webhelyekkel.

Lehetővé teszi az adatok kereszthivatkozását más webhelyekkel és PHP-ben vagy bármely más nyelven írt szoftverrel.

Különböző bővítmények, szolgáltatások és alkalmazások használják a REST API-t, a Perfmatters szerint ezek közül néhány:

Yoast SEO és Ryte dashboard widget, Jetpack, néhány kapcsolatfelvételi űrlap, Wordfence és néhány WooCommerce dashboard specifikus widget.
A Gutenberg blokkszerkesztő is használja a kommunikációra, amikor szerkesztéseket végez az oldalakon és a bejegyzéseken. Ha teljesen kikapcsolja, akkor egy "Update failed" hibaüzenetet fog kapni.

A Perfmatters három lehetőséget kínál. Bekapcsolva (alapértelmezett), letiltva a nem adminisztrátorok számára és letiltva, ha kijelentkeztél.

REST API-kötések eltávolítása

Alapértelmezés szerint egy REST API-kötés szerepel a típusfejlécben:

<link rel='https://api.w.org/' href='https://domain.com/wp-json/' />

A fejléc is elküldésre kerül minden egyes kérelemben, és egy API-címke kerül hozzá a Really Simple Discovery (RSD) végponthoz. Mindez a kód nélkülözhető a hivatkozások eltávolítására szolgáló opció aktiválásával.

A Google Maps letiltása

Csak ennyi, tiltsa le a Google Maps API-t.

Egyes WordPress sablonok és bővítmények beépített Google Maps API-val rendelkeznek, és gyakran nem kínálnak módot a letiltására. A Google Maps pusztítást végezhet a blogod teljesítményén, még akkor is, ha a kérések aszinkron módon töltődnek be. Normális esetben a kérés a hivatalos Google Maps API-n keresztül történik.

Csak egy térkép betöltéséhez a blogján akár 20 HTTP-kérés is érkezhet a Google Mapshez. Az integrációtól függően kevesebb vagy akár több kérést is végezhet.

Ha nincs rájuk szüksége, akkor érdemes letiltani őket.

A Google Maps kikapcsolásának kizárása a postai azonosítószám alapján

Ha azonban nincs más választása, mint a térképek beágyazása, akkor csak azoknál a bejegyzéseknél zárhatja ki a deaktiválást, ahol szükség van rájuk. Ehhez a következő mezőbe kell beírnia az egyes bejegyzések azonosítóját vesszővel elválasztva.

A jelszó erősségmérőjének kikapcsolása

Ezt a WordPress és a WooCommerce legújabb verzióiban vezették be. Ez egy beépített jelszóerősségmérő, amely arra kényszeríti a felhasználókat, hogy erős jelszavakat használjanak, és több fájlt tölt be, például: /wp-admin/js/password-strength-meter.min.js és /wp-includes/js/zxcvbn.min.js

azxcvbn.min.js több mint 800 KB súlyú lehet

Ha a WooCommerce-t használja, a fájl néha szintén ebben az elérési útvonalban található:

/wp-content/plugins/woocommerce/assets/js/frontend/password-strength-meter.min.js

Az egyes sablonoktól és attól függően, hogy a fejlesztő hogyan állította be a dolgokat a sorba, néha ezek a fájlok az egész webhelyre betöltődnek. Teljesítőképességi okokból csak a "fiók", a "pénztár" és a "jelszó visszaállítása" oldalakon kell betölteni őket.

Ha a letiltás után még mindig talál ilyen szkripteket a kérések között, kérjük, nézze meg a sablon dokumentációját és bármely olyan bővítmény dokumentációját, amelyről úgy gondolja, hogy használja ezt a funkciót.

A megjegyzések letiltása

Ha nincs szükséged a kommentekre, vagy úgy döntöttél, hogy a legradikálisabb módon vetsz véget a spamnek, akkor letilthatod az olvasók számára a kommentelés lehetőségét. A hozzászólási űrlap eltűnik.

Ez azoknak a műveleteknek a listája, amelyeket a Perfmatters megpróbál végrehajtani, ha a Hozzászólások letiltása opció be van kapcsolva:

• A beépített legutóbbi hozzászólások widget letiltása.
• Eltávolítja az X-Pingback fejlécet.
• Eltávolítja a hozzászólási feed linkeket.
• Letiltja a komment feed lekérdezéseket.
• A hozzászólási linkek eltávolítása az admin sávból.
• Távolítsa el a hozzászólás-támogatást az összes bejegyzéstípushoz.
• Kommentszűrők bezárása.
• Hozzászólási linkek eltávolítása az adminisztrációs menüből.
• Tiltja le a beépített vitaoldalt.
• Rejtse el a hozzászólásokat a vezérlőpultból.
• Rejtse el a kommentbeállítások opciót a profiloldalról.
• Üres hozzászólássablon visszaküldése kérésre.
• Távolítsa el a hozzászólásra válaszoló szkriptet.

Ne feledje, hogy ha a lágyabb opciót választja, akkor az egyes hozzászólások szerkesztéséből csak bizonyos hozzászólásokhoz tartozó hozzászólásokat zárhat le a jelölőnégyzet kijelölésének megszüntetésével.

Vagy a Beállítások/kommentek menüpontban beállíthatja, hogy bizonyos számú nap után bezáródjanak.

URL-ek eltávolítása a hozzászólásokból

Alapértelmezés szerint a WordPress hozzászólások tartalmaznak egy weboldal mezőt, amely egy nofollow linket hoz létre (bár a spammerek ezt nem bánják) a hozzászólás szerzőjének nevében.

Ha nem akarsz foglalkozni az idővel megtörő linkekkel, túl kevés hozzászólásod van, vagy egyszerűen csak ki akarod szorítani a spameket, egy csapásra törölheted a látogatók által a kommentekben hozzáadott összes URL-t.

Ennek engedélyezése az URL-mezőt is eltávolítja az űrlapról a jövőbeli hozzászólásokhoz.

Üres favicon hozzáadása

Ha már van favicon a webhelyén, akkor ezt az opciót érdemes kikapcsolva hagyni.

Egy fehér favicon hozzáadása akkor hasznos, ha sok új WordPress telepítést hoz létre és tesztel. Az üres favicon hozzáadása megkíméli Önt attól, hogy minden egyes webhelyhez fel kelljen töltenie egy favicont. Emellett, ha elfelejti, 404-es hibát generálhat a sebességtesztelő eszközökben.

Globális stílusok eltávolítása

A WordPress 5.9-től kezdődően további inline kódot adtak hozzá a duotone stílusok (CSS és SVG kód) javítására. A legtöbb felhasználó valószínűleg nem fogja használni ezt a funkciót, és az a probléma, hogy 311 sor (nem minimalizált) kódot ad hozzá a webhelyed minden egyes oldalához, amelyek így vannak felosztva:

196 sor CSS a body tag előtt és 115 sor SVG kód, amely szintén a /body tag előtt kerül hozzáadásra.

A kód nagy része!important; címkéket használ, ami szintén nem ideális.
A Perfmatters úgy véli, hogy ez egy hiba lehet, ezért hozzáadják ezt az opciót, hogy könnyen eltávolíthassák ezt a felesleges kódot, amíg a hiba megoldása folyamatban van.

Hearbeat, vélemények és automatikus mentés

A WordPress Heartbeat API a /wp-admin/admin-ajax.php fájlt használja az AJAX hívások végrehajtásához a böngészőből.

Ez nagyszerű, mert elmenti a vázlataidat, és megakadályozza, hogy egy váratlan leállás miatt elveszítsd őket, de magas CPU-használatot és őrült mennyiségű PHP-hívást is okozhat. Ha például nyitva hagyja a vezérlőpanelt, az továbbra is rendszeres időközönként, 15 másodpercenként POST-kéréseket küld ebbe a fájlba. Ennek mérséklése érdekében a gyakoriságot 60 másodpercre növelheti.

Az első opcióban kiválaszthatja, hogy mikor és hol kerüljön kiváltásra.

A harmadik opcióval korlátozhatja a bejegyzések felülvizsgálatainak számát, hogy helyet takarítson meg, például ha 10-re állítja be, csak az utolsó 10 kerül mentésre, az előzőek pedig törlődnek.

Végül beállíthatja a vázlatok automatikus mentési időközét. Alapértelmezés szerint a WordPress 60 másodpercenként automatikusan menti őket. Ha azonban megnöveled az intervallumot, akkor gyakrabban kell manuálisan menteni, ez megakadályozza, hogy a böngésző annyira "lógjon", amíg az adminisztrációs területen tartózkodsz, és kevesebbet ír az adatbázisba.

Woocommerce

A Wookereskedelem optimalizálási lehetőségeiről csak annyit mondok, hogy léteznek, de kerülni fogom a kommentárt, mivel ebben a házban szokás, hogy nem vizsgálok meg semmit, amit nem nagyon világos, mint ahogy ez a helyzet. A WooCommerce-t 2021 júliusában eltávolítottam, és alig emlékszem valamire az optimalizálások válaszáról, így a dokumentációjukra utalok:

• A WooCommerce szkriptek és stílusok letiltása
• A kosár snippets letiltása
• Tiltja le a WooCommerce állapotdobozát
• A WooCommerce widgetek letiltása

Bejelentkezési URL

Egy másik érdekes funkció az a lehetőség, hogy megváltoztathatja az admin területre való alapértelmezett bejelentkezési URL-t, amelyet a WordPress a yourdomain/wp-admin címen állít be. Ez pontosan ugyanazt teszi, mint a puginok, mint például WPS Hide Login.

Három mezőt találsz:

Az elsőben megváltoztathatod a wp-admin bejelentkezési url-t arra, amire akarod, például "yourdomain.com/potato", így elkerülve a brute force támadásokat és másokat, amelyek általában az alapértelmezett url-t célozzák. Csak írd le és/vagy próbáld meg nem túl sok karakterből álló furcsa url-t csinálni, hogy ne felejtsd el (bár bármikor lekérdezheted a wp_options / perfmatters_options táblában)

A második mező (Disabled Behavior) azt állítja be, hogy a yourdomain/wp-admin-ra érkező látogatót melyik url-re küldje a rendszer három lehetőség közül:

• Üzenet (alapértelmezett): Üzenetet jelenít meg a látogatónak. Az üzenetet a kívánt szöveggel testreszabhatja a mezőben lévő szöveggel Üzenet.
• 404 sablon: A felhasználó egy 404-es oldalra kerül.
• Kezdőlap URL: A felhasználó a kezdőlapra kerül átirányításra.

Eszközök

Itt válik igazán érdekessé a dolog.

Script Manager, a hab a tortán

A Perfmatters Script Manager kétségkívül a legerősebb és leghasznosabb eszközük. Ez önmagában minden fillért megér abból a kevésből, amit a pluginért és annak támogatásáért fizetsz.

Lehetővé teszi, hogy letiltsd az egyes pluginok által használt scripteket és CSS-eket, és megakadályozd, hogy betöltődjenek egy posztban vagy oldalon, mindkét helyen vagy az egész site-on, szűrhetsz bejelentkezett vagy kijelentkezett felhasználók, eszközök szerint, és kivételeket adhatsz hozzá, akár kategóriákra és címkékre is.

Ez drasztikusan növelheti a betöltési sebességet (különösen a kezdőlapon) azáltal, hogy kiküszöböli a felesleges kéréseket ott, ahol a pluginokat nem használják, mint például az űrlapok vagy bármi más.

A kötelező használati mód (MU) sokkal tovább viszi a Script Manager-t. Sokkal nagyobb kontrollt biztosít, és lehetőséget ad a WordPress plugin lekérdezések és horgok, valamint az inline CSS és JS letiltására. Mostantól egy plugin minden aspektusát, a front-end szkriptjeit, az inline kódot és a MySQL-lekérdezéseket is ellenőrizheti, ahol csak akarja.

Globális nézetében megtalálja az összes alkalmazott beállítást arra az esetre, ha egy nap át kell rendeznie, módosítania, újakat hozzáadni vagy néhányat eltávolítani.

Elég teljes dokumentációval rendelkezik. Ha nem vagy hozzászokva az ilyen típusú eszközökhöz, elsőre ijesztő lehet, de amint kipróbálod, rájössz, hogy nagyon könnyen használható.

JavaScript

A JavaScriptelhalasztása és késleltetése.

Mindkettő segíthet az FCP és az LCP javításában

A defer attribútum hozzáadása minden nem kritikus JavaScript fájlhoz felgyorsítja az oldal első tartalomfestését (FCP). Ez azt jelenti, hogy a JavaScript a HTML-elemzés során töltődik le, és az oldal betöltése után (amikor az elemzés befejeződött) hajtódik végre. Más szóval a JavaScript letöltése az oldal aljára kerül, így a folyamat végén történik meg.

A késleltetéssel javulnak az LCP és a TBT eredmények. A JavaScript a felhasználói interakciónak megfelelően késleltetve van, felgyorsítva az oldal első festését, ha valamire nincs azonnal szükség, például harmadik féltől származó nehéz szkriptekre, mint a Google Adsense, Google Analytics, Facebook konverziós pixelek vagy Google Ads és hasonlók.

Mindkét opcióhoz hozzáadhat kivételeket, és engedélyezheti a Delay Timeout viselkedést, ez beállít egy időkorlátot, amely automatikusan betölti a szkripteket 10 másodperc után, ha nem észlelt felhasználói interakciót. Ez opcionális, és alapértelmezés szerint ki van kapcsolva.

Késleltetési időkorlát

Ha engedélyezi ezt az opciót, akkor lehetősége van a késleltetési időkorlátot más értékre állítani az alábbi szűrők egyikének használatával.

A példában szereplő érték 7 másodpercre van beállítva.

add_filter('perfmatters_delay_js_timeout', function($timeout) {
    return '7';
});

Azt tanácsolják, hogy ne állítsa túl rövidre az időkorlát értékét, különben a JS késleltetési funkció nem fog megfelelően működni. Továbbá az időkorlátozástól függetlenül, az esetek 99%-ában minden az első felhasználói interakciónál fog elsülni, legyen az görgetés, kattintás vagy az első egérmozgás.

CSS

A Perfmatters szerint a "Reduce unused CSS" figyelmeztetés feloldásának legegyszerűbb módja, ha engedélyezed ezt a funkciót, amelyet még a béta-verzió idején vizsgáltam, és amely mindent automatikusan elvégez. A fejlesztők azt állítják, hogy több száz URL-címen tesztelték (különböző sablonok és beállítások használatával), és ez néhány az általuk állítólag elért eredmények közül:

• Átlagos FCP-csökkenés 15,20%.
• Átlagos LCP csökkenés 19,66%.
• Átlagos TTI csökkenés 14,95%.

A Perfmattersben a "Fel nem használt CSS eltávolítása" funkció aktiválása előtt azt javasolják, hogy távolítsuk el a Perfmattersben beállított, meglévő CSS előtöltéseket (kivéve a Google Fonts helyi stíluslapokat).
Ne egyesítsük a CSS-t (amit a WP Rocket, Litespeed, Autoptimize és mások gyakran csinálnak). A CSS egyesítése a HTTP/2 óta elavult optimalizálási technika. Bizonyos esetekben a CSS egyesítése árthat a teljesítménynek(az én esetemben nem ártott), és végül győződj meg róla, hogy nem próbálod meg eltávolítani a nem használt CSS-t egy másik pluginnal.

Az eltávolításnak három módja van:

• Késleltetés (alapértelmezett): Minden eredeti CSS stíluslap (nem használt CSS) késleltetve van, és a felhasználói interakcióra töltődik be. Ez az ajánlott opció.
• Aszinkron: Az összes eredeti CSS stíluslap (nem használt CSS) aszinkron módon töltődik be. Ez a módszer segíthet elkerülni a beugró megjelenéseket, mivel a stíluslapok aszinkron módon kerülnek végrehajtásra, miközben az oldal betöltődik. Ez a módszer valamivel magasabb LCP/FCP értéket eredményez, mint a késleltetési viselkedés.
• Remove: Az összes eredeti CSS-stíluslap (nem használt CSS) eltávolításra kerül. Ez a legagresszívabb módszer, de valószínűleg kivételek hozzáadását is igényli. Csak haladó felhasználóknak ajánlott.

Itt nincs más titok, mint a tesztkörnyezetben való kísérletezés és az eredmények mérése, mind elszigetelten, mind a többi funkcióval való kölcsönhatásban.

Ezen funkciók némelyike kikapcsolható bármelyik poszton vagy oldalon a WP-szerkesztésben.

Kód

Egy hasznos klasszikus, amit sok más plugin tartalmaz, amit akár kézzel is el lehet végezni, de ami leegyszerűsíti és megkönnyíti az egyéni kód hozzáadásának működését a blog fejlécéhez, törzséhez vagy láblécéhez.

A következő mezők közvetlenül a front-endre nyomtatják a kódot, így annak érvényes HTML-nek kell lennie. Ez magában foglalja a <style> címkéken belüli inline CSS-t vagy a <script> címkéken belüli inline JS-t. Egy JS vagy CSS fájlt is feltölthet.

Nem támogatja a szerveroldali nyelveket, például a PHP-t. Egyéni PHP-kód hozzáadásához ajánlott a Code Snippets bővítmény használata.

Előbetöltés

Az előtöltésnél az első,"Instant Page" nevű opció az instant.page könyvtárat használja, és egy kis, kevesebb mint 2 KB-os JS fájlt(instantpage.js) tölt be helyileg az oldaladra, és az URL-ek előtöltésére szolgál, amikor a felhasználó egy link vagy kép fölé mozgatja a mutatót az asztali verzióban. Mobilon az URL előretöltődik, miután a felhasználó elkezdi megérinteni a linket a képernyőjén, és mielőtt elengedné azt.

65 milliszekundum után az URL előtöltése automatikusan elindul a háttérben.

Ez az eszköz a Litespeed"Instant Click" és a WP Rocket"Preload Links" funkciójának megfelelője, így ha ezt az opciót használja e két plugin valamelyikében, akkor érdemes kikapcsolni, hogy kipróbálhassa a Perfmatters-t.

Az én esetemben egy kicsit jobban működött, mint a Litespeed megfelelő opciója, bár meg kell jegyezni, hogy bizonyos esetekben növelheti a szerverterhelést.

A Javascript és a CSS opciókhoz hasonlóan az előtöltés és az előcsatlakozás használatát is az Ön igényei szerint kell használni a különböző tesztek alapján.

A kritikus képek (a hajtás felettiek) előretöltése egy még béta fázisban lévő opció, amely segíthet csökkenteni a nagyobb tartalmak (LCP) festéséhez szükséges időt a Core Web Vitalsban.

Ezek általában olyan képek, mint például egy logó, egy kiemelt kép egy posztban, egy fő kép egy landing page-en stb. Amikor előretölti őket, a vízesés tetejére kerülnek, és lényegében azt üzenik a böngészőnek, hogy elsőbbséget élveznek, és azonnal be kell tölteni őket.

Választhatsz a nulla, azaz egy sem (az alapértelmezett beállítás) és az öt kép előretöltése között. A Permatters azt ajánlja, hogy kettő vagy legfeljebb három képet válasszon, mivel a Chrome korlátozza az előretöltött képek számát, amelyek a vízesés tetején jelennek meg.

Lusta betöltés

Egy másik klasszikus teljesítményhez kapcsolódó funkció, amelyet a WordPress natívan tartalmaz a 2020-as 5.4-es kiadás óta.

Az én esetemben a Litespeed opciót használom, mert a tesztek során valamivel jobb eredményeket találtam, ennek ellenére a Perfmatters egy nagyon jól működik, és a háttérképek CSS-ére is alkalmazza.

Betűtípusok

Egy másik jó dolog. Ez az opció, amelyet az 1.7.4-es verzióhoz adtak hozzá a Perfmatters 1.7.42022. június 7-én jelent meg. Lehetővé teszi a Google betűtípusok helyi hosztolását és feltöltését néhány kattintással.

A betűtípusok helyi hosztolásának számos előnye van, teljes ellenőrzést szerez felettük, kiküszöböli az összes kérést és ezáltal a betöltési időt, és eldöntheti, hogyan szolgálja ki őket.

A funkció automatikusan megkeresi a blogodon létező Google Fonts hivatkozásokat, letölti a megfelelő betűtípusokat a fonts.google.com oldalról, és helyben tárolja őket a szervereden a következő könyvtárban: /wp-content/cache/perfmatters/your-domain.com/fonts/

Ez a bejegyzés részletesebben elmagyarázza a használatát.

CDN

Itt nincs semmi különös, és kevés a kommentálnivaló. Egy eszköz, mindig hasznos hozzáadni a használt CDN-t. Mivel én a QUIC.CLOUD-ot használom, még nem volt rá szükségem.

Analitika

Bár most nem használom, mivel megkezdtem az átállást a Matomóra, és az Analytics szkript kezelését az RGPD/CCPA cookie-k hozzájárulásának kezelését végző pluginomra hárítottam, amely szintén megfelelően kezeli, de tudom, hogy nagyon jól működik a Perfmatters-szel, mert annak idején használtam.

Innentől kezdve a Google Analytics szkriptet lokálisan hosztolhatod. Ez segít felgyorsítani az oldaladat, mivel csökkenti a további DNS-kereséseket, és megoldja a szkriptjük "böngésző gyorsítótárának kihasználása" problémáját.

A Perfmatters szerint ironikus módon a Google saját szkriptje figyelmeztetést ad ki a gyorsítótárazással kapcsolatban, de ez azért van, mert nagyon rövid a HTTP-cache fejléc lejárati ideje. Ha saját maga hosztolja, akkor a saját CDN-je vagy szervere HTTP-cache fejléceit automatikusan alkalmazza. Más szóval, teljes ellenőrzést nyer a szkript gyorsítótárazása felett.

Megjegyzik azt is, hogy ezt az eszközt a Google hivatalosan nem támogatja, de évek óta gond nélkül használják.

A Google Analytics helyi tárhelye és a szkript saját CDN-ről vagy szerverről történő kiszolgálása azt is lehetővé teszi, hogy kihasználja az egyetlen HTTP/2 kapcsolat előnyeit.