Egyéni betűtípusok használata SVG-vel képcímkében

Tanuljon fejlesztést a Frontend Mastersnél

használata

Amikor PNG képet készítünk, használunk címkét vagy CSS hátteret, és ennyi. Halott egyszerű és garantáltan működik.

A PNG sokkal egyszerűbb a HTML-ben használni, mint az SVG

Sajnos ugyanez nem mondható el az SVG-ről, annak számos előnye ellenére. Bár elkényeztetett a választás, amikor az SVG-t HTML-ben használja, az valóban belefeledkezik, és mindez komoly válaszokkal és kompromisszumokkal jár.

Problémák az inline SVG-vel

Ha beágyazza az SVG-t, akkor elveszíti a böngésző gyorsítótárának használatát, a Gzip-tömörítést a szerverek és a böngészők között, valamint a keresőmotor-indexelést (az inline SVG nem tekinthető képnek). Annak ellenére, hogy a kép valószínűleg egy kicsit sem változott, mindig újratöltődnek, és ez lassabb betöltési időket okoz a webhelyén, amely olyan kompromisszum, amelyet a legtöbben nem hajlandók tolerálni.

Ezenkívül az SVG beillesztése összetett függőségi problémákat is okoz, amikor nem lehet könnyen beilleszteni a képeket a HTML-be, és szkriptekhez kell használnia (PHP vagy más módon). Ha több képe van, ez hatalmas problémát jelent a webhely karbantartásában, mert lényegében már nem használhatja a címkét.

Kétségtelen, hogy vannak olyan területek, ahol az inkluzív SVG ragyog - vagyis ha azt szeretné, hogy a képei gyorsan megjelenjenek, anélkül, hogy megvárná más erőforrások betöltését. Ettől eltekintve egyértelműen egyszerűen nem lehet mindent beilleszteni.

Problémák az objektumcímkével

Az SVG jól ismert kiváló minőségéről, amikor minden felbontású eszközön megjelenik, és képes külső erőforrásokra - például CSS-re és betűtípusokra - hivatkozni, miközben a fájlméret nagyon kicsi. Az elképzelés az, hogy sok SVG-vel rendelkezzen, amelyek mindegyike egyetlen CSS-t vagy egyetlen betűtípust oszt meg, hogy csökkentse a letöltendő erőforrások mennyiségét.

Az erőforrás-megosztás mítosza

Sokak számára ismeretlen, az SVG külső erőforrásainak megosztása csak az inline SVG-re vonatkozik. Mivel a címkék használata lehetővé teszi ezekhez az erőforrásokhoz való hozzáférést, az a felfogás, hogy a böngésző egyetlen példányt tölt le a CSS-ből, annak ellenére, hogy sok címke van ugyanazon CSS fájlra hivatkozva.

Ez azonban egyáltalán nem igaz:

Több objektumcímke több CSS-t tölt le

A problémát az jelenti, hogy a címkéket nem ismerik fel képként, ezért a képkeresés indexelése nem lehetséges.

A probléma további fokozása függőségi kérdések. Tegyük fel például, hogy 100 képed van, és 25 közülük Roboto betűtípust használ, további 25 Lato-t, 25 Open Sans-t, míg a többi a három betű kombinációját használja. A CSS-nek mindhárom betűtípusra hivatkoznia kell, mert lehetetlen nyomon követni, hogy melyik fájl mely betűtípusokat használja, vagyis előfordulhat, hogy betölti azokat a betűtípusokat, amelyekre nincs szüksége bizonyos oldalakra.

Ez megadja nekünk a címkét, amelyre sok minden vonatkozik. Mivel ez ugyanaz a címke, amelyet más képformátumokhoz használnak, megismerheti a böngésző gyorsítótárát, a Gzip tömörítést és a képkeresést. Minden kép önálló, függőségi problémák nélkül.

Az SVG elveszíti a betűtípusokat, ha a címkével együtt használják

