Karcsúsítja Hugo statikus webhelyét

közzétéve 2020. január 28 körülbelül 9 perc az olvasáshoz

karcsúsítja

Az elmúlt hónapokban rengeteg időt töltöttem azon, hogy minimalizáljam a webhelyem oldalterhelését. Amikor először fejlesztettem ki a Wordpress-ből. Természetesen az előző oldal hatalmas volt; Azt hiszem, valahol egy 2 MB-os oldalterhelés körül futottam, az összes szkript és nagy felbontású kép és egyéb tartalommal együtt. Az egyik célom a Hugo-vá történő átalakítással az volt, hogy ezt csökkentsem, de ezt nem tudtam egyszerre megtenni - néhány lépést meg kellett tennem, hogy eljussak oda, ahol most vagyok, és a folyamat minden bizonnyal nem volt csuklás nélkül. (a kedvencem az volt, amikor 30 MB JPEG-t töltöttem fel az egyik bejegyzésembe, és soha nem méreteztem át). Mindazonáltal úgy gondolom, hogy a dolgokat valószínűleg a lehető legjobb helyre jutottam ezen a ponton, miközben továbbra is lehetővé tettem számomra, hogy kényelmesen dolgozhassak. Ebben a bejegyzésben szeretném áttekinteni azokat a lépéseket, amelyeket megtettem, hogy eljussak a mai helyre.

Kép átméretezése Hugóban

Valószínűleg vannak ennek sokkal hatékonyabb módszerei, de az ötlet alapvetően az volt, hogy a rövid kódból egy csomó különböző tulajdonságot lemásoljon az esetleges képcímkébe. Az egyedüli a longdesc egyedülálló; ehhez beállítottam az oldalkötegben egy erőforrást, amely egy olyan fájlra mutatott, amelynek neve ugyanaz, mint a kép, amelyhez kapcsolódik. Nem használom ezt gyakran, de alkalmanként szükség van rá (főleg képek kollázsaihoz).

A rövid kód végrehajtása után láttam, hogy az oldalméretem - és ami még ennél is fontosabb - az oldal betöltési ideje - drámai módon - 50% -kal vagy annál nagyobb mértékben - csökken a képeket tartalmazó oldalakon. Pedig még nagyon sok munkám volt.

Webfontok eltávolítása

Jó ideje minden oldalbetöltés részeként szolgáltam pár Google betűtípust - Lora és Raleway. Tervezési okokból tettem ezt, de végül úgy döntöttem, hogy a sávszélesség nem éri meg, és a böngésző betűtípusai amúgy is rendben vannak, ezért csak kidobtam őket a CSS-ből, és abbahagytam a betöltésüket. Megmentett még két kérést és egy jó darab sávszélességet.

Ehhez hasonlóan a Font Awesome-ot - ami egy nagyszerű webfont ikoncsomag - használtam a webhelyem ikonjaihoz. Eltávolítva és helyettesítve a linkeket szavakkal, úgy éreztem, hogy javítottam az akadálymentességet, és nem igazán bántottam a dizájnt (vessünk egy pillantást például a láblécre, ahogy ma kinéz). Ez egy másik nagyon egyszerű javítás volt - csak néhány gyors változtatás a témában - és napi megabájtokat spórolt meg nekem sávszélességben.

Csökkentse a HTML-t

Ez nagyon buta és nagyon könnyű. Most kezdtem el a Hugo webhelyemet a hugo - minify segítségével építeni, csak a hugo helyett, és ez eltávolította az összes felesleges helyet. Semmi probléma, és a világon a legegyszerűbb felvenni az összeépítési folyamatba - csak az egy parancsot módosítani.

A jQuery eltávolítása

Gyakran használom a jQuery-t a projektjeimben, mert tudom, hogyan kell használni, és jól érzem magam 3. A jQuery 29 KB-os, ha azt tömörítve és tömörítve tömörítik, aminek meg kell adnia, hogy milyen messze vagyunk itt a nyúl lyukában - a több tíz kilobájtban, a megabájtok helyett, amelyekkel korábban foglalkoztam. Ennek ellenére, a CSS-mel együtt, ez volt a legnagyobb sávszélesség-meghajtó abban az időben, amikor elkezdtem nézegetni, így ez volt a következő lépés - ami végül kissé inkább emelő volt. Szerencsére nem a Bootstrap egyik Javascript-funkcióját sem használtam, ezért nem kellett aggódnom emiatt - de a weboldalamon található összes JavaScript erősen jQuerified volt, így ez azt jelentette, hogy a megjegyzésrendszeremet és a kapcsolatfelvételi űrlapomat tiszta JavaScript-be írtam., majd egy darab teszteléssel, hogy megbizonyosodjak arról, hogy nem csavartam el semmit.

Csökkentse a CSS-t

