Med hjälp av Anpassade Typsnitt Med SVG i en Bild Tag

0
47

När vi producerar en PNG-bild, använder vi en <img> – tagg eller en CSS-bakgrund, och det är ungefär det. Det är superenkelt och garanterat att det fungerar.

PNG är på så sätt enklare att använda i HTML-än SVG

Tyvärr kan detsamma inte sägas för SVG, trots dess många fördelar. Även om du är bortskämd för val när du använder SVG i HTML är det egentligen kokar ned till inline, <object> och <img>, alla med allvarliga gotchas och trade-offs.

Problem med inline SVG

Om du är inlining SVG, du förlorar förmågan att använda webbläsarens cache, Gzip-komprimering mellan servrar och webbläsare, och sökmotor bild indexering (inline SVG är inte att betrakta som en bild). Även om bilden kanske inte har ändrat sig ett dugg, de är alltid laddas och detta orsakar långsammare laddningstiderna för din webbplats, en trade-off som de flesta är inte villiga att tolerera.

Dessutom inlining SVG också orsakar komplexa beroendeproblem där du kan enkelt infoga bilder i HTML och måste ta till script (PHP eller på annat sätt). När du har mer än ett par bilder, detta blir ett stort problem när det gäller att upprätthålla din webbplats, eftersom den i huvudsak kan du inte använda taggen <img> längre.

Ingen tvekan, det finns områden där inlining SVG-lyser — det är, om du vill ha dina bilder för att visa snabbt, utan att vänta på andra resurser för att ladda. Bortsett från detta, klart och tydligt, du bara inte kan inline allt.

Problem med object-taggen

SVG är känd för sin utmärkta kvalitet när de visas på enheter i alla resolutioner, och dess förmåga att hänvisa till externa resurser — som CSS och teckensnitt — samtidigt som filstorleken är mycket liten. Idén är att ha många SVGs som alla delar en enda CSS-eller en enda font-fil, för att minska mängden resurser som du har att hämta.

Myten om resursfördelning

Okänd för många, dela externa resurser för SVG gäller endast inline SVG. Eftersom användning av <object> – taggar som kan ge tillgång till dessa resurser är uppfattningen att webbläsaren kommer att ladda ned en enstaka kopia av din CSS, även om du har många med <object> – taggar som hänvisar till samma CSS-fil.

Detta är dock inte alls sant:

Flera objekt taggar kommer att ladda ner flera CSS

Blanda problemet är det faktum att med <object> – taggar är inte redovisas som en bild, och därför bildsökning indexering inte är möjlig.

Ytterligare förvärra problemet är beroendet frågor. Till exempel, låt oss säga att du har 100 bilder, och 25 av dem använder en font Roboto, ytterligare 25 använda Lato, 25 använda Open Sans, medan resten är en kombination av tre typsnitt. Din CSS skulle behöva hänvisa till alla tre typsnitt eftersom det är helt omöjligt att hålla reda på vilken fil att använda som typsnitt, vilket innebär att du kan fylla på typsnitt du kan inte kräva på vissa sidor.

Bilden tag

Det lämnar oss med <img> – taggen, som har mycket att gå för det. Eftersom det är samma tagg som används för andra bildformat, du får förtrogenhet, browser caching, Gzip-komprimering och bildsökning. Varje bild är i sig själv, utan beroende frågor.

SVG förlora teckensnitt om de används med <img> – taggen

Det enda problemet är att du kommer att förlora dina typsnitt. För att vara mer exakt, om du har någon text i ditt SVG, såvida du inte bädda in teckensnitt, din text kommer att visas med ett typsnitt, typiskt Times New Roman. Du har tillbringat timmar med att välja en vacker typsnitt, men det ögonblick du använda taggen <img> för att bädda in SVG, allt som är förlorat. Hur kan detta vara acceptabelt?

Att undersöka font rastrering

Konvertera typsnitt till banor

Vår första reaktion är att se om vi kan utföra font rastrering. Det är en vanligt förekommande teknik för att konvertera typsnitt till banor, så det ska göra sig bra på alla enheter och behålla noll beroenden. På ytan, detta fungerar mycket väl, och på editor, allt ser perfekt.

Även om de rastrerade SVG kom in på en jättestor 137 KB jämfört med 15.7 KB innan rastrering, vi var optimistiska, eftersom, efter att optimera våra SVG använda Gzip-komprimering, rastrerade fil reduceras till 11 KB, något mindre än motsvarande PNG till 11.9 KB.

Original
Font rastrering
Font rastrering (.svgz)
15.7 KB 137 KB 11.0 KB
PNG @ 1x
PNG @ 2x
PNG @ 3x
11.9 KB 26.5 KB 42.6 KB
En SVG-bild med font rastrering

Ack, när vi bädda in den rastrerade SVG i HTML, vi hittade vår optimism för att vara tidig. Även om det kan se bra på högupplösta skärmar, kvalitet på låg upplösning visas är oacceptabelt.

Rastrerade teckensnitt på toppen och ursprungliga i botten

Den nedre delen av bilden är originalet, med tydligt typsnitt samtidigt, på toppen, teckensnitt är pixlad ut med typsnitt rastrering.

Cleartype skillnad när de visas på skärmar

Vad som händer är att de flesta operativsystem kommer att optimera teckensnitt för att säkerställa att de är klart och skarpt på alla skärmar. På Windows, detta kallas ClearType, och eftersom vi rastrerade våra teckensnitt, inga optimeringar kommer att tillämpas, vilket resulterar i suddiga texten, särskilt synlig på lågupplösta skärmar.

