Google font include of op eigen server

[Zenda]

Ik vroeg me af wat nou beter is qua SEO / laadtijd / externe bestanden inladen als je een custom font op je website wilt gebruiken. Je kunt via Google fonts een stylesheet inladen of is het handiger als je dit niet doet; de CSS van Google fonts in je eigen CSS toevoegen, fonts downloaden en linken vanaf je eigen server.

Het scheelt wel externe connecties, een referentie naar een tweede CSS bestand dus mij lijkt het beter te zijn, alleen doen grotere websites die zelf over SEO schrijven het niet. Heeft iemand hier een goede theorie over?

Alvast dank.

[RobIII]

Als je een/de CDN gebruikt heb je weer een extra connectie over voor je eigen bestanden (browsers openen max X gelijktijdige connecties per domein) en je hebt kans dat 't bestand al in de cache zit omdat 't van een CDN komt. Ik zou 't dus van externe bron halen (weet eigenlijk niet of je een fallback kunt gebruiken zoals je dat met JS kunt doen, maar vast wel). En dan heb je eventueel nog kleine voordeeltjes zoals dat die CDN's (i.t.t. je eigen domein, tenzij je iets als static.domein.nl gebruikt) cookieless zijn zodat je weer een paar bytes bespaart, de files waarschijnlijk (middels wat DNS magic o.i.d.) geserveerd worden van geografisch gunstig gelegen locaties etc.

[ Voor 43% gewijzigd door RobIII op 01-05-2014 09:46 ]

[Spinal]

Ik zou 100% zeker de externe CSS inladen, die verschilt namelijk per browser. Bijvoorbeeld https://fonts.googleapis.com/css?family=Open+Sans laadt in moderne browsers de WOFF-versie, terwijl die in oude Android de TTF-versie pakt.
Bovendien ben je zo verzekerd dat je altijd de nieuwste versie van de lettertypes hebt.

[André]

Voor wat betreft SEO is dit geen issue, het is milliseconden werk. Ik heb een test gedaan voor een grote NL site en daar bleek het verschil tussen een normale titel of een titel met custom font minimaal. Pas als je de hele pagina in een custom font zet ga je verschillen in je laadtijden zien.

[Zenda]

Thanks voor de replies! Mooi uitgebreid antwoord RobIII. Now I know . Goed idee met de fallback ook. Had een keer gelezen (of ondervonden via Google Speed oid) dat als je meerdere (teveel) CSS bestanden include je daar wel eens een waarschuwing voor kreeg. Maar valt allemaal mee dus. Nogmaals dank, ik ga weer aan de slag .

[crisp]

Het nadeel is wel een extra lookup voor een ander domain wat op high-latency netwerken (bv 3G) behoorlijk merkbaar is. Als je al een dedicated domain gebruikt voor static resources (zoals wijzelf) dan zou ik het zelf hosten. Voor huis-, tuin- en keukenwebsites zou ik inderdaad gewoon de CSS van googleapis includen.

[RobIII]

Zenda schreef op donderdag 01 mei 2014 @ 15:34:
dat als je meerdere (teveel) CSS bestanden include je daar wel eens een waarschuwing voor kreeg

Definieer meerdere / teveel
Sowieso kun je CSS (en JS for that matter) minifyen en vaak kun je meerdere/alle CSS (en JS...) files combineren tot 1 enkele file. En ja, dat scheelt nogal wat HTTP requests en dus merkbaar sneller (ook even zorgen dat je 't gzipped over de lijn duwt (waar mogelijk)).

[ Voor 3% gewijzigd door RobIII op 01-05-2014 18:07 ]

[André]

En dan is het nog geen waarschuwing, maar meer een tip waar je iets mee zou kunnen doen

[Grijze Vos]

Zet de css in je eigen css code, maar link naar de fonts op de cdn. Op die manier voorkom je het downloaden van een extra css bestand, maar heb je wel de voordelen van de gehoste font via de cdn.

[gitaarwerk]

crisp schreef op donderdag 01 mei 2014 @ 15:47:
Het nadeel is wel een extra lookup voor een ander domain wat op high-latency netwerken (bv 3G) behoorlijk merkbaar is. Als je al een dedicated domain gebruikt voor static resources (zoals wijzelf) dan zou ik het zelf hosten. Voor huis-, tuin- en keukenwebsites zou ik inderdaad gewoon de CSS van googleapis includen.

Inderdaad... Je zou natuurlijk DNS precaching kunnen gebruiken ook.

Overigens is de keuze soms ook nog wel eens uit veiligheidsoverwegingen. Cross site scripts wil je soms voorkomen. Als je een CDN hebt kan dat helpen.

Voordeel van wel direct inladen is dat als er al eerder een font ingeladen is op de browser van de gebruiker deze niet weer hoeft in te laden. Vooral inderdaad met 3G is aantal requests verminderen het slimsts.

[crisp]

Er wordt wel vaker gerefereerd aan het vermeende voordeel van cross-site caching bij het gebruik van (Google) CDN's, maar ik denk dat dat voordeel nogal overrated is. Sowieso is de cache-ruimte op vooral mobiele devices zwaar beperkt, en daarnaast zal het voordeel hooguit opgaan voor de meest gebruikte fonts. Kies je voor een meer 'exotisch' font dan wordt de kans dat een andere site die heeft gebruikt, en dat de gebruiker die site (recent) eerder heeft bezocht al heel erg klein.

Hetzelfde geldt ook voor bijvoorbeeld jQuery (door de vele verschillende versies) e.d.

[n8n]

Ik kies er altijd voor om het zelf te hosten, indien mogelijk vanaf een cdn. Ik doe dit om 2 (voor mij) belangrijke punten:

1) je kan je fonts met base64 in een enkel bestand laden (of zelfs in je main stylesheet).
2) Google chrome heeft in Windows ernstige font-rendering-problemen wanneer woff het bestandstype is en er is niks aan te doen. http://www.dev-metal.com/...-rendering-google-chrome/

Wat ik doe is svg gebruiken, dit geeft de mooiste rendering op alle platformen. Voor IE conditional comment ik een eot linked bestand omdat <ie9 geen base64 of svg ondersteunen en je anders nodeloos alle svg-strings inlaadt.

Ja base64 heeft overhead maar dit wordt vrijwel teniet gedaan (2–5%) door gzip compressie. Voordeel is alle fonts in 1 (of met veel bestanden 2) http-request en met svg en eot pak je alle browsers.

Sidenote svg: webkit in iOS ondersteund met svg geen subpixel-antialiased (wel grayschale antialiased) wat opzich geen probleem is (eigenlijk correcter) maar je fonts zien er dunner uit. Sidenote sidenote: op retina devices wordt sowieso geen subpixel-antialiased gebruikt.