Dziś opisuję “od kuchni”  niektóre niuanse działania jednego z serwisów, którymi się opiekuję, tym samym odsłaniając niektóre z tajemnic.

Przygotowując nowe rozwiązanie na potrzeby Legionisci.com (czyli tak na prawdę doskonale znane kibicom – Legialive.pl), przypomnieliśmy sobie o pewnym problemie i mankamencie przeglądania dużych galerii pełnych zdjęć w wysokiej (jak na Internet) rozdzielczości.

Otóż oprócz ich przeglądania w wersji lightboxowej dajemy również opcję przeglądania wszystkich zdjęć na jednej stronie, która dla fanów fotografii i treści pokazywanych na zdjęciach może być tą najciekawszą.
W czym dokładnie tkwi ich problem? Przede wszystkim w samej ilości zdjęć i ich rozdzielczości.

Problem rozdzielczości można wytłumaczyć najłatwiej. Jakiś czas temu zdecydowaliśmy się zaszaleć i pójść zgodnie z najnowszymi trendami prezentacji reportaży, czy też galerii tematycznych – podnieśliśmy rozdzielczość prezentowanych zdjęć z 800px na dłuższym boku do 990px. Jak wiadomo, taki krok nie pozostaje bez znaczenia dla wielkości pliku i różnice potrafią być dość istotne. Na szczęście posiadane zasoby serwerowe nie ograniczały nas w tym względzie.

Jeśli do faktu rozdzielczości i większej objętości pliku dodany jeszcze czynnik ilościowy, zawsze lubiliśmy kompleksowo przedstawiać wydarzenia sportowe związane z Legią Warszawa, wówczas mamy mieszankę wybuchową. Linkowana powyżej galeria to 8,1MB danych przypadających na same (61 sztuk) zdjęcia. Nadmienię jeszcze, że niejednokrotnie zdarza nam się publikować ponad 100 obrazów w relacji pojedynczego fotoreportera. Jeśli dodamy do tego niesłychanie duże zainteresowanie fotografiami bezpośrednio po każdym meczu, wówczas piki obciążenia i ruchu potrafią zabić nawet nasze maszyny.

Duża ilość danych ładowanych do przeglądarki widza ma również inne aspekty. Z jednej strony nie każdy posiada w domu łącze 120 Mbps, a z drugiej nie każdy pracuje na wielordzeniowym potworze wyposażonym w nieskończone ilości pamięci oraz super duże i szybkie dyski. Taka galeria nie pozostaje bez wpływu na webusability i potrafi zabić na dłuższą chwilę przeglądarkę, nie dając widzowi możliwości bieżącego przeglądania pierwszych załadowanych zdjęć lub przejścia na chwilę na drugą zakładkę i przeczytania nowych newsów – w oczekiwaniu na załadowanie się galerii.

Człowiek myślący lubi wyzwania, dlatego zaczęliśmy szukać rozwiązania powyższych problemów. Pierwszym rozwiązaniem przychodzącym do głowy było spróbować dociągać obrazki asynchronicznie, wedle “zapotrzebowania” widza. Po chwili googlania udało nam się doprecyzować, że idealnym rozwiązaniem byłoby skorzystanie z patentów związanych z tzw. lazy loading.

W dużym skórcie patent lazy loading polega na doładowywaniu “treści wzbogacających” podstawową warstwę prezentacji, którą już dostarczyliśmy do widza. Taką podstawową warstwą może być strona w czystym HTMLu z wstawką CSS, a tymi “treściami wzbogacającymi” – wszystkie zabawki związane z social media, dynamiczne przeładowywania treści itp. Przykładem komunikacji asynchronicznej i wykorzystania lazy loading są wszystkie wstawki Facebooka: przyciski “Lubię to”, profil danego fan page, livestream, …. W kodzie strony znajdują się tagi w notacji FBML i odwołanie do elementarnej biblioteki JavaScript Facebooka, która następnie dynamicznie dopisuje sobie wywołanie ładowania pozostałych niezbędnych bibliotek JS (choć ostatnio Facebook skłania developerów i użytkowników do stosowania rozwiązań opartych na IFRAME, czyli “pływającej” ramki).