Az egyetlen probléma az elveszíti a betűkészletét. Pontosabban, ha van valamilyen szöveg az SVG-ben, kivéve, ha betűtípusokat ágyaz be, a szövege rendszerfontokkal jelenik meg, általában a Times New Roman-tel. Órákat töltött egy gyönyörű betűtípus kiválasztásával, de abban a pillanatban, amikor a címkét használja az SVG beágyazására, minden elveszett. Hogyan lehet ez elfogadható?

Betűtípus raszterizálás vizsgálata

Első reakciónk az, hogy meg tudjuk-e valósítani a betűkészlet raszterizálását. Ez egy általánosan használt technika a betűtípusok ösvényekké konvertálására, így minden eszközön jól megjelenik és nulla függőséget tart fenn. A felszínen ez nagyon jól működik, a szerkesztőn pedig minden tökéletesnek tűnik.

Bár a raszterizált SVG óriási módon jött be 137 KB összehasonlítva 15,7 KB a raszterizálás előtt optimisták voltunk, mert az SVG optimalizálása után a Gzip tömörítéssel a raszterizált fájl 11 KB, valamivel kisebb, mint az egyenértékű PNG 11,9 KB.

Eredeti betűtípus raszterizálás Betűtípus raszterizálás (.svgz)
15,7 KB 137 KB 11,0 KB
PNG @ 1x PNG @ 2x PNG @ 3x
11,9 KB 26,5 KB 42,6 KB
SVG kép betűtípus raszterezéssel

Sajnos, miután beágyazottuk a raszterizált SVG-t a HTML-be, időszerűnek találtuk optimizmusunkat. Bár nagy felbontású kijelzőkön remekül néz ki, az alacsony felbontású kijelzők minősége elfogadhatatlan.

Raszterezett betűtípusok felül, eredeti pedig alul

A kép alja az eredeti, jól látható betűkészlettel, felül pedig a betűkészlet raszterizálással pixelezett.

Cleartype különbség, ha a képernyőkön megjelenik

Az történik, hogy a legtöbb operációs rendszer optimalizálja a betűkészleteket annak érdekében, hogy minden képernyőn világosan és élesen jelenjenek meg. Windows rendszeren ezt hívják ClearType-nek, és mivel raszterizáltuk a betűtípusokat, nem alkalmazunk optimalizálást, ami elmosódott szöveget eredményez, különösen az alacsony felbontású képernyőkön.

Nyilvánvaló, hogy a minőség csökkenése elfogadhatatlan, ezért térjünk vissza a rajzlapra.

Betűtípus beágyazása a megmentéshez

Kezdetben rendkívül szkeptikusak voltunk a betűkészlet beágyazásával kapcsolatban, főként a bonyolult munkafolyamat miatt.

A betűtípusok SVG-be való beágyazásához először tudnia kell, milyen betűtípuscsaládokat használnak. Ezután meg kell találnia ezeket a betűtípusfájlokat, és le kell töltenie őket. A letöltés után a szokásos, félkövér, dőlt és félkövér dőlt betűt kell átalakítania Base64 kódolássá. Ha manuálisan csinálja, akkor nagyon sok fájlnál lehetetlen tudni, melyik fájl félkövér és melyik nem. Ezután át kell másolnia mind a négy Base64 kódolt karakterláncot az SVG-be.

Biztosan van jobb módszer. És ezért építettük a Nano-t. A Nano automatikusan beolvassa az SVG-t, és csak a használt betűtípusokat illeszti be. Például, ha a vastag betűt nem használjuk, vagy ha nincs szöveg, akkor a betűtípusok nem kerülnek beágyazásra.

Ennek ellenére az eredményül kapott fájl hatalmas, és nem versenyképes a PNG-megfelelővel, ezért csatlakoztattuk és felépítettük saját SVG-optimalizálónkat (Nano), amely cseppekre csökkenti az SVG fájlméreteket. (Nézze meg, hogyan tömöríti a Nano az SVG-t.) Ezenkívül optimalizáltuk a betűkészletek beágyazását az SVG-be, ami nagyon kicsi fájlméretet eredményezett.

SVG-kép szöveggel, optimalizált Nano-val és beágyazott betűtípusokkal

A fájlméretek és a sávszélesség-megtakarítások összehasonlítása

