Google Fonts API - rewolucja czy redundancja?
Na odbywającej się właśnie konferencji Google I/O 2010 internetowy gigant zaprezentował swój nowy produkt - tytułowe Google Font API szybko okrzyknięte przez niektórych zbawieniem webdeveloperów, krokiem ku przyszłości czy "jednolinijkowym rozwiązaniem". Czy aby na pewno?
Na początek wypada wyjaśnić o co właściwie chodzi. Każdy, kto kiedykolwiek zajmował się na poważnie tworzeniem serwisów internetowych wie, że możliwość korzystania z różnorodnych dostępnych czcionek ograniczona jest tym, jakie czcionki posiada zainstalowany odwiedzający - jeżeli nie ma tej, którą wybraliśmy, wyświetli mu się alternatywna (zdefiniowana przez nas lub przez jego przeglądarkę). Oczywiście pojawiały się różne próby dodania obsługi czcionek w CSS - jednak jak to bywa z przeglądarkami, Microsoft wprowadził do IE swoje standardy, część przeglądarek zaczęła adaptować rozwiązanie zaproponowane dla CSS3, IE6 nie obsługiwał prawie nic .... Teraz, kiedy zbliża się czas w którym IE6 będziemy mogli porzucić a większość przeglądarek zdaje się już finalizuje obsługę font-face z CSS3 możemy zacząć rozważnie stosować te technikę.
Jak to dokładnie działa? W CSS możemy zdefiniować sobie nowe czcionki w oparciu o udostępnione przez nas pliki, np:
@font-face {
font-family: Delicious;
font-weight: bold;
src: url('Delicious-Bold.otf');
}
Zadeklaruje nam nową czcionkę o nazwie "Delicious" i do jej wyświetlenia użyje pliku "Delicious-Bold.otf" dostępnego na naszym serwerze. Oczywiście, każdy z użytkowników musi pobrać te czcionkę co powoduje dwie rzeczy:
- Do czasu pobrania czcionki tekst wyświetlany jest przy użyciu czcionki alternatywnej
- Każdy użytkownik musi pobrać plik czcionki przez co wzrasta transfer nasz i odwiedzającego
I tutaj wchodzi Google - nowa usługa polega na udostępnianiu czcionek prosto z serwerów Google co pozwala nam zaoszczędzić na transferze, odwiedzający zaś pobierze czcionkę tylko raz - jeżeli przejdzie na inną stronę, która także używa danej czcionki i również korzysta z usługi Google nie musi pobierać jej ponownie.
I o ile jest to rozwiązanie korzystne na pierwszy rzut oka, o tyle nie jest ono w żaden sposób rewolucyjne - nie jest to żadne "end-all" rozwiązanie wprowadzające jakąś technologiczną nowość czy dodające funkcjonalność, której do tej pory przeglądarki nie miały. Nie sprawi to, że magicznie nowe czcionki pojawią się w IE6 - po prostu jest to rozwiązanie CSS3 wykorzystujące CDN (ang. content delivery network, sieć dostarczania treści - pozwala to na dostarczenie użytkownikowi materiałów z serwera który znajduje się "najbliżej" jego lokacji) Google.
I tu pojawia się problem dla mnie. Po pierwsze dodajemy kolejny supełek na linie łączącej nas z Google - jeżeli nagle panom znudzi się usługa i postanowią ją wyłączyć zostajemy na lodzie i mamy kilka stron do poprawienia. Czcionki dodawane do Google Font Directory udostępniane są na licencji open source, co daje nam pewność, że nie każą nam za nie nagle płacić, ale wybór (na razie) jest mizerny. No i pozostaje sam CDN - mam nadzieję, że będzie działać on dużo lepiej niż Google AJAX Libraries API który potrafi notorycznie wieszać się i wisieć na "Trwa pobieranie z google..." co w przypadku JS potrafi zawiesić działanie reszty strony.
Ktoś powie, że ten ostatni problem jest specyficzny dla JS i nie powinien powodować problemów w CSS - przecież czcionkę pobieramy raz. Czcionkę tak, plik CSS od Google nie - jeżeli serwer będzie odpowiadał wolno, przyjdzie nam czekać na załadowanie CSS by wskazał czcionkę, którą już mamy na dysku.
Podsumowując - cały szum wokół Google Font API zdaje się być zupełnie chybiony - cała "aplikacja" jest przecież tylko frontendem do Google Font Directory pozwalającym w 2 linijkach HTML i CSS zrobić to, co od dłuższego czasu możemy zrobić w 3-4 CSS...
aktualizacja: okazuje się, że byłem w błędzie i jak to wytkną mi trójkąt w komentarzach Google Fonts API radzi sobie nawet w IE6 (chociaż u mnie mało stabilnie, ale może to być wina nie natywnej wersji IE6 - IETester). Jeżeli żądanie czcionki wyjdzie z "nowej" przeglądarki - serwer Google odpowie nam wysyłając czcionkę w formacie TTF. Jeżeli zaś to samo żądanie, pod ten sam URI wyślemy z IE6 - serwer Google wyśle nam plik EOT - jest to format czcionek obsługiwanych przez IE od dłuższego czasu.
Biję się w pierś i przyznaje - jednak jest w tym rozwiązaniu coś interesującego :-)
Komentarze
Komentarz użytkownika pecet
20 05 2010Podsumowując - cały szum wokół Google Font API zdaje się być zupełnie chybiony
Ale Google to zrobiło, czyli automatycznie musi być to jakaś innowacja ;)
Komentarz użytkownika BTM
20 05 2010Tak jak masa innych innowacji, o których dzisiaj już nikt nie pamięta? Ok, może jest to jakiś pomysł, ale nie jest wart całego zamieszania jakie wywołał.
3
Komentarz użytkownika radmen
20 05 2010Google IMO zachowuje się podobnie do Apple. Z małej pierdoły robią wielkie wydarzenie ;) Pomysł mi się podoba, chociaż gdybym miał z tego korzystać w większym projekcie to raczej bym sobie skopiował te arkusze i czcionki na własny serwer.
Komentarz użytkownika pecet
20 05 2010radmen +1, swoją drogą więcej by zyskali jakby nie używali opensourcowych fontów, ale załatwili licencje na jakieś komercyjne, które umożliwiały by każdemu ich użycie, ale tylko za pomocą produktu Google właśnie ;)
Komentarz użytkownika Kamil
20 05 2010Mimo to wielu ludzi korzysta z jQuery zamieszczonym na serwerach Google, co w wielu przypadkach rzeczywiście bardzo dużo zwiększa szybkość działania strony. Plik taki jest pobierany przez system CDN, jak już wspomniałeś, a co więcej, prawie każdy użytkownik posiada już zbuforowany plik w przeglądarce lub systemie. Jakby tego było mało, transfer nie jest pożerany z Twojego serwera, a serwerów Google.
Jak na moje same zalety, choć nic innowacyjnego :-) A jeśli się obawiasz, iż Google nagle usunie lub zablokuje usługę, to czemu by się nie zabezpieczyć? Wystarczy po prostu napisać kilka linijek, które sprawdzą czy czcionka istnieje na serwerach Google, a jeśli nie - pobierze ją z Twojego serwera. Czcionka będzie następnie buforowana u użytkownika, także nie powinno być problemów z wydajnością takiego rozwiązania.
Komentarz użytkownika BTM
20 05 2010@radmen: no i to właśnie jest to, co mi w ogóle nie pasuje w tym rozwiązaniu. Z jednej strony zaleca się kompresowanie plików, nie rozrzucanie ich po serwerach żeby zmniejszyć ilość zapytań do zewnętrznych źródeł (dzięki czemu klient nie musi nawiązywać nowego połączenia, resolvować DNS etc.) a z drugiej Google wyskakuje z taką decentralizacją.
Komentarz użytkownika BTM
20 05 2010@Kamil: ja osobiście nie korzystam i pluje sobie w brodę, że kiedyś korzystałem. Jak już pisałem nie raz zdarzyło mi się, że ładowanie JS z serwera Google zawieszało cały serwis. Może Ci się wydawać, że plik pobierany jest tylko raz z Google AJAX API - co jakiś czas sprawdzane jest czy pojawiła się nowsza wersja pliku etc. i na prawdę nie raz nie dwa zdarzyło mi się, że strona muliła z tekstem "Oczekiwanie na google.com" czy innym w pasku.
8
Komentarz użytkownika radmen
20 05 2010@BTM: trochę bym się kłócił z tym nie rozrzucaniem po serwerach. Teraz przeglądarki mają standardowo ustawione po kilka wątków pobierających dane z jednej domeny, rozbij to na kilka domen i ta ilość wątków nagle wzrasta.
W większości wypadków nie posiadamy łącz komórkowych, a te też już nie są takie wolne. Poza tym w wypadku CSSów i fontów to jak taki arkusz się nie załaduje to tragedii nie ma. Jeśli czcionka się załaduje dopiero kilka sekund po wyświetleniu strony to użytkownik zobaczy jedynie "przeskok" czcionek. Myślę, że jednorazowo jest to dopuszczalne.
Komentarz użytkownika szym0n
20 05 2010Jak już pisałem nie raz zdarzyło mi się,
że ładowanie JS z serwera Google zawieszało cały serwis.
no to trzeba było zrobić tak żeby nie zawieszało XD
Btw1, imo z tymi fontami to będzie COŚ jeśli dodadzą stixy -- http://www.stixfonts.org/
Btw2, skoro to takie mało ważne to nie trzeba się było tak rozpisywać ;)
Komentarz użytkownika BTM
20 05 2010@szym0n: uwaga nie do mnie, bo nie ja byłem autorem serwisów, na których zawieszało ;-)
A co do btw2 - się rozpisałem, prawda, ale dużą część zajęło wyjaśnienie o co chodzi, a potem dlaczego nie ważne :P
Komentarz użytkownika Kamil
20 05 2010BTM, nie mówię o korzystaniu z Google AJAX API, lecz o bezpośrednim odwoływaniu się do plików ;) Przykładowo: http://ajax.googleapis.com/ajax/libs/jquery/1.4.1/jquery.min.js
Raczej nie zaobserwowałem tego typu zawieszeń strony spowodowanym "Oczekiwanie na google.com".
12
Komentarz użytkownika trójkąt
20 05 2010I o ile jest to rozwiązanie korzystne na pierwszy rzut oka, o tyle nie jest ono w żaden sposób rewolucyjne [...]
Nie sprawi to, że magicznie nowe czcionki pojawią się w IE6 - po prostu jest to rozwiązanie CSS3 wykorzystujące CDN.
Zgadzam się, że nie rewolucyjne ale chyba jednak nie zrozumiałeś na czym polega cały myk.
The Google Font API is compatible with the following browsers:
- Google Chrome: version 4.249.4+
- Mozilla Firefox: version: 3.5+
- Apple Safari: version 3.1+
- Microsoft Internet Explorer: version 6+ !!
Poza tym dopiero ostatnio ustalono jaki będzie format czcionek w CSS3 dla font-face. Nie będzie to OpenType (OTF), który to format podałeś w przykładzie, ale Mozillowy Web Open Font Format (WOFF). I właśnie do czasu ustabilizowania się całej sytuacji z CSS3 (a pewnie i później) Google przecina czcionkowy węzeł gordyjski i daje webdeveloperom przyjazne i maksymalnie proste narzędzie, które zadziała prawie wszędzie (prawie, bo Opery nie widzę na spisie).
Komentarz użytkownika BTM
20 05 2010@trójkąt: fakt, zdaje się działać pod IE6 jednak (przynajmniej u mnie) na zasadzie "raz jest, raz nie ma" i potrafi wywalić IETester-a.
Komentarz użytkownika BTM
20 05 2010I właśnie sam podsunąłeś dodatkowy powód przemawiający "za" - jeżeli nagle okaże się, że rezygnujemy z WOFF tylko jakiś kolejny, nowy, lepszy format - wystarczy, że Google zmieni zapisy na swoich serwerach i już wszędzie mamy nowy standard.
15
Komentarz użytkownika trójkąt
20 05 2010I właśnie o to chodzi w tej "mini rewolucji". Teraz to oni się martwią żeby to działało wszędzie a nam zostaje czysty, smukły, śliczny i zgrabny CSS ;-)
Komentarz użytkownika BTM
20 05 2010Dodałem aktualizację nt. rozwiązania dla IE6, dzięki trójkąt :-)
