Néhány WordPress webhely adminisztrátor megszállottja a PageSpeed Insights vagy a GTmetrix. Az én tanácsom, és sok másé, aki sokkal többet tud erről, az, hogy ne tulajdonítson ezeknek a mérőszámoknak nagyobb jelentőséget, mint amekkora jelentőségük van.
Ha az érzékelt betöltési sebesség jó, nem szükséges mindent "zöldre" tenni. Sok esetben ez még kontraproduktív is, mert túloptimalizálásba eshetünk, vagy ami még rosszabb, a végén különböző dolgokat tehetünk tönkre, miközben egy dolgot próbálunk javítani.
Mindegy, hogy Ön WPO-rajongó, az optimalizálás szerelmese, vagy csak szeretné javítani webhelye érzékenységét, ezek az eszközök szinte nélkülözhetetlenek. A probléma az, hogy külső szerverekről származó "állóképeket" kínálnak. De mi történik akkor, amikor Ön, mint rendszergazda, böngészi az oldalát, mi van azokkal a hirdetésekkel, amelyek későn töltődnek be, vagy azzal a menüvel, amelyik éppen akkor ugrik, amikor kattintani készül?
Eredet
A Speed Auditor egy személyes igényre adott válaszként született, hogy több egyszerű, de hatékony helyi diagnosztikai eszközzel rendelkezzen. Ez nem egy optimalizáló plugin (nem változtat semmit a kódodon), hanem egy valós idejű auditáló plugin.
Ha egy jó, talán a legjobb fizetős plugint keres a WPO-hoz, amellyel változtatásokat és finomhangolást végezhet, nézze meg a Perfmatters-t. Ha viszont valami ingyenes és egyszerű dolgot keresel, amiben nem kell a beállításokkal és beállításokkal bajlódnod, de rengeteg lehetőséged van, akkor próbáld ki a WPO Rocket Tweaks-t Fernando Tellado-tól, ami a WordPress tárolóban érhető el.
Ha nem tudja, mi az a DOM-csomópont vagy a késleltetési metrika, ne aggódjon. A Speed Auditor úgy lett kialakítva, hogy segítsen megérteni a webhelyét egy pillantással:
- Az intelligens jelző: Egy színváltó ikon jelenik meg az adminisztrációs sávban. Ha ez zöld, akkor az LCP (a legfontosabb dolgok megtekintéséhez szükséges idő) optimális. Ha narancssárgára vagy pirosra vált, akkor valamire oda kell figyelnie.
- Auditálás böngészés közben: Nem kell semmi bonyolultat konfigurálnia. Aktiválod a plugint, és miközben a bejegyzéseidet ellenőrzöd, a háttérben elemzi, hogy a képeid túl nagyok-e, vagy a szervered lassan reagál-e.
- További emberi jelentések: Egyetlen kattintással letölthet egy .txt fájlt, amelyet elküldhet a fejlesztőjének, vagy elmenthet, hogy a módosítások alkalmazása után összehasonlíthassa az eredményeket.
A motorháztető alatt
Az 1.1.8-as verzió megpróbál némi mélységű diagnosztikát biztosítani, hogy időt takarítson meg a böngésző konzoljában való babrálásra.
- Pontos LCP-azonosítás: A bővítmény pontosan felismeri, hogy melyik elem (kép vagy szövegblokk) váltotta ki a Largest Contentful Paint-et.
- DOM mélyelemzés: DOM-méret túlméretezésének elkerülése érdekében. A Speed Auditor a csomópontok számát zónák (fejléc, tartalom, lábléc) szerint bontja le, és figyelmeztet, ha a beágyazottság meghaladja a 15-20 szintet.
- Médiakésleltetés-monitor: A képek tényleges átviteli idejét méri (Resource Timing API). Ha egy kép letöltése 500 ms-ot vesz igénybe, a bővítmény kritikusnak jelöli azt.
- Nulla hatás a szerverre: Minden feldolgozás az ügyfél (böngésző) oldalán történik. Nincsenek nehéz adatbázis-lekérdezések vagy PHP-folyamatok, amelyek lelassítják az oldalt.
A nagy ugrás. Hamarosan: Speed Auditor 1.1.9 (a "Radar CLS"-szel)
Eddig a kumulatív elrendezéseltolódás (CLS) egy jelentésben szereplő absztrakt számadat volt. Tudta, hogy valami mozog, de nem mindig tudta, hogy mi. Hamarosan, az 1.1.9-es verzióban ez megváltozik.
Bevezetésre kerül a radar vagy a vizuális CLS "Kiemelő" gombja.
Képzelje el, hogy aktivál egy "radar" üzemmódot, amely piros dobozokat rajzol minden olyan elem fölé, amely görgetés közben mozog. Ez, amit néhány bővítmény már több-kevesebb sikerrel meg is tesz, mindig nagyon hasznos vizuális segítség, hogy megpróbáljuk elkapni azokat a "túlcsordulásokat", amelyek néha elkerülnek a szemünk elől.
- Egy AdSense banner nyomja a tartalmadat? Egy piros kerettel fogod látni. Itt mélyebben elmélyedhetsz ebben a problémában.
- Meghatározott méretek nélküli kép? A radar el fogja kapni.
- Teljes kitartás: A bővítmény emlékezni fog arra, hogy minden sarkot vizuálisan ellenőrizni akar.
Ez a frissítés egy rövid technikai szószedet is tartalmazni fog, amely kibővül tippekkel és útmutatókkal, amelyek integrálva lesznek a WordPress műszerfalába, így az olyan kifejezések, mint az ins, iframe vagy figure többé nem lesznek rejtélyek.
Az ötlet az, hogy javítsam mind az elemzés válaszát, mind a generált jelentéseket, ahogy tesztelem különböző forgatókönyvekben, és ha kapok javítási javaslatokat vagy hibajelzéseket.
Az 1.1.8-as verzió már elérhető a metrikák rendbetételéhez, és hamarosan az 1.1.9-es verzióval még könnyebbé válik a WordPress vizuális stabilitásának javítása. Ha most telepíted, hamarosan megkapod a frissítést.
Hogyan működik?
A kód a következő három lépést követi:
1. A PerformanceObserver
A böngésző (Chrome, Edge, Opera) rendelkezik egy natív API-val, a Performance API-val. A bővítmény regisztrál egy PerformanceObserver nevű "figyelőt", amely kifejezetten az elrendezés-eltolódás bemeneti típushoz van beállítva.
A böngésző minden alkalommal, amikor valami mozog a képernyőn a kezdeti festés után, eseményt generál. A bővítmény csapdába ejti ezt az eseményt, és két kulcsfontosságú adatot nyer ki:
- Az eltolás értéke: (Ez a szám 0,0145).
- A bűnös elem: A böngésző pontosan megmondja a bővítménynek, hogy melyik HTML-csomópontot mozgatta el.
2. A "Legutóbbi interakciók" szűrő
Ez az a pont, ahol a plugin megpróbál okoskodni. Nem minden mozdulat "rossz". Ha egy legördülő menüre kattintasz, és a tartalom lefelé gördül, az a felhasználó által elvárt mozdulat.
A bővítmény ellenőrzi a hadRecentInput nevű tulajdonságot. Ha az elmúlt 500 ms-ban megérintett egy billentyűt vagy rákattintott, a böngésző ezt a mozgást "várhatónak" jelöli, és a plugin figyelmen kívül hagyja azt, hogy elkerülje a hamis pozitív jeleket. Csak a váratlanul bekövetkező mozgásokat (például egy hirtelen megjelenő hirdetés) érzékeli.
3. Vizuális megjelenítés (A piros dobozok)
Miután a plugin megkapta az áthelyezett elemet, a vizuális rész jön a képbe:
- Koordinátaszámítás: A getBoundingClientRect() nevű függvényt használja annak megállapítására, hogy az adott elem az adott pillanatban hol van a képernyőn (pixel felfelé, pixel balra).
- Keretbefecskendezés: Hozzon létre egy
div-etabszolút pozícióval, 2px-es piros szegéllyel és nagyon magasz-indexszel, hogy mindenre ráhúzza. - A címke: A piros doboz bal felső sarkában adjunk hozzá egy kis dobozt a címke nevével (ins, img, div) és a felhalmozott CLS értékével.
Miért jobb ez, mint egy külső jelentés?
Az olyan eszközök, mint a PageSpeed, néha nem észlelik a CLS-t, mert nem görgetnek az aljára, vagy nem várják meg bizonyos hirdetések betöltését.
A plugin a perzisztencia használatával méri a felhasználó tényleges böngészési munkamenete során felhalmozott CLS-t. Ha egy elem egy kicsit mozog az elején, és egy kicsit görgetés közben, a bővítmény ezt összeadja és kiemeli, így kapja meg a legközelebbi valós értéket, amelyet a Google végül a"Chrome User Experience" (CrUX) jelentésében fog látni.