Eredeti betűtípus raszterizálás Optimalizálatlan betűtípus beágyazás Nano betűtípus beágyazás
Méret 15,7 KB 137 KB 65,2 KB 22,0 KB
Gzip 3,57 KB 11,0 KB 44,5 KB 11,7 KB
PNG @ 1x PNG @ 2x PNG @ 3x
Méret 11,9 KB 26,5 KB 42,6 KB
Gzip 12,1 KB 26,1 KB 41,7 KB

A fentiekből láthatjuk, hogy a Nano SVG-t gyárt, amely beágyazott betűtípusokkal is rendkívül könnyű, és 11,7 KB (Gzip), összehasonlítva az 1x egyenértékű PNG-vel 11,9 KB. Bár ez jelentéktelennek tűnhet, a webhelyén mentett teljes sávszélesség biztosan jelentős lesz.

Tegyük fel, hogy forgalmának 50% -a alacsony felbontású, 40% -a kétszeres felbontása, a fennmaradó 10% -a pedig háromszorosa. Ha webhelyének egyetlen képen 10 000 találata van:

(5000 * 11,9 KB) + (4 000 * 26,5 KB) + (1 000 * 42,6 KB) = 208,1 MB

Ha Nano-t használ, tömörített SVG-t és GZip-et:

10 000 * 11,7 KB = 117,0 MB

Ennek eredményeként: 208,1 MB - 117,0 MB = 91,1 MB megtakarítás, vagyis 43,7% -os sávszélesség-megtakarítás, jelentős összeg bármilyen méréssel.

A sávszélesség-megtakarítás mellett sokkal egyszerűbb munkafolyamatot kap, anélkül, hogy több src-készlettel rendelkező PNG-képeket kellene igénybe venni, sokkal jobb minőségben, beleértve az operációs rendszer betűtípusának javítását, hogy a képei éles és élesek maradjanak minden felbontású eszközön. A legjobb az egészben: jobb felhasználói élmény a felhasználók számára, mivel webhelye gyorsabban töltődik be - különösen a nagy felbontású eszközökön.

A Nano alapos tesztelése

Mivel nem voltunk elégedettek minden megtakarítással, elkezdtük keresni az SVG képeket, hogy alaposan teszteljük a nanót. Teljes 2,571 Különböző méretű és kivitelű SVG fájlokat használtak, összesen 16,3 MB-ot. A 6,2 MB-os Nano-optimalizálás után pedig elképesztő 61,8% -os megtakarítás érhető el.

Kis válogatás több mint 2500 SVG képből, amelyeket a Nano tesztelésére használtak

Vizuális különbséget mutat

A tesztelt fájlok rengeteg száma miatt, és ez időnként növekszik, automatizált tesztet kell készítenünk, beleértve az optimalizálás előtti és utáni pixelkülönbségek automatikus kiemelését. A többi SVG optimalizálóval szemben támasztott egyik panasz az a tény, hogy az SVG kicsinyítésével megtörhet a kép, és ettől eltérően jelenhet meg az eredetihez képest.

Ennek érdekében az automatizált teszt során a pixel-differenciálást átvisszük magába a Nano-ba. Vagyis a Nano figyelmeztet, ha észleli, hogy az általa optimalizált SVG pixelkülönbsége meghaladja az 1% -ot az eredetihez képest, ezért a Nano optimalizálásának biztosítása soha nem fogja megszakítani az SVG-t.

Nano optimalizálás vizuális különbséget mutat

Mivel a betűtípusok be vannak ágyazva és meg vannak őrizve, ráadásul az SVG vektorgrafikus formátum, a felbontás minden felbontásban összehasonlíthatatlan a többi raszteres formátummal.

Reméljük, hogy munkánk megkönnyíti az SVG használatát mindenhol. Most még kisebb fájlméretek gyártásán dolgozunk, kódjainkat a Node.js-re való áthelyezéssel dolgozzuk, így többek között a nanóval is automatizálhatja a gyártási összeállításokat.

Gondolod, hogy a Nano hasznos lesz a projektjeidben? Mondja meg nekem a megjegyzésekben!