Ennek az oldalnak a kezdetétől fogva a Hugo beépített moduljaival tömörítettem és összegyűjtöttem a CSS-t. Az első ismétlésem így nézett ki:

Remekül működött, de még mindig a Bootstrap egészét csomagoltam, amikor csak az alapstílust használtam, és ennek nem volt értelme. A Bootstrap nem egy kis CSS keretrendszer, mivel az ilyen dolgokat mérik, és tekintettel arra, hogy ebből mennyit keveset használtam, valójában nem volt értelme számomra az egész baromi dolgot szolgálnom - de biztosan nem fogok belemenni és kivágtam az összes cuccot, amit nem használtam, főleg, ha esetleg a jövőben használom a stílust.

Már egy ideje átgondoltam, hogyan lehet ezt megtenni a Hugo Pipes segítségével, és ez nekem csak nagyon bonyolultnak tűnt. Végül úgy döntöttem, hogy megharapom a golyót, és elmegyek érte, és felépítettem a PostCSS-t és annak purgecss plugint az építési folyamatom részeként. Hugo fórum szálat használtam a kiugrási pontomként, és a megvalósítás végül nagyon egyszerű volt. Csak annyit kellett tennem, hogy telepítettem a csomópontot és az npm-et, felépítettem a config.json fájlt és futtattam az npm install programot - és miután hozzáadtam a megfelelő fájlokat a Hugo témához, tökéletesen működött. Az egyetlen nagyobb gotcha, amellyel összefutottam, az az, hogy meg kellett győződnöm arról, hogy minden CSS osztály, amelyet dinamikusan töltöttem be, vagy közvetlenül hivatkoztam egy bejegyzésre, szerepeljen a purgecss engedélyezőlistámban a postcss.config.js fájlban:

Ezek többsége a megjegyzésrendszer stílusa - és ennek az engedélyezőlistának a nélkül egyikük sem működött volna a közzétett oldalon. Miután ez megtörtént, frissítettem a CSS építési kódomat:

Az általános elképzelés az, hogy összefűznék mindent, aztán futtatnám az összes PostCSS-dolgot, hogy deduplikáljam a szabályokat, és kivegyek mindent, amire nincs szükségem - és ez sikerült! Mindent elmondva, azt hiszem, a CSS körülbelül 90% -át ledobtam a webhelyemre - csak egy csomó olyan dolog, amelyet egyáltalán nem használtak. Ráadásul az eredeti Bootstrap CSS fájl továbbra is jelen van a témában - így ha később több Bootstrap funkciót használok, a PostCSS automatikusan frissíti a CSS-t, hogy tartalmazza ezeket a szolgáltatásokat.

Csomagolás

Sok minden van itt, ami nem tűnik hatalmas változásnak, nem igaz? Például, mi a 20 KB itt vagy ott a dolgok nagy sémájában? Az, ahogyan nézem, ennek azonban akkor számít, ha méretarányosan működik. A 20 ezer KB megtakarítás, amely több ezer vagy több millió oldalra terjed ki, valóban elkezdődhet, és ezért úgy gondolom, hogy a forgalmas webhelyeknél, és különösen azoknál a helyzeteknél, amikor a sávszélességét fizetik, kritikus fontosságú minden sarkot levágni 4. Az összes fenti változás végül körülbelül 70% -kal csökkentette sávszélességemet a webhelyem elindítása óta. Számomra ez még mindig havi centben mért költség, de a CloudFront kihasználó nagy forgalmú webhelyeknél ez sokkal nagyobb különbség lehet. Valószínűleg azonban a legfontosabb a felhasználói élmény; A kérelmek lefelé történő csökkentésével és az oldalméret csökkentésével hozzáférhetőbbé teszi tartalmát az internet-felhasználók spektrumában, egészen a gigabites szálas emberektől egészen a betárcsázást használó emberekig. Azt mondanám, hogy az oldalam bizonyítja, hogy ezt meg lehet tenni az olvashatóság vagy a tervezési filozófia veszélyeztetése nélkül.

A CloudFront konzolon található népszerű objektumok jelentése rendkívül hasznos ehhez - a kiszolgált bájtok szerint rendezheti, amit nagyon hasznosnak találtam. ↩︎

Az egyik nap szeretnék kiemelt tekercset feltenni néhány kedvenc fényképemről, amelyeket készítettem, de ez egy olyan projekt, amely egyelőre a hátsó égőn található. ↩︎

Számomra ezt a Bootstrap használta; A Bootstrap az egyetlen CSS keretrendszer, amelyet valójában tudok használni (igen, tudom, borzasztó vagyok), és ez a jQuery-t csomagolja, így természetes kiterjesztés volt számomra, hogy mindent csak a jQuery-be írtam. ↩︎

Ésszerűség határain belül. Például nem vágom le teljesen a képeket a webhelyemről, de megalapozott döntéseket hozok a felhasználásukról és a webhelyen történő megjelenítésükről. ↩︎