Zmniejszanie rozmiaru OpenLayers

Biblioteka OpenLayers bywa często krytykowana za duży rozmiar. Istotnie, prawie 1 MB kodu JavaScript robi wrażenie – dla porównania Leaflet-js „waży“ 92 kB, a Polymaps  zaledwie 32 kB. Nie wolno jednak zapominać o tym, że różnice te nie biorą się z niczego. Liczba dostępnych funkcji oraz akceptowanych formatów danych jest dużo dłuższa właśnie w OpenLayers i często są one niezbędne do zbudowania aplikacji spełniającej wszystkie oczekiwania.

Nie znaczy to jednak, że jesteśmy skazani na ładowanie tak obszernej biblioteki za każdym razem. Poniżej opiszę kilka sposobów, które pozwalają na ograniczenie ilości pobieranych danych przy zachowaniu pełnej wymaganej funkcjonalności.

Użycie nowej wersji

Niedawno doczekaliśmy się nowego wydania biblioteki, oznaczonego numerem 2.12 (link). Oprócz dostępu do kilku usprawnień,zyskamy na tym 236 kB dzięki pozbyciu się przestarzałych klas i funkcji. Starsze aplikacje, napisane dla wydań przed numerem 2.10 mogą mieć problemy z kompatybilnością – w ustaleniu zakresu koniecznych modernizacji pomocna będzie dokumentacja: http://dev.openlayers.org/docs/files/deprecated-js.html.

Wybór gotowej, odchudzonej kompilacji

Wraz z wersją 2.12, w głównym katalogu odnajdziemy nie jeden, ale 6 różnych plików JavaScript. Wersje oznaczone .debug mają nieskompresowany kod, z pełnymi nazwami zmiennych i są przydatne w procesie tworzenia aplikacji – dają bowiem bardziej zrozumiałe komunikaty o błędach. To, co nas będzie bardziej interesować, to dwie wersje oznaczone jako .light i .mobile.

Są to odchudzone wersje OpenLayers, z zredukowanym zestawem funkcji, wystarczającym do typowych zastosowań. Wyłączono z nich między innymi większość formatów danych. Wersja „light“ umożliwia wyłącznie odczyt (bez edycji) formatu GeoJSON i wykorzystanie warstw WMS, OSM, Google i Bing Maps jako podkładów, zaznaczanie obiektów i wyświetlanie „dymków“, przełączanie warstw i stylizację danych wektorowych, których strategie ładowania ograniczono do dwóch: Fixed oraz BBOX. Natomiast w wersji „mobile“ zrezygnowano z przełączania warstw oraz strategii BBOX, ale uwzględniono Geolocation API, narzędzia edycyjne i obsługę formatu KML. Ponadto zastosowano „lekką“ wersję nawigacji mapy, dedykowaną ekranom dotykowym.

Własna kompilacja

Czasem jednak gotowe „odchudzone“ wersje nie spełnią oczekiwań. Weźmy na przykład mapę, która ma pokazywać ślad GPX oraz grupowane punkty (Strategy.Cluster), z jednym dostępnym podkładem. Albo też aplikacje mobilną, która ma pobierać dane wektorowe przez WFS, wraz z przesuwaniem mapy. Na szczęście biblioteka ma budowę modułową, z której można (i należy!) skorzystać – zbudować własną wersję. Nie jest to wprawdzie tak wygodne, jak w przypadku frameworków z rodziny jQuery, gdzie pożądane moduły wybieramy po prostu myszką na stronie pobierania, ale też niezbyt trudne.

Po rozpakowaniu OpenLayers, w katalogu o nazwie „build“ znajdują się pliki konfiguracyjne z rozszerzeniem .cfg oraz niezbędne narzędzia. Plik .cfg możemy otworzyć w dowolnym edytorze tekstu nadającym się do programowania. Najważniejsze są w nim sekcje oznaczone tagami [include] oraz [exclude]. W nich wypisane są moduły, które mają być włączone lub wyłączone z kompilacji.

Zwykle uzupełnia się tylko jedną z nich – w zależności od tego, czy chcemy zachować większość, czy mniejszość pełnej funkcjonalności. A czym należy się kierować przy budowie własnej kompilacji?

Przede wszystkim weźmy pod lupę formaty. Czy aby na pewno korzystamy z pełnej palety? Zwykle wystarczą najwyżej 2-3. Obsługa stylów przy pomocy SLD też na ogół nie jest konieczna. To samo tyczy się warstw podkładowych – bez obsługi  ArcIMS, WorldWind czy Zoomify obejdzie się znakomita większość internetowych map. Po drugie, jeśli aplikacja nie przewiduje modyfikacji danych – warto wyłączyć narzędzia edycyjne. Strategie i protokoły to kolejne miejsce do potencjalnej optymalizacji.

Na zakończenie wywołujemy z linii komend polecenie:

python build.py <nazwa pliku konfiguracyjnego>  <nazwa pliku wyjściowego>

na przykład:

python build.py custom OpenLayers.custom.js

Korzystając ze wskazówek w pliku README, możemy jeszcze zainstalować Google Closure Compiler, który pozwoli na skuteczniejsze skompresowanie kodu. Może się bowiem okazać, że po usunięciu kilku klas i kompresji domyślnym narzędziem o nazwie jsmin, rozmiar wynikowy będzie… większy od standardowego, kompresowanego właśnie Google Closure.