Folytatva, most van még egy pont, amit a Google javasolt nekem: Távolítsa el a JavaScriptet és a CSS-t, amelyek blokkolják a megjelenítést az oldal tetejéről. Most megpróbálom kitalálni, hogy mi a felesleges ott, és hogyan lehet eltávolítani az extra JavaScriptet és CSS-t?
Tesztek, emlékeztetem Önöket, én készítem ezt a szolgáltatást: , ahol konkrét tanácsokat kaptam JavaScripttel és CSS-sel kapcsolatban:
Mint látható, ez a legnagyobb problémám, 8 script töltődik be egyszerre, és emiatt az első képernyő nem töltődik be olyan gyorsan, mint szeretnénk. 10 css fájl is van, amelyek szintén nincsenek optimalizálva. Nos, oldjuk meg a problémát!
Ebben a kérdésben az állítások a következők:
Távolítsa el a megjelenítést blokkoló JavaScriptet:
- https://prostolinux.ru/…-includes/js/jquery/jquery.js?ver=1.10.2
- https://prostolinux.ru/...s/jquery/jquery-migrate.min.js?ver=1.2.1
- https://prostolinux.ru/...query-ui-1.8.10.custom.min.js?ver=1.8.10
- https://prostolinux.ru/...ial-textboxes/js/wstb.js.php?ver=3.10.60
- https://prostolinux.ru/wp-includes/js/tw-sack.min.js?ver=1.6.1
Nemrég találtam egy érdekes megoldást: a function.php-be be kell szúrni egy kódot, amely utasítja a szkripteket, amelyeket nem azonnal kell betöltenünk:
function jquery_in_footer() ( wp_register_script('tie-tipsy', get_template_directory_uri() . '/js/jquery.tipsy.js', array('jquery')); wp_register_script('tie-easing', get_template_directory_uri() js/jquery.easing.1.3.js', array('jquery')) ; )
A példában két szkriptet adunk hozzá, de annyit adunk hozzá, amennyit akarunk, és ezek azok, amelyek lassítják az oldal betöltését. Megpróbáltam alkalmazni ezt a megoldást - nekem nem működött, lehet, hogy valamit rosszul csináltam?
A Google maga azt tanácsolja, hogy illessze be az async attribútumot a szkriptbe, ami aszinkronná tenné a betöltését. De ez a megoldás csak külső szkriptekhez alkalmas, például ez az aszinkron attribútum beilleszthető a Yandex Direct hirdetésszkriptbe, ha annak hirdetése megjelenik az első képernyőn. A Yandexnek is van aszinkron kódja, de ez problémát okozott nekem - ha az egyik blokkban aszinkron betöltés van, a másodikban pedig nem, akkor csak az egyik jelenik meg. De most nem erről van szó...
Nehéz így optimalizálni a bővítményeket, minden beépülő modul kódjába kell bemenni és be kell írni ezt az attribútumot, vagy annak alternatíváját. Nem vagyok programozó és nem is fogok ilyet csinálni. Ezenkívül, ha folyamatosan frissíti a bővítményeket, akkor a frissítés után minden munkája elveszik.
Meglepetésemre találtam egy másik, nagyon egyszerű megoldást erre a problémára – telepítettem az Asynchronous Javascript plugint. A telepítés után a következő eredményt kaptam:
Mint látható, már csak egy szkript maradt, és ez magának a beépülő modulnak a szkriptje. Telepítés után nekem személy szerint nem volt problémám az oldal témájának megjelenítésével, de ha van valamilyen jamb, és azonnali betöltéshez szüksége van valamilyen szkriptre, akkor a bővítmény beállításainál hozzáadhatja a kivételekhez:
Így van megoldva az első pont, de mint látod ez még mindig nem elég, optimalizálni kell a css-t, hogyan kell ezt csinálni?
Íme a követelések listája:
Optimalizálja a CSS teljesítményét a következő erőforrásokon:
- https://prostolinux.ru/...wp-special-textboxes.css.php?ver=3.10.60
- https://prostolinux.ru/...plugins/wp-ds-blog-map/wp-ds-blogmap.css
- https://prostolinux.ru/...t/themes/rockwell_new/rockwell/style.css
Ideális esetben ezt kell tennie: vegye ki az összes adatot ezekből a css-fájlokból, és helyezze át a fő stile.css fájlba, és tiltsa le a kérést magukban a bővítményekben. De mint érti, ez egy hosszú és fárasztó üzlet, tele sok buktatóval. Lehet, hogy a jövőben megteszem, de egyelőre nincs annyi időm és tapasztalatom.
A problémát egy olyan bővítmény telepítésével oldhatja meg, amely az összes stílust egy fájlba egyesíti. Nem találtam olyan bővítményt, amely csak ezt a funkciót látná el, ezért mesélek egy olyan bővítményről, amely mindent egyszerre csinál, eltávolítja a szkripteket és optimalizálja a css-t.
Hogyan lehet mindent egyszerre optimalizálni?Úgy döntöttem, hogy telepítem az Autoptimize plugint, amely egyszerre optimalizálja a szkripteket és a css-t. A bővítmény telepítése után csak el kell lépnie a beállításaihoz, és be kell jelölnie a megfelelő helyen lévő négyzeteket:
Ezt követően a Google Page Speed a következőket adja:
Nincsenek szkriptek betöltve, csak két css fájl, amely tartalmazza az összes stílust, és az összes szkript átkerül a lábléc területére. Ha most megnézed az oldal forráskódját, akkor ott van egy optimalizált zabkása, amit üveg nélkül nem tudsz kitalálni.
Először azt hittem, hogy ez a plugin nem oldja meg teljesen a problémáimat, de mint kiderült, ez azért van, mert nem konfiguráltam teljesen! Miután bejelöltem a megfelelő helyen lévő négyzeteket, NAGYON NAGY eredményt kaptam! MINDEN PROBLÉMA MEGSZŰNT! 
Ehhez kattintson a tetején található Speciális beállítások megjelenítése gombra, majd további beállítások jelennek meg. Be kell jelölnie a következő négyzeteket:
Optimalizálja a HTML kódot?
Optimalizálja a JavaScript kódot?
Csak a következőben keres szkripteket? (elavult)
Optimalizálja a CSS kódot?
Inline minden CSS?
Az összesített szkript/css mentése statikus fájlként
Ezek után az igazság az, hogy nálam leállt a widgetet javító plugin, de ez egyáltalán nem probléma, sokkal fontosabb az oldal betöltési sebessége. És még ennél is fontosabb, hogy a Google bácsi kedvében járjon...
Egy árnyalatot is szeretnék megemlíteni: ezen az oldalon van egy adaptív sablonom, és ha használod, akkor a plugin a mobil verzió megjelenítésekor nem tud teljesen minden problémát kiküszöbölni. Amikor engedélyezem a mobilverziós beépülő modult, nem marad hiba. Ismét meggyőződtem arról, hogy jobb, mint az adaptív dizájn.
Egy másik hasonló plugin a WP Minify Fix, ugyanazt csinálja, de nekem kevésbé tetszett, vagy csak nem értettem teljesen.
Megértem, hogy ideális mindezt beépülő modulok nélkül, manuálisan megtenni, de nagyon hosszú és sivár, és tényleg nem éri meg, mert még ha eléri a 100-as pontszámot, akkor sem fogja a csúcsra hozni az oldalt - az oldal betöltési sebessége csak EGY a több száz rangsorolási tényező közül, elég módja és fontos. De tegyél meg mindent, amit csak tudsz – kell!
A Google PageSpeed JavaScript és a CSS-kód eltávolítása
Nem talált választ? Használja a webhelykeresőt
A HTML kód és a lépcsőzetes stíluslapok (CSS) optimalizálása szükséges az oldal és a rajta tárolt tartalom betöltési folyamatának felgyorsítása érdekében. Az idő- és forgalommegtakarítás általában az optimalizálás utáni hosszú idő után jelentősnek bizonyul, még akkor is, ha a sebességváltozás kívülről nem nagyon érezhető.
HTML kód optimalizálásAhhoz, hogy a HTML kód hozzájáruljon az oldal gyors betöltéséhez, több feltételnek kell megfelelnie:
- Legyen egyszerű és informatív. Az érvényesség ellenőrzése után ki kell javítania a hibákat, hogy a botok könnyebben elemezzék azokat. A kódnak egyértelműen tükröznie kell az oldal szerkezetét.
- Az oldalak fő összetevői, mint a címsorok, indexek, információblokkok könnyen és gyorsan azonosíthatók legyenek.
- Ha megszabadítjuk a kódot a felesleges információktól, külön fájlokba helyezzük (például CSS-t és JS-t is rakhatunk), megnő a letöltési sebesség, ami a botok munkáját is leegyszerűsíti.
Ezen feltételek teljesítésével az oldal gyorsabbá, kényelmesebbé tehető, és a keresőrobotok általi indexelésének hatékonysága növelhető.
Kódcsökkentés és CSS optimalizálás
Könnyebbé teheti a webhely kódját a hangerő csökkentésével. Ehhez több műveletet kell végrehajtania.
Először is kerülni kell a flash technológiákat, JavaScriptet, kereteket, képpel ábrázolt szöveget. Az összes elemet, ha lehetséges, különálló, külső fájlokban kell megjeleníteni (például CSS és JS, amint azt fentebb megjegyeztük). Speciális bővítmények segítenek a kód optimalizálásában. Például telepítheti az Autoptimize plugint, amely automatikusan optimalizálja a HTML, CSS, JS kódot (ha bejelöli a megfelelő négyzeteket). Be kell állítani egy hozzáértő és kényelmes webhely-navigációt, amely érthető lesz a felhasználók számára, és helyesen ismeri fel a keresőmotorok. Ez növeli a sebességet, a betöltés minőségét és a webhely indexelését.
Ami a CSS-optimalizálást illeti, ezt megteheti saját maga, vagy rábízhatja egy speciális erőforrásra vagy programra. A kézi optimalizálás idő- és időigényes folyamat, emellett néhány hiba is kimaradhat. Az optimalizálásra szolgáló program vagy szolgáltatás jobban kiküszöböli a hiányosságokat, de megzavarhatja az oldalon működő egyes funkciókat, és az ellenőrzés után a tartalom nem jelenik meg megfelelően, ezért a munkájukat javítani kell.
Néhány módszer a CSS-struktúra manuális javítására:
- Távolítsa el a felesleges szóközöket és sortöréseket, amelyek túlterhelik a CSS-fájlt, és megnehezítik a robotok munkáját;
- Írjon általánosító tulajdonságokat a hasonló parancsok többszöri ismétlése helyett;
- Használjon tömör, érthető leírásokat a megjegyzésekben;
- Írjon szokatlan betűtípusokat stílusok, ne képek használatával;
- A képekhez hozzon létre alt és címet (minden képhez más), hogy azok tartalmát felismerjék a keresőrobotok;
- Alkalmazza a H1 eszközöket a címsorokra - és így tovább, hogy azokat helyesen felismerje az indexelés során;
- A kulcsszavakban csak azokat a kulcsszavakat írja elő, amelyeket az oldalon használnak, minimalizálja a számukat;
- Használjon változatos és tömör metacímkéket.
CSS és HTML optimalizálók
Kényelmesen és gyorsan optimalizálhat közvetlenül a böngészőben speciális szolgáltatások segítségével, például:
- CleanCSS.com;
- CSS-optimalizáló;
- CSS kompresszor
- CYPR.com;
- beépülő modul engedélyezése.
A SEO és IT szakértők a CleanCSS.com használatát tanácsolják, mivel ez lehetővé teszi a tömörítési szint kiválasztását alacsonytól a magasig, vagy egyéni beállítások kiválasztását. Magas és legmagasabb szintű optimalizálás után a webhely kódja szinte olvashatatlanná válik, és szinte lehetetlen lesz módosítani rajta. Ezért először a szabványos optimalizálást kell használnia. Kiválaszthat tömörítési módokat adott tartalomhoz, vagy optimalizálhatja az egyes paramétereket: betűtípusok, képek tömörítése, szóközök eltávolítása.
A CY-PR.com-on is van egy hasonló optimalizáló eszköz, amely 25-30%-kal könnyíti a CSS-struktúrát, de nincs mód kódfájl generálására a művelet után.
A többi szolgáltatás radikálisan megváltoztathatja a kódot, így a webhely egyes funkciói leállnak. Ezért segítségükkel jobb, ha csak helyi változtatásokat hajtanak végre az adott webhelyparamétereken.
Az optimalizálás után ellenőriznie kell az oldal teljesítményét, a dizájn helyes megjelenítését és a letöltési sebességet. Normális az a helyzet, amikor a webhely oldalai és felhasználói beállításai legfeljebb 3-5 másodpercig töltődnek be.
Az optimalizálás mértékének ellenőrzéséhez és annak megértéséhez, hogy a HTML-kód most milyen hatékonyan íródott, használhat olyan szolgáltatásokat, mint például:
- optimization.com;
- Portál seo-ellenőrző lista;
- firebug plugin.
Ezek az eszközök segítenek ellenőrizni, hogy mindent megtettek-e a HTML-kód mennyiségének csökkentése és szerkezetének javítása érdekében. A SEO ellenőrzőlista erőforráson ellenőrizheti az optimalizálás érdekében már elvégzett és még meg nem végzett listát, valamint megjelölheti a befejezett tetteket.
Az érvényesítés-ellenőrző szolgáltatások – érvényesítők – segítségével ellenőrizheti a webhely kódját, hogy vannak-e hibák. A hatékony kódellenőrzés a validator.w3c.org segítségével történik
Ha az első ellenőrzéskor félezernél több hibát generál a rendszer, akkor nem kell elkeseredni. Egy bizonyos hiba kijavítása után újra lefuttathatja az ellenőrzést, és sokkal kevesebb lesz a hiba, mivel egy hiba másokat is tartalmaz, és ha kijavítják, azok eltűnnek.
Egy javított és optimalizált kóddal rendelkező webhely nagyobb valószínűséggel kerül előkelő helyre a keresési eredmények között, mint egy túlterhelt, hibákat tartalmazó HTML-kóddal rendelkező webhely.
Ez a folyamat a szükségtelen vagy redundáns kód eltávolítására a CSS-fájlokból a fájl méretének csökkentése érdekében az oldalbetöltési sebesség növelése érdekében.
Íme 10 CSS-optimalizáló eszköz, amelyek segítségével gyorsan és egyszerűen rendszerezheti és optimalizálhatja CSS-jét.
Mindannyian tapasztaltuk már azt a problémát, hogy várni kell az oldal megjelenítésére, amíg az összes beépülő modul és stílus be nem töltődik. Néha nehéz webhelyeken hosszú ideig tart az összes fájl betöltése. A Critical Path CSS Generator szolgáltatás használatával megkerülheti ezt a problémát. Lehetővé teszi CSS kód létrehozását úgy, hogy az oldal megnyitásakor azonnal betöltődik az úgynevezett újsághajlításig (első képernyő) tartó rész. Ez a módszer pozitív hatással van a keresőoptimalizálásra.
Sziasztok, a blogoldal kedves olvasói. Továbbra is részletesen tanulmányozzuk az oldal felgyorsításának lehetőségeit az ajánlások betartásával, amely valódi gyakorlati tanácsokat ad a hibák kijavításához.
A képtömörítés megvalósításáról már írtam ezzel az eszközzel, most a következő lépés a CSS és a scriptek (javascript) optimalizálása, ami komoly, sokszor akár meghatározó adalékot jelenthet az oldalak betöltésének sebességének növelésében.
A mai cikkben leírom az ezzel a szemponttal kapcsolatos összes gyakorlati lépést, és megpróbálom figyelembe venni az összes lehetséges árnyalatot, amely az ilyen események lépésről lépésre történő megvalósítása során felmerülhet.
Távolítsa el a CSS-kódot és a szkripteket az oldal tetejéről, és egyesítse őket egy fájlbaTehát annak megértéséhez, hogy pontosan milyen tevékenységeknek kell tartalmazniuk a stílusok és szkriptek optimalizálását kifejezetten az Ön webhelyére, a legegyszerűbb módja a jól ismert PageSpeed eszköz szolgáltatásainak használata, amelyet a cikk elején említettem.
Mielőtt továbblépnék, a következőket szeretném elmondani. A webhelytulajdonosok túlnyomó többsége CMS-t használ projektjeihez (). Sajnos nincs univerzális utasítás a szükséges műveletek elvégzésére abszolút minden CMS-re vonatkozóan, mivel mindegyiknek megvannak a maga finomságai.
Elemezzük a CSS és a script optimalizálás gyakorlati árnyalatait a WordPress blog () alapján, mivel a webes erőforrások ezen formája az egyik legnépszerűbb.
Az ellenőrzés rendszerezése és az időmegtakarítás érdekében célszerű lenne kiválasztani az egyik legtöbbet "betöltött" oldalt, amelyhez képest a legtöbb stílus és szkript végrehajtásra kerül (ha kiküszöböli a főbb hibákat akkor a többiek nagy valószínűséggel magas besorolást kapnak a Page Speed-től).
Mivel WP-blogon gondolkodunk (ez a webes forrás is ehhez az oldaltípushoz tartozik), elmagyarázom, hogy milyen típusú oldalakat választottam tesztelésre, és egy szemléltető példát választottam. Nem titok, hogy egy szabványos blogon a posztok (cikkek) oldalaira nehezedik a fő terhelés, hiszen ezek tartalmazzák a legtöbb letölthető tartalmat (képeket is), felhasználói kommenteket, és vannak kitéve különféle kiterjesztéseknek is.
Például a cikkoldalakon a webhely saját stílusokkal és szkriptekkel működik. És néhány bejegyzésben gyakran használom a Syntaxhighlighter Evolved funkcióit, amelyeknek köszönhetően a különböző kódok gyönyörű töredékei kiemeléssel jelennek meg.
Ez az egyik oldal, amelyet tesztelésre ajánlok fel, és bemutatom az általam a hiányosságok kiküszöbölésére tett későbbi intézkedéseket. Tehát az elemző oldalon adja meg a kívánt weboldal URL-jét, és néhány másodpercen belül megkapja az eredményt. Íme néhány stílus- és szkriptelési hiba, amelyet a Page Speed talált:
Először is vessünk egy pillantást a Paige Speed első szkriptelési tippére, amely a következő: „Távolítsa el a megjelenítést blokkoló JavaScriptet”:
//site/wp-includes/js/jquery/jquery.js?ver=1.12..min.js?ver=1.4..js?ver=4.8.2
A Page Speed tanácsa szerint a további funkciókért felelős JavaScript kódokat az oldal felső részének elemeinek megjelenítése után kell végrehajtani, ami felgyorsítja az oldal betöltését.
Az első két sor, amely a könyvtár kimenetére vonatkozik, és a harmadik, amely a Feliratkozás megjegyzésekre plugin fent említett szkriptjének működését tükrözi, éppen szükséges az ilyen funkciók biztosításához. Ezért kívánatos ezekre az erőforrásokra mutató hivatkozásokat elhelyezni a HTML-kód alján. De a sablonok egyszerű kézi szerkesztése () itt nem elegendő.
Megjegyzem, korábban a Page Speed az elemzés eredményei alapján gyakran adott ki külön ajánlást a szkriptek és stílusok kombinálására. Ha jól értem, most egy oldal kiértékelésekor ilyen tanácsok közvetlenül nem elérhetőek, de mindenképpen beleértendők.
A helyzet az, hogy amikor más eszközökkel teszteljük egy webhely weboldalainak betöltési idejét, akkor ez az optimalizálás az egyik leghatékonyabb és legkötelezőbb, kivéve, ha ez természetesen károsítja az oldal funkcionalitását.
Ezért a szkriptek és stílusok tekintetében a teljes lehetséges intézkedéskészletet végrehajtjuk (beleértve nemcsak a fejterületről való eltávolításukat, hanem egy közös fájlba való összevonásukat is). Ehhez a WordPress számos funkcióval rendelkezik, amelyek a következő feladatokat hajtják végre:
- wp_deregister_script, wp_deregister_style- törli a stílusok és CSS-fájlok regisztrációját;
- wp_register_script, wp_register_style— szkriptek és stílusfájlok regisztrálása;
- wp_enqueue_script, wp_enqueue_style— összeköti a szkripteket és a CSS-t a munkával.
Ezeknek a funkcióknak a használata lehetővé teszi az összes ilyen erőforrás ellenőrzését, figyelembe véve az egyik függőségét, és kiküszöböli egymás közötti konfliktusukat. Ez alapján fogjuk megoldani az előttünk álló problémát.
A jQuery könyvtár betöltése a Google CDN-rőlElőször is elmondom, hogy a JQuery olyan szkriptek gyűjteménye, amely kész függvényeket tartalmaz, és segít a fejlesztőknek JavaScript-kód írásában. Jelenleg sok webmester használja ezt a könyvtárat, mert lehetővé teszi néhány „chip” alkalmazását a webhelyen. Mondjuk ezen a blogon az egyik jQuery-vel végrehajtott elem a fejléc felett van.
Nem véletlen, hogy a WordPress legújabb verzióiban a fejlesztők hozzáadták azt a lehetőséget, hogy a könyvtárat magából a motor tárolóiból csatlakoztassák és töltsék be. Ezt bizonyítja a Page Speed eszközzel végzett elemzés eredményeként talált URL-ek megjelenése:
//site/wp-includes/js/jquery/jquery.js?ver=1.12..min.js?ver=1.4.1
Ebben az esetben a "ver=1.12.4" a verziót jelenti. Érdekes a második link, ami, ahogy valószínűleg sejtitek, szintén a könyvtárhoz kapcsolódik. Ez egy szkript ("jquery-migrate.min.js"), amelyet kifejezetten a régebbi verziókról való átállásra és az inkompatibilitási problémák megoldására használnak.
Vagyis ha egy régi beépülő modul fut a webhelyén, amelyhez a korábbi verziók valamelyike szükséges, akkor a jquery-migrate.min hozzájárul a kiterjesztés kódjának megfelelő működéséhez a könyvtár új módosításával együtt.
Megszokásból igyekszem megszabadulni a régóta nem frissített beépülő moduloktól, és a megfelelő kódokat alkalmazni, amelyek tartalma kielégíti a könyvtár legújabb verzióját. Ezért úgy döntöttem, hogy letiltom ezt a kiegészítő szkriptet, amelyet az alábbiakban tárgyalok.
Ha emlékszik, a PageSpeed-elemzés eredményei alapján el kell távolítania a szkripteket az oldal HTML-kódjának fejrészéből. Ehhez a WP rendelkezik egy megfelelő funkcióval, amely segít a hivatkozást a láblécbe helyezni. Egyébként ezzel egy időben úgy döntöttem, hogy a könyvtárbetöltést úgy konfigurálom, hogy az ne a WP mappából, hanem magából a Google CDN hálózatból legyen betöltve.
Emlékeztetjük Önöket, hogy biztonsági okokból a webhely fájljainak megváltoztatásakor tanácsos biztonsági másolatot készíteni róluk, valamint speciális szoftvert, például a NotePad ++ szerkesztőt használni, amely lehetővé teszi, hogy annyi lépést visszalépjen, kedveled.
Ez a döntés azon a tényen alapult, hogy a CDN ( Tartalomszolgáltató hálózat vagy Tartalomelosztó hálózat- tartalomszolgáltató hálózat) számos előnnyel jár, nevezetesen:
- biztosítja, hogy a JQuery átkerüljön a számítógépéhez (földrajzilag) legközelebbi szerverről, ami felgyorsítja a letöltést;
- nagy a valószínűsége annak, hogy a könyvtár jelen van a felhasználó böngészőjének gyorsítótárában, ha korábban már felkereste az Ön webhelyét;
- a fájl tömörített formában kerül megadásra, ami csökkenti a súlyát;
- a könyvtár egy külön szálban lesz betöltve.
A Google jQuery CDN legfrissebb verziójának a fenti szándékokkal összhangban történő kiadásához törölnie kell a könyvtár regisztrációját a WP-ben (ne feledje, hogy a CMS-hez kapcsolódóan elemezzük az optimalizálást), majd újra kell regisztrálnia a következő módon. függvényt, amelyet a functions.php varázsfájlba kell beírni:
Függvény my_scripts_method() ( wp_deregister_script("jquery"); wp_register_script("jquery", "//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js", false, null, true); wp_enqueue_script ("jquery"); ) add_action("wp_enqueue_scripts", "my_scripts_method");
Ezt a kialakítást használtam, amikor követtem a Paige Speed ajánlásait. A JQuery regisztráció letiltásával automatikusan megszüntetjük a jquery-migrate hozzárendelését, ami után csak egy hivatkozás jelenik meg a könyvtárra az oldal HTML kódjának legalján:
Ennek az erőforrásnak a láblécbe való mozgását a szkript regisztrációs sorának utolsó "true" argumentuma határozza meg:
Wp_register_script("jquery", "//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js", false, null, true);
Itt kell szem előtt tartani, hogy a könyvtári szkript csak akkor jelenik meg az oldal alján, ha egy ilyen pozíció nem zavarja a bővítményekkel való interakciót, amelyek helyes működése attól függ. Ellenkező esetben az "igaz" argumentum nem fog működni, és a jQuery a fejrészbe kerül.
Elképzelhető, hogy a könyvtár legújabb módosítása nem fog működni bizonyos szkriptekkel a webhelyén, majd próbálja meg ezt az opciót használni a kívánt verzió jelzésére (természetesen az 1.8.3 helyettesíthető bármilyen mással):
Függvény my_scripts_method() ( // unregister jQuery wp_deregister_script("jquery"); wp_register_script("jquery", "//ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js?ver= 1.8 .3", false, null, true); wp_enqueue_script("jquery"); ) add_action("wp_enqueue_scripts", "my_scripts_method");
Még ha webhelye szerkezete és a meglévő szkriptek halmaza nem teszi lehetővé, hogy a kimeneti kódot a HTML-oldalak aljára helyezze a "true" attribútum jelenléte ellenére, akkor is pozitív eredményt fog elérni a sebesség növelésében. az oldal, mivel a könyvtár a Google CDN hálózatáról töltődik be.
Tiltsa le a stílusok és szkriptek regisztrációját, hogy egyesítse őketAz általunk törölt, majd újraregisztrált JQery könyvtárat csak a láblécbe próbáltuk áthelyezni, hogy az ne lassítsa az oldalak tetején lévő elemek betöltését. De a többi szkriptet, valamint a CSS-stílusú fájlokat, miután letiltjuk a regisztrációjuk törlésével, egyetlen közös formátumba fogjuk egyesíteni őket.
A WordPress oldalak oldalainak betöltési idejének minimalizálása érdekében ajánlatos az összes szkriptet egy speciálisan létrehozott, .js kiterjesztésű fájlba helyezni a témakönyvtárban, és egyedi CSS-stílusokat hozzáadni a meglévő style.css stílusfájlhoz. ugyanaz a téma.
Ehhez a webes erőforráshoz készítettem egy ilyen fájlt (codes.js) a JavaScript számára is, amelynek elérési útját a footer.php sablonban regisztráltam a záró body tag előtt (ezt a HTML kódban láthatod a legalján). bármely blogoldalra kattintva):
Ebben nem csak az összes regisztrált plugin szkriptet szúrok be a regisztráció törlése után, hanem a manuálisan hozzáadott JavaScriptet is (közösségi gombok kódjai, számlálók stb.). Ezért az ellenőrzés eredményeiben a PageSpeed csak a Subscribe to Comments plugin szkriptjét jelölte meg, amelyet még nem volt időm megfelelően optimalizálni.
Tehát első lépésként hozzon létre egy egységesítő JavaScript-fájlt .js kiterjesztéssel. Közvetlenül a WordPress témakönyvtárába (/your_theme/codes.js) helyezheted el, valamiért én is a „js” almappába (/tiny-forge/js/codes.js) helyeztem el.,
Ezután foglalja bele a létrehozott fájlt úgy, hogy beilleszti a fenti konstrukciót a footer.php sablonba a . Természetesen a fájl elérési útjában ne felejtse el a „site” szót a domainjére cserélni, és a „tiny-forge” helyett a téma nevét is beírni. Nézze meg a szkriptek egyesítéséről szóló videót is:
");">
Ezt követően törölnie kell az összes olyan beépülő modul szkriptjét, amelyre a Page Speed mutatott. De ellentétben a JQuery könyvtárral, amely nem helyezhető el egy közös fájlba, ezeket a szkripteket nem regisztráljuk az új szabályok szerint, mivel később egyszerűen kombináljuk őket. Ebből a célból hozzá kell adni egy kis függvényt ugyanazokhoz a functions.php-hez:
Függvény my_deregister_javascript() ( wp_deregister_script("ID-1"); wp_deregister_script("ID-2"); wp_deregister_script("ID-3"); ) add_action("wp_print_scripts", "my_deregister_javascript", 100);
De hogyan lehet megtalálni ugyanazokat az azonosítókat (regiszterneveket) az egyes bővítményekhez? Ezt a SyntaxHighlighter példán keresztül mutatom be. Ez a példa lesz a legsokoldalúbb, mivel ez a beépülő modul összetett fájlszerkezettel és számos aktív szkripttel rendelkezik, amelyek helyét az oldal HTML kódjában megjelenített elérési utakból lehet megtalálni:
//site/wp-content/plugins/syntaxhighlighter/syntaxhighlighter2/scripts/shCore..js //site/wp-content/plugins/syntaxhighlighter/syntaxhighlighter2/scripts/shBrushCss.js
Annak ellenére, hogy ezek az erőforrások nem lassítják a fő tartalom betöltését (mivel az oldal alján töltődnek be) a Page Speed szerint, kombinációjuk nagyon kívánatos, mint minden más szkript. A fenti URL-ek segítségével meghatározhatja a SyntaxHighlighter beépülő modulhoz tartozó összes mappát, amelyben ezek találhatók.
Bármely WP-bővítmény fájljai általában tartalmazzák a mellékelt szkript regisztrációját (wp_deregister_script) és annak belefoglalását (wp_enqueue_script). Ezeknek a soroknak a segítségével keresheti a regiszterek nevét a plugin könyvtárában található mappákban, például a NotePad++ () segítségével:
Így a tesztelt oldalon három SyntaxHighlighter szkriptet le kell tiltani a tartalmuk későbbi másolásához és beillesztéséhez az általunk már létrehozott egyesítő fájlba:
Függvény my_deregister_javascript() ( wp_deregister_script("syntaxhighlighter-core"); wp_deregister_script("syntaxhighlighter-brush-php"); wp_deregister_script("syntaxhighlighter-brush-css";_script); ) add_, gip_myvactionde 00);
A SyntaxHighlighter azonban összetett felépítésű, így a másolt tartalom megosztott fájlba való beillesztése után az oldalon a szintaktikai kiemelés nem működik. Természetesen ki lehet kapcsolni a szkripteket, majd a segítségével kiválasztani az oldalon megjelenő kód színét, de az árnyalat ebben az esetben egységes lesz.
Az interneten számos lehetőséggel találkoztam a probléma megoldására, de mindegyik nem teszi lehetővé a teljes funkcionalitás mentését, ezért számomra elfogadhatatlan. Ezért egyelőre mindent az "eredeti formában" hagytam ezzel a pluginnal kapcsolatban, főleg, hogy a PageSpeed csak az egyik szkriptjének tömörítését javasolta, amit meg is tudunk valósítani. De erről alább, ha a következő optimalizálási lépéshez érünk.
Ami a Reloaded-et illeti, okoskodnom kellett, aminek eredményeként ennek a pluginnak az azonosítóját határoztam meg (legalábbis sikerült letiltani, ami kellett). Ennek megfelelően a regisztráció törlési funkciója, amelyet ismét a WP téma functions.php-jába kell helyezni, az én esetemben így néz ki (ezt a kódot teljesen másolhatja és használhatja, ha a Google PageSpeed jelezte, hogy optimalizálni kell ezt a szkriptet) :
Függvény my_deregister_javascript() ( wp_deregister_script("stcr-plugin-js"); ) add_action("wp_print_scripts", "my_deregister_javascript", 100);
Tehát, miután letiltotta az összes optimalizálandó szkriptet (meghatározza a fájlok helyét az oldalsebesség-ellenőrzés eredményeiben jelzett útvonal mentén), másolja ki a tartalmát, és illessze be a korábban létrehozott közös fájlba. Felhívom a figyelmet arra, hogy a script kódokat tiszta formában kell beilleszteni, a és címkék elhagyása mellett, különben egyik sem fog működni.
Ezt követően csatolja be az egyesítési fájlt a szakasz elején található kóddal. Ennek eredményeként a JavaScript többé nem akadályozhatja meg a fő tartalomelemek betöltését az oldal tetején.
Kitaláltuk a szkripteket, most nézzük meg, hogy a Page Speed milyen CSS-forrásokra esküszik:
A CSS-stílusok optimalizálásának lépései nagyjából hasonlóak a JavaScripthez leírtakhoz. Igaz, a téma style.css főfájlja egységesítő fájlként fog működni, ahová hozzáadjuk a többi stílusfájl másolt tartalmát. Sőt, nincs értelme a style.css-t beletenni a láblécbe, különben sérülhet az oldal helyes megjelenítése. Kiderült, hogy a CSS-optimalizálás csak a stílusok kombinálásából áll.
Blogom tesztelt oldalához ajánlások vannak feltüntetve, ismét az StCR bővítményre vonatkozóan, amely saját stílusfájllal (stcr-plugin-style.css) rendelkezik, valamint a betűkészlet-könyvtárakkal, amelyek közül az egyik regisztrálva van és benne van. Iratkozz fel a Comments Reloaded oldalra, és a másik kettőt magában a WP témában aktiváltuk. Ehhez a bloghoz nincs szükségem rájuk, elég a standard készlet, ezért úgy döntöttem, egyszerűen kikapcsolom őket.
Most a cikkben már említett SyntaxHighlighter beépülő modult szeretném érinteni, amelynek szkriptjeit úgy döntöttem, hogy eredeti formájukban hagyom, de itt a stílusai megtalálhatók a „CSS kód minimalizálása” teszteredmények részben, ami megegyezik a a tömörítési eljárás:
Ezeket az erőforrásokat elvileg külön-külön is tömöríthetjük, de a maximális optimalizálás érdekében, mint mondtam, jobb, ha átmásoljuk a tartalmukat és beillesztjük a téma alap style.css fájljába, amely az összes szükséges CSS stílus beillesztése után tömörítésre kerül. optimalizálás. Először azonban fel kell venni őket a 4 deaktiválható erőforrás listájára, kivéve a fő style.css fájlt (lásd a második képernyőképet innen felfelé).
A stílusregisztráció letiltásához használja ugyanazt a funkciót, amellyel deaktiváltuk a szkripteket a fent leírt módszerrel:
Függvény my_deregister_styles() ( wp_deregister_style("stcr-plugin-style"); wp_deregister_style("stcr-font-awesome"); wp_deregister_style("tinyforge-fonts"); wp_deregister_style("fontlesive_style" syntaxhighlighter-theme-default"); wp_deregister_style("syntaxhighlighter-core"); ) add_action("wp_print_styles", "my_deregister_styles", 100);
A regisztrált stílusazonosítók egyébként a NotePad++ keresésében is megtalálhatók a "wp_register_style" és a "wp_enqueue_style" kifejezések használatával, de a JavaScripttel ellentétben ez sokkal egyszerűbb. Legalább gyorsan megtaláltam az összes szükséges nyilvántartási nevet.
Mint mondtam, a betűtípusokat ("stcr-font-awesome", "tinyforge-fonts", "elusive-iconfont-style"), csak letiltottam, de a bővítmény CSS-fájlok tartalmát ("stcr-plugin-style" , " syntaxhighlighter-theme-default", "syntaxhighlighter-core") kimásolva és beillesztve a style.css fájlba. Hadd emlékeztesselek arra, hogy az összes optimalizálandó stílusfájl helyét az oldalsebesség-elemzés eredményei jelzik.
De van itt egy nagyon fontos árnyalat. Mielőtt bármilyen kiterjesztés stílusszabályait átviszi a style.css fájlba, győződjön meg arról, hogy vannak-e háttér- vagy háttérkép-tulajdonságok, amelyek paramétere lehet egy url a használt kép elérési útjával, amely a következőként jelenik meg. egy tervezési elem (a keresésük ugyanazzal a Notpad ++ használatával végezhető):
Háttér-kép: url(images/image-1.png)
Ha vannak ilyen tulajdonságok, akkor az összes relatív URL-t abszolút (teljes) URL-ekké kell konvertálni a következő minta szerint:
Background-image:url(http://your_domain/wp-content/plugins/plugin-1/images/image-1.png)
Ez azt jelenti, hogy ebben a példában meg kell adnia a -t, amely a beépülő modul képeit tartalmazó mappához vezet, ahol a kívánt grafikus fájl található. Ellenkező esetben a WordPress nem fogja megtalálni a képet, és ezért nem jelenik meg.
A CSS és JavaScript fájlokat online tömörítjükAz utolsó optimalizálási lépés előtt valamilyen módon összefoglaljuk az általunk megtett lépéseket, ez némileg egyértelművé teszi a folyamatot, melynek leírásában átmeneteket kellett végrehajtanunk, hogy kiemeljük a nem szabványos helyzetek által elindított különböző forgatókönyveket:
- a fent leírt tevékenységek eredményeként létrejött egy közös JS fájl, ahová a “wp_deregister_script” függvény által letiltott összes script másolt tartalmát elhelyeztük;
- letiltotta azoknak a stílusoknak a regisztrációját, amelyek lassítják az oldal betöltését a "wp_deregister_style" aktiválásával, ezek egy részének tartalma (szükséges) átmásolódott és hozzáadásra került a style.css téma fő stílusfájljához;
Mielőtt folytatná, hadd emlékeztessem önöket arra, hogy a SyntaxHighlighter beépülő modullal kapcsolatban úgy döntöttem, hogy megtartom a teljes funkcionalitást, és nem kombinálom a szkriptjeit, mivel azok nem működnek egy közös fájl részeként. A Page Speed azonban rámutatott arra, hogy sürgősen le kell rövidíteni (tömöríteni) a CSS-kód szintaxis kiemeléséért felelős szkriptek egyikét:
De lehet majd tömöríteni a közös JavaScript fájllal és a style.css-szel együtt. Ehhez ismét tesztelnie kell ezt az oldalt a PageSpeed alkalmazásban:
Mellékesen szeretném megjegyezni, hogy a szkriptek és stílusok eltávolítására tett intézkedések az oldal kódjának fejrészéből, valamint a fájlok egyesítésére tett erőfeszítések nem maradtak észrevétlenül.
Az optimalizálás pontszáma komolyan nőtt, és elérte a 82 pontot a 100-ból a mobiltelefonok esetében, de a PC-k esetében a zöld zónába került (90), ami a Google által bemutatott szinte összes fő ajánlás végrehajtását jellemzi.
A 8 forrásból (3 szkript és 5 CSS-dokumentum) csak egy maradt meg, ez a fő style.css fájl, amelynek elérési útját meg kell hagyni a weboldal tetején, hogy a böngésző megfelelően jelenítse meg az összetevőjét. elemeket.
Elvileg ez már méltó eredmény, bár kívánság szerint javítható. Csak le kell töltenie a Google által már optimalizált erőforrásokat (a fenti képernyőképen a linkek a legalul), beleértve a ZIP-archívumba csomagolt CSS- és JavaScript-dokumentumokat is.
Az elemzett oldalhoz, amelynek tesztje alapján optimalizálást végeztem, a tömörítettek között szerepelt a style.css, egy közös JavaScript fájl és az általam említett chBrushCss.js, amelyeket a hangoztatott okok miatt nem kombináltam más szkriptekkel. felett.
Biztosan más lesz a redukción átesett fájlok összetétele, de úgy gondolom, hogy az ilyen helyzetben szükséges ötlet és eljárás egyértelmű. A számítógépre való letöltés után csomagolja ki az archívumot, és cserélje ki a szerveren lévő eredetik tartalmát tömörített verziókra.
Fontos figyelni a következőkre. Az oldalsebesség korlátozza a csonka fájlok elérését. Ha az optimalizált dokumentumok össztömege meghaladja a 10 MB-ot (ez ritka, de előfordul), akkor az erőforrások egy része nem lesz tömörítve, azonban a róluk és a helyükről szóló információk (URL) egy speciális Manifest fájlban jelennek meg. , amely szintén ZIP-archívumban van csomagolva:
Ezen információk alapján saját maga is tömörítheti a szkripteket és a CSS-fájlokat online szolgáltatások segítségével, amelyekből sok van a hálózaton. Amúgy ne keverjük össze a stílusok és a JavaScript csökkentését, ami a megjegyzések, szóközök, sortörések, blokkok elválasztásával jár, a -val, amely során más algoritmusokat alkalmaznak.
Lerövidítheti a CSS-t online speciális szolgáltatások segítségével. Például annak érdekében, hogy csökkentsem az egyik projekt style.css fájlját, ezt az eszközt választottam, mivel három tömörítési szint közül választhat ("Light" - light, "Normal" - standard és "Super Compact"). - maximum), amire szüksége van:
A termelékenység és a befolyás hatékonysága szempontjából az utóbbi tűnik a legelőnyösebbnek. Ne feledje azonban, hogy a Super Compact használatakor az optimalizált CSS-kód szóközök nélkül egy sorba kerül, ami egyértelműen rontja az olvashatóságot, és emiatt a jövőben megnehezíti a szerkesztést.
Ebben az esetben, mivel rendszeresen módosítom az aktuális CSS-tulajdonságokat, és új CSS-tulajdonságokat adok hozzá, hogy kényelmesebb legyen az oldal stílusának módosítása, a kedvenc "sweet spot"-omat választottam a Normál szint formájában.
Én személy szerint elégedett voltam a szabványos tömörítési feltételekkel. Most bejelöltem a "Minden megjegyzés csíkozása" opciót a megjegyzések teljes eltávolításához. Előfordulhat azonban, hogy a kódcsökkentési művelet végrehajtása előtt finomhangolni kell. Ezután nyissa meg a további opciókat, amelyeket a „Speciális mód” hivatkozáson keresztül érhet el.
Miután eldöntötte a beállításokat, másolja ki a rövidíteni kívánt stíluskódot, illessze be a közvetlenül a beállítások alatt található mezőbe, és nyomja meg a „tömörítés” gombot (lásd a fenti képernyőképet). Kapja meg frissített kódját másodpercek alatt:
A tömörítés befejezése után (aminek eredményeként például a webhelyem forrásfájljának tartalma 29%-kal "elveszett"), kiválaszthatja a kapott kódot a "Kód kiemelése" gombbal, majd másolhatja, majd beillesztheti. az eredeti helyett a Notepad ++ használatával.
Csak az online CSS-tömörítés befejezése és a stílusok frissítése után ne felejtse el ellenőrizni a webhely oldalai elemeinek megjelenítésének helyességét. Ezenkívül be kell jelentkeznie az összes népszerű böngészőbe ().
Annak érdekében, hogy érthetőbb legyen, hogy ez vagy az a CSS-fájl mi miatt van tömörítve, az alábbi kép segítségével bemutatom az eredeti verziót:
És így nézett ki tömörítés után:
Ez a minta eredetileg csak a WordPress-téma fő style.css fájljában szereplő stílusok voltak, anélkül, hogy más stílusokkal, köztük bővítményekkel kombinálták volna. Az összes CSS-tulajdonság kombinálása után a tömörítési nyereség sokkal nagyobb lehet.
A JS fájlok esetében a maximális tömörítés (redukció) mellett döntöttem, mivel én magam nem szerkesztem őket a szükség hiánya miatt (rendkívül ritka a szkriptek tartalmi módosítása, mindenesetre egyszerűbb a csere teljes kód).
Lerövidítheti a JS fájlokat online szolgáltatásokkal is, amelyek közül az egyik legmegbízhatóbb az Online YUI Compressor:
Itt minden hasonló a CSS gyorsíráshoz. A "Tömörítés" gomb megnyomása után másolja ki az eredményt, és cserélje ki a forrásfájl tartalmára. A cikkben ismertetett összes tevékenység végén ismét teszteljük a tesztoldalt az Oldalsebességben:
Mi az első dolog, ami megakad a szemedben? Persze az, hogy még pár ponttal feljebb került a pontszám, és a zöld zónába került (PC-nél és mobileszköznél is). A "JavaScript rövidítése" tanács eltűnt az ajánlások listájáról (ha emlékszel, a SyntaxHighlighter beépülő modul egyik szkriptjéhez volt társítva).
Annak ellenére, hogy vannak még javaslatok ezen és más hasonló oldalakon ( , kód eltávolítása a felső részből, ), ezek teljes körű megvalósítása nem lehetséges azon egyszerű oknál fogva, hogy az ilyen lépések az oldal funkcióinak egy részének letiltásával járnak majd, ami például számomra elfogadhatatlan.
Ráadásul a zöld zónában elért pontszám azt sugallja, hogy a további lépések nem vezetnek jelentős előrelépéshez az oldal felgyorsításában, de sok értékes időt igényelnek. Tehát, ha sikerült elérnie a 85-90 pontot, akkor ezen a ponton elvégezhető az oldalsebesség-ajánlással kapcsolatos műveletek.
Sőt, további módszerek is vannak az oldalak betöltésének sebességének növelésére, amelyekről időben tájékozódhat, ha e-mailben feliratkozik a blogfrissítésekre. Nézzen meg további 2 videót, amelyek a WordPress szkriptek és stílusok optimalizálásáról szólnak a WP Fastest Cache gyorsítótár-bővítménycsomag és az Autoptimize bővítmény használatával: Denis
Minden egészséget. MUTATÓK A GOOGLE OLDALOM SEBESSÉGÉBEN 100/100 http://sibvaleogroup.ru
Sokáig tesztelték. Milyen módszerek és technikák nem alkalmazhatók, hosszas próbálkozás és tévedés és kellemes eredmény bónusz formájában;). Az oldal témája nagyon keresett: Hogyan indítsunk vállalkozást? És betegségek megelőzése és kezelése! Természetes ECO termék!
Üdvözöljük a Mutatók megtekintése oldalon! Ha valami, kérem keressen, tudok segíteni, csak vedd figyelembe, én csak amatőr vagyok, nagy tapasztalattal! Tisztelet mindenkinek!
Sziasztok, a blogoldal kedves olvasói. Ma szeretném megtörni a hagyományt (egyenletesen írja le az összes címsort), és felhívja a figyelmet a cikk második részére.
Az a tény, hogy sokkal könnyebb írni, ahogy mondják, forró nyomon, és nem később emlékezni: „hogyan tehettem ezt?”, Ami meglehetősen nehéz lehet, különösen egy idő után.
Próbáljuk tovább növelni a sebességet egy olyan eszköz segítségével, mint a Page Speed, amely a Mazila vagy a Chrome kiegészítőjeként van telepítve. Elvileg valószínűleg hiába mondtam egy korábbi cikkben, hogy ez a plugin önmagában nem tud semmit felgyorsítani a projekteden, csak ajánlásokat ad, hogy pontosan mire is érdemes odafigyelni. Kiderült, hogy ő maga is tud tenni valamit.
A CSS optimalizálása és tömörítése oldalsebességgelAz utolsó cikkben részletesen tárgyaltuk a Page Speed plugin telepítését, és a statikus objektumok (képek, szkriptek, stílusok) gyorsítótárának optimális beállítását a felhasználói böngészőkben.
Az általunk elvégzett webszerver-beállítások után ez a beépülő modul már nem esküdött a sebesség erőteljes csökkenésére a „Böngésző gyorsítótárának kihasználása” miatt:
Valójában a Page Speed rámutat arra, hogy szinte minden stílusfájl, amely a látogató böngészőjébe és a blogom weboldalába is betöltődik, jelentősen optimalizálható (tömöríthető), hogy csökkentse súlyát.
Ha a „CSS kicsinyítése” melletti pluszjelre kattint, megnyílik azon objektumok listája, amelyeket érdemes lenne optimalizálni (tömöríteni):
De a legfigyelemreméltóbb az, hogy maga a plugin elvégzi az összes optimalizálási (tömörítési) munkát. Nézze meg figyelmesen, a sor végén az egyes nem optimalizált stílusfájlok nevével az ablakban megjelenik az optimalizált (tömörített) verzió megtekintése, és ha szeretné, töltse le a lépcsőzetes stíluslap fájlt, amely ingyenes a szemetet, ami lehetővé teszi, bár egy kicsit, de növeli a letöltési sebességet.
Az optimalizálás abból áll, hogy eltávolítunk belőlük minden felesleges szóközt és megjegyzést, amelyek semmilyen módon nem befolyásolják az erőforrás működését, de bár kicsi, de mégis többletsúlyukkal lassítják a betöltődést.
Például a WordPress témámhoz mellékelt optimalizálatlan style.css-em majdnem 2000 soros volt, és az optimalizálás után sikerült 400-ra csökkentenem a sorok számát, és maga a fájl egyötödét veszítette eredeti súlyának. Utána pedig sokkal jobban tetszik a benne előírt tulajdonságok megjelenése.
Ítélje meg maga, így nézett ki, mielőtt sikerült oldalsebességben tömöríteni:
És így néz ki az optimalizálás után:
Tehát ehhez csak a tömörített verziót kell letöltenie a "Mentés másként" hivatkozásról. Letöltve?
Most csatlakozzon FTP-n keresztül, menjen abba a mappába, ahol az eredeti stíluslapfájl található (lásd az elérési utat a Page Speed ablakban), és cserélje ki a régi tömörítetlent az újra (azzal, amelyik az Ön számára lett optimalizálva), ne felejtse el adja meg ugyanazt a nevet, mint az eredetinek, különben a lépcsőzetes stíluslapok nem működnek. Bajusz, élvezd azokat az ezredmásodperceket, amelyekkel webhelye betöltése felgyorsult.
De a fő CSS-fájlon kívül, amely általában az Ön által használt témához tartozik, az Oldalsebesség ablakban azokat a stílusfájlokat is láthatja, amelyeket a WordPress (vagy bármely más használt motor) telepített bővítményei és kiterjesztései használnak. . Elvileg ugyanúgy tömörítheti őket, mint fentebb tárgyaltuk.
Hogyan lehet a külső CSS-t egyetlen közös fájlba egyesíteniDe a legjobb megoldás az lenne, ha az összes külső CSS-t egyesítené, és csak ezután tömörítené az oldalsebesség használatával. Ez lenne a tökéletes lehetőség néhány ezredmásodperccel a letöltési sebesség növelésére. Valójában maga a beépülő modul éppen egy ilyen lehetőséget javasol a „Külső CSS kombinálása” mezőben:
Itt felajánlja, hogy az általa talált összes külső fájlt (a külső szkriptek egybe is kombinálhatók - „Külső JavaScript kombinálása”), a látogatók böngészőjébe betöltötték, egy közös fájlba egyesítsük, de minden szükségtelent le kell tiltani. stílus fájlok. A probléma az, hogy sok közülük bővítményeket vagy egyéb bővítményeket hoz létre és tartalmaz a motorjához.
Természetesen beléphet a beépülő modul kódjába, és onnan letilthatja a stílusokat, de ha frissíti ezt a bővítményt, előfordulhat, hogy újra be kell ásnia a bővítmény belsejébe, hogy ismét letilthassa. A WordPress esetében van egy mód a probléma központi megoldására, az Ön által ismert eszközökön keresztül, amelyeknek jelen kell lenniük a használt témával rendelkező mappában:
/wp-content/themes/WordPress téma neve/functions.php
Ha nem találja a functions.php fájlt, egyszerűen létrehozhatja, például a Notepad++ szerkesztőben, és feltöltheti a WordPress téma mappájába. De az biztos, hogy továbbra is ott lesz. Ehhez hozzá kell adnia egy kis PHP kódot, például:
Add_action("wp_print_styles", "my_deregister_styles", 100); function my_deregister_styles() ( wp_deregister_style("google-ajax-translation"); wp_deregister_style("syntaxhighlighter-theme-default"); wp_deregister_style("syntaxhighlighter-core"); wp_deregister_style("wp_deregisterf-style("wp_deregisterf-style("wp_deregisterf-style) q" ;)
Ezzel megszüntetjük a WordPress egyes beépülő moduljainak stílusát. Ennek eredményeként ezeknek a bővítményeknek az egyes CSS-fájljai nem töltődnek be a látogatók böngészőjébe.
És még ha frissíti is bármelyiket, semmi sem fog változni, és nem kell újra beleásnia a kódjukba. Hát azóta elég gyakran frissülnek, akkor egy ilyen ravasz kikapcsolási móddal jelentősen megspóroljuk az időnket és az idegeinket.
Minden egyszerűnek tűnik - kikapcsolták és ennyi, elfelejtheted. Igen, nem úgy. Előtte minden WP-bővítmény kódjában (amelyben letiltjuk a stílusok betöltését) meg kell találni azt a regisztert, amelyik felelős az összekapcsolásukért.
Ha közelebbről megnézi a fenti kódot, észre fogja venni azokat a sorokat, ahol ezek a regiszterek vannak felsorolva:
wp_deregister_style("google-ajax-translation"); wp_deregister_style("syntaxhighlighter-theme-default"); wp_deregister_style("syntaxhighlighter-core"); wp_deregister_style("wp-pagenavi"); wp_deregister_style("cfq");
Vagyis például egy csodálatos WordPress beépülő modulnál a regiszter neve „wp-pagenavi”, a Comment Form Quicktags plugin esetében pedig „cfq” lesz. Ha ugyanazokat a kiterjesztéseket használod, mint én, akkor nem tudsz belemászni a PHP kódjukba, hanem kölcsönkérhetsz regisztereket a fenti kódból.
De az összes saját stílusfájllal rendelkező beépülő modul letiltásakor ne felejtse el átmásolni ezeknek a leginkább letiltott CSS-eknek az összes tartalmát, hogy egy közös fájlba egyesüljön a téma mappából (én style.css-nek hívom). Érthető, igaz?
Valószínűleg van fogalmad arról, hogy mi forog kockán. Egy ilyen CSS-tulajdonság például így nézhet ki:
Translate_links .translate_flag(background:url(flags.png) no-repeat;border:0;margin:0;padding:0;)
Az url(flags.png) bejegyzés azt jelenti, hogy a flags.png nevű képet ugyanabban a mappában kell keresni, mint magát a lépcsőzetes stíluslap fájlt. De a helyzet az, hogy ha az összes beépülő modul stílusának tartalmát másolja, akkor valószínűleg ilyen relatív útvonalakat fognak használni a képekhez.
Ez pedig oda vezet, hogy a WordPress nem fogja tudni megtalálni a kívánt képeket a megadott relatív útvonalon. Végül is továbbra is a mappákban maradtak a bővítményekkel. Ezért a CSS kombinálásakor feltétlenül le kell cserélni a háttérképek relatív elérési útjait abszolút olyanokra, amelyek valahogy így néznek ki:
Miután ezt megtette, a saját stílusát letiltott beépülő modulok által használt összes háttérkép visszaáll az eredeti helyére. Igen, szerintem bírod.
Egyébként, miután az összes stíluskódot egy közös fájlban tárolta, ne felejtse el újra tömöríteni a Page Speed segítségével úgy, hogy az ablakában keresse meg a CSS minimálása nevű sort, és kattintson a felirat melletti plusz jelre, és majd másolja az optimalizált "Mentés másként" fájlt. Ezután cserélje ki a mappában lévő eredeti fájlt a WordPress témával.
Vegyünk most egy konkrét példát annak bemutatására, hogy hol kell keresni a WordPress plugin-regiszter nevét, amely lehetővé teszi a stílus betöltésének letiltását. Valójában a megfelelő regiszter megtalálásához szükségünk lesz egy PHP kiterjesztésű fájlra a plugin mappájából. Általában mindegyik ugyanabban a mappában él:
/wp-content/plugins
Ezért itt kell keresnie a kívánt könyvtárat. Vegyük például a SyntaxHighlighter Evolvedet, mert Meglehetősen szokatlan a helyzet, amikor több stíluslapot használ, attól függően, hogy melyik stílusbeállításokat választotta ki a bővítmény beállításaiban.
Amint láthatja, azt a nézetet választottam, amely a beépülő modul második verziójában volt, és alapértelmezés szerint a SyntaxHighlighter színséma van használatban. Most az ő mappájába kell lépnem úgy, hogy FTP-n keresztül csatlakozom a bloghoz:
/wp-content/plugins/syntaxhighlighter/syntaxhighlighter2/styles
másolja le a két letiltani tervezett CSS-fájl tartalmát: shCore.css és shThemeDefault.css , mert rajtuk mutatja meg a Page Speed egy ujjal (nos, a beállításoknál az alapértelmezett témát választottam, amihez logikusan a megfelelő nevű CSS-re van szükségünk).
Ezt követően nyissa meg szerkesztésre:
/wp-content/plugins/syntaxhighlighter/syntaxhighlighter.php
Aztán keress és olvass. Keressen valamit, amely tartalmazza a "CSS" kifejezést. A syntaxhighlighter.php fájlban ez lenne a kódrészlet:
// Téma stíluslapok regisztrálása wp_register_style("syntaxhighlighter-core", plugins_url("syntaxhighlighter/" . $this->shfolder . "/styles/shCore.css"), array(), $this->agshver); wp_register_style("syntaxhighlighter-theme-default", plugins_url("syntaxhighlighter/" . $this->shfolder . "/styles/shThemeDefault.css"), array("syntaxhighlighter-core"), $this->agshver); wp_register_style("syntaxhighlighter-theme-django", plugins_url("syntaxhighlighter/" . $this->shfolder . "/styles/shThemeDjango.css"), array("syntaxhighlighter-core"), $this->agshver); wp_register_style("syntaxhighlighter-theme-eclipse", plugins_url("syntaxhighlighter/" . $this->shfolder . "/styles/shThemeEclipse.css"), array("syntaxhighlighter-core"), $this->agshver); wp_register_style("syntaxhighlighter-theme-emacs", plugins_url("syntaxhighlighter/" . $this->shfolder . "/styles/shThemeEmacs.css"), array("syntaxhighlighter-core"), $this->agshver); wp_register_style("syntaxhighlighter-theme-fadetogrey", plugins_url("syntaxhighlighter/" . $this->shfolder . "/styles/shThemeFadeToGrey.css"), array("syntaxhighlighter-core"), $this); wp_register_style("syntaxhighlighter-theme-midnight", plugins_url("syntaxhighlighter/" . $this->shfolder . "/styles/shThemeMidnight.css"), array("syntaxhighlighter-core"), $this->agshver); wp_register_style("syntaxhighlighter-theme-rdark", plugins_url("syntaxhighlighter/" . $this->shfolder . "/styles/shThemeRDark.css"), array("syntaxhighlighter-core"), $this->agshver);
Megnézzük, mely regiszterek teszik lehetővé az shCore.css és shThemeDefault.css stílusok betöltésének letiltását. Kimásoljuk a nevüket (esetemben ezek lesznek: syntaxhighlighter-theme-default és syntaxhighlighter-core), és hozzáadunk két további sort a functions.php fájlhoz (a témát tartalmazó mappából) a fent leírt kódrészlethez:
wp_deregister_style("syntaxhighlighter-theme-default"); wp_deregister_style("syntaxhighlighter-core");
És ezt megismétli minden olyan WordPress beépülő modulnál, amelynél le szeretné tiltani a stílusbetöltést. Remélem, minden világos és érthető lett számodra. Ha nem, akkor próbáld meg újraolvasni, mert nem túl könnyen érthető a téma, bár igyekszem nem feleslegesen bonyolítani, nehezíteni a szöveget (kinek kell részlet, mert minél egyszerűbb, annál jobb).
Az összes manipuláció eredményeként a functions.php-ben egy egész sor listája lesz a plugin-regiszterekkel, amelyek stílusait le kell tiltani. És egy közös CSS-fájlban, a téma mappából, tartalmazza a webhely összes stíluskódját. Hadd emlékeztesselek még egyszer – ne felejtsd el tömöríteni vagy más szóval optimalizálni a style.css fájlt a Page Speed segítségével a fent leírt módon.
Sok szerencsét! Hamarosan találkozunk a blogoldalak oldalán
Lehet, hogy érdekel
A functions.php fájl a WordPress téma mappájából és valós példák a használatára 
Hogyan lehet maximalizálni a webhely betöltési sebességét és optimalizálni a kiszolgáló betöltését ingyenes WordPress témák és sablonok - Hol lehet letölteni 
Hogyan készítsünk egy gyors webhelyet - a képek és szkriptek optimalizálása (tömörítése), valamint a HTTP-kérések számának csökkentése 
Hogyan találhat meg és távolíthat el nem használt stíluskarakterláncokat (extra választókat) webhelye CSS-fájljában 
WordPress téma (sablon) optimalizálás a tárhelyszerver terhelésének csökkentése, a WP Tuner bővítmény és az adatbáziskérések számának csökkentése érdekében 
CSS sprite-ok létrehozása a Sprites Me online generátorban a kiszolgálóhoz intézett kérések számának csökkentése érdekében 
Témák a WordPresshez – milyen sablonokból állnak, és hogyan működik mindez 
A WordPress memóriafelhasználásának csökkentése oldalak létrehozásakor – WPLANG Lite bővítmény a lokalizációs fájl helyettesítésére 
Cikkek írása a WordPressben - Vizuális és HTML szerkesztők, címsorok és kulcsszókiemelés 
Gzip-tömörítés a webhely betöltésének felgyorsítása érdekében – hogyan engedélyezheti a Js, Html és Css számára a .htaccess fájl használatával