Självklart, en minskning i kvalitet är oacceptabelt, så tillbaka till ritbordet.

Inbäddning av teckensnitt till undsättning

I början, vi var mycket skeptisk till inbäddning av teckensnitt, främst på grund av den komplicerade arbetsflöden.

För att bädda in teckensnitt i SVG, du måste först veta vad font-familjer som används. Då måste du hitta dessa font-filer och ladda ned dem. När du har hämtat, måste du konvertera vanliga, fet, kursiv och fet kursiv stil till Base64-kodning. Om du gör det manuellt, det är helt omöjligt, över ett stort antal filer, för att veta vilken fil som använder fetstil och vilka som inte gör det. Sedan måste du kopiera alla fyra Base64-kodad strängar till din SVG.

Visst, det måste finnas ett bättre sätt. Och det är därför vi byggt Nano. Nano skannar SVG automatiskt och infogar endast de teckensnitt som används. Till exempel, om fet inte används eller om ingen text finns inga typsnitt skall vara inbäddade.

Fortfarande, den resulterande filen är enorm och är inte konkurrenskraftig med PNG likvärdiga, så vi kopplat bort och byggde vår egen SVG optimizer (Nano) som kommer att minska SVG-fil storlekar till en rännil. (Se hur Nano komprimerar SVG.) Dessutom har vi också optimerad hur vi bädda in teckensnitt i SVG, vilket resulterar i mycket små filstorlekar.

En SVG-bild med text, optimerad med Nano och inbäddade teckensnitt

Att jämföra filstorlekar och bandbredd besparingar

Original
Font rastrering
Unoptimized inbäddning av teckensnitt
Nano inbäddning av teckensnitt

Storlek 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

Storlek 11.9 KB 26.5 KB 42.6 KB
Gzip 12.1 KB 26.1 KB Med 41,7 KB

Från ovan kan vi se att Nano ger en SVG-det är extremt lätt-även med inbäddade teckensnitt, kommer in på 11.7 KB (Gzip) jämfört med motsvarande PNG @1x på 11.9 KB. Även om detta kan tyckas obetydlig, skulle den totala bandbredden som sparas på din webbplats kommer säkert att vara betydande.

Låt oss anta att 50% av din trafik är låg upplösning, 40% är 2X upplösning och resterande 10% är 3X upplösning. Om din webbplats har 10.000 träffar på en enda bild:

5,000 * 11.9 KB + 4,000 * 26.5 KB + 1,000 * 42.6 KB = 208.1 KB

Om du använder Nano, komprimerad SVG med GZip:

10,000 * 11.7 KB = 117.0 KB

Detta kommer att resultera i: 208.1 KB – 117.0 KB = 91.1 KB besparingar, eller 43,7 procent, bandbredd besparingar, en betydande mängd av någon åtgärd.

Förutom bandbredd besparingar, du får en mycket enklare arbetsflöde utan att tillgripa flera PNG-bilder med flera srcset, med mycket bättre kvalitet, inklusive operativsystemet font tillbehör för att säkerställa att dina bilder stannar skarpa och tydliga om anordningar för alla upplösningar. Det bästa av allt-en bättre upplevelse för användarna, eftersom din webbplats kommer att läsa snabbare — särskilt på enheter med hög upplösning.

Grundligt testa Nano

Inte nöjd med alla besparingar, vi började leta efter SVG-bilder för att grundligt testa Nano. Totalt till 2 571 SVG-filer i olika storlekar och mönster användes, totalt upp till 16,3 MB. Och efter Nano-optimering, vilket resulterar i 6.2 MB, en häpnadsväckande 61.8% besparingar i storlek.

Ett litet urval av över 2500 SVG-bilder används för att testa Nano

Visar en visuell skillnad

På grund av det stora antalet filer som vi skulle testa, och det ökar från gång till gång, vi måste bygga upp ett automatiserat test, inklusive automatiskt lyfta fram pixel skillnader före och efter optimering. En av de klagomål på andra SVG-optimerare är det faktum att SVG-minifying kan bryta din bild, orsakar det att göra annorlunda jämfört med den ursprungliga.

För detta ändamål, vi bär över pixel differentiering i vår automatiserade test i Nano själv. Det är, Nano kommer att varna dig om det upptäcker att de SVG det optimerar har en pixel är skillnaden mer än 1% jämfört med den ursprungliga, därför se till Nano optimering kommer aldrig att bryta en SVG.

Nano optimering visar visuella skillnaden

Eftersom teckensnitt är inbäddade och bevaras, plus SVG är en vektor grafik format, rendering kvalitet på alla upplösning är ojämförlig till andra raster-format.

Vad är nästa steg?

Vi hoppas att vårt arbete kommer att göra SVG lättare att använda överallt. Vi håller nu på att producera ännu mindre filstorlekar, portering våra koder för att arbeta på Node.js så att du kan automatisera din produktion bygger med Nano, bland andra.

Tror du att du kommer att hitta Nano hjälp i ditt projekt? Låt mig veta i kommentarerna!

Jetpack WordPress plugin som körs på denna webbplats, driver inte bara relaterade inlägg nedan, men säkerhet och backup, Wiki-stöd, sök på sajten, kommentera form, sociala nätverk, och mycket mer!