Idąc tym tropem trafiliśmy na bardzo fajne biblioteki rozszerzające frameworki jQuery i Prototype, których zadaniem było zatrzymanie ładowania obrazów o określonych kryteriach i doładowywanie ich dopiero w chwili, w której użytkownik zbliżał się do oglądania danej treści. Podobne rozwiązanie znalazłem choćby na stronie mashable.com i moim ulubionym “portalowym” blogu prezentującym różne tematy fotograficzne – 990px.pl. Wszystko do tego momentu jest pięknie, ale jak zwykle diabeł tkwi w szczegółach. Otóż 90% rozwiązań dostępnych w sieci ma jeden feler – zostały napisane kilkadziesiąt miesięcy temu, a przez ten czas przeglądarki ewoluowały i tamte rozwiązania działają tylko w warstwie prezentacji, natomiast pod spodem ściągają do przeglądarki komplet danych, nie rozwiązując faktycznego problemu.

Kolega Woytek co prawda znalazł jedno rozwiązanie zdające się działać poprawnie (nie mogłem dojść jak, ale udawało mu się abortować ściąganie odpowiednich obrazków), ale wykorzystywało ono framework jQuery. Problem w tym, że o ile używamy go na stronach, o tyle nie było go jeszcze w galerii z dużymi zdjęciami, w których do innego celu jest już wykorzystywany Prototype z rozszerzeniem w postaci Scriptaculous. Jeszcze jeden framework tylko dla jednej funkcjonalności, jego dociąganie, cała zabawa z rozwiązywaniem konfliktów z już istniejącym kodem – to wykluczało skorzystanie z tego rozwiązania. Woytek przy okazji podrzucił jeszcze jedno działające, choć obarczone pewnymi błędami natury funkcjonalnej i również w jQuery, ale od strony mechanizmu spełniające swoje zadanie.

Tym sposobem wziąłem na warsztat niedziałające rozszerzenie stworzone pod Prototype i przystosowałem do ulepszonego mechanizmu znalezionego przez Woytka. Dzięki temu mamy na stronie galerie, które nie zabijają przeglądarek widzów, pozwalają im cały czas nimi operować, a do tego zdjęcia wyświetlają się jak należy.

Przy okazji wynikł pomysł jeszcze jednego rozwiązania ulepszającego galerie. Jeśli ktoś zna zasady działania przeglądarek internetowych, to wie również o fakcie ograniczeń wprowadzanych przez ich projektantów i np. ograniczaniu ilości jednocześnie otwieranych połączeń służących do ściągania treści z pojedynczej domeny. Z tego względu od jakiegoś czasu minimalizujemy i łączymy biblioteki z kodem JS.
W tym miejscu wspomnę jeszcze, że testujemy właśnie rozwiązanie DNS Balancingu, które być może w niedalekiej perspektywie wzbogacimy o kolejny patent typu client side. Ma ono za zadanie rozłożyć generowany ruch pomiędzy posiadane przez nas maszyny, dzięki czemu wszystko powinno działać dużo płynniej, nawet w piku odwiedzin.

Gdybyście znaleźli rozwiązania spisujące się lepiej od naszego lub trafili na błędy w tym używanym przez nas (mogą pojawiać się problemy ze wsteczną kompatybilnością ze starymi przeglądarkami), to proszę o informację w komentarzach.

Natomiast jeśli ktoś jest zainteresowany wprowadzeniem takiego rozwiązania do własnych galerii, co polecam szczególnie wszystki budującym portfolio fotograficzne na WordPressie (zwłaszcza przedstawicielom “branży ślubnej” zalewającej widzów megabajtami zdjęć), to zapraszam do kontaktu i podesłania emaila ze szczegółami problemu do rozwiązania.