Tworzenie stron internetowych to nie tylko stosowanie się do zasad semantyki, pisanie kodu, stylizowanie plików czy tworzenie treści zachęcających do dalszego odwiedzania strony. Nawet jeśli zdobędziesz umiejętności potrzebne do budowy stron internetowych, prędko się przekonasz, że nie jest łatwo utrzymać je na odpowiednio wysokim poziomie. Powód jest prosty: wraz z upływem czasu wprowadza się nowe standardy, rynek się powiększa, każdy stara się poszerzać swoje możliwości. Nawet jeśli starannie przygotujesz się do napisania strony, po jakimś czasie okaże się, że to, czego się nauczyłeś, stopniowo się dezaktualizuje. Mimo że dysponujemy łączami internetowymi o coraz większej przepustowości, wiele stron ładuje się dłuższą chwilę, co wywołuje zniecierpliwienie użytkownika. Dzieje się tak z powodu złego przygotowania materiałów wykorzystywanych do tworzenia stron. Trzeba też mieć na uwadze to, że strony są obecnie coraz częściej odwiedzane przy użyciu urządzeń mobilnych, które rządzą się nieco innymi prawami. Użytkownikowi, który nie korzysta z połączenia Wi-Fi, zależy na tym, aby strona nie wymagała do działania obszernych plików, a jej przeglądanie było możliwe po jak najkrótszym czasie ładowania. Tymczasem często zdarzają się strony, które nawet przy wykorzystaniu połączenia Wi-Fi powodują problemy z ładowaniem plików w urządzeniach mobilnych. Wszystko to jest winą pośpiechu deweloperów. Owszem, strona powinna wyglądać ładnie, ale nie kosztem szybkości ładowania strony! Dlatego też napisałem ten rozdział: chciałbym, abyś jeszcze przed utworzeniem strony uświadomił sobie, jak duży wpływ mają pliki na tempo jej załadowania do przeglądarki. Nie należy też ładować całego zdjęcia o rozdzielczości 4K, jeśli potrzebujemy tylko jego małego fragmentu.  

Optymalizacja grafiki

  Zacznijmy zatem od przygotowania zdjęć. Ciekawiej będzie, jeśli będziemy pracować na zdjęciach, które wykorzystamy do utworzenia naszej witryny. Uznajmy też, że pliki, które zaraz zmodyfikujemy, posłużą nam do zbudowania strony WWW (rysunek 5.1).   Rysunek 5.1. Zdjęcie pierwsze   Jak widzimy, rozmiar zdjęcia powitalnego naszej witryny w swojej wyjściowej formie przekracza dwa megabajty. Często taki rozmiar mają fajne strony internetowe, które nie zawierają wielu grafik. Aby zoptymalizować zdjęcie, możemy posłużyć się dwiema metodami. Przeanalizujemy obie, głównie ze względu na to, że często narzędzia dostępne w internecie mogą znacznie pogorszyć (a nie obniżyć) jakość grafik, ponieważ już przy ich ładowaniu (a następnie pobieraniu) tracą na jakości. Co więcej, niektóre narzędzia online mogą nakładać na zdjęcia własne znaki wodne, a tego byśmy nie chcieli. Warto mieć także na uwadze, że efektu zmniejszenia rozmiaru pliku nie otrzymamy przy formacie png, gdyż jest to format zapewniający bezstratną kompresję obrazu. Podsumowując, można powiedzieć, że pliki ze zdjęciami możemy zoptymalizować poprzez:

  • użycie programu GIMP,
  • wykorzystanie narzędzi dostępnych online.

  Optymalizacja obrazów za pomocą programu GIMP Zacznijmy od optymalizacji obrazów za pomocą programu GIMP. Sposób ten jest szybszy, a przy okazji poznasz jedną z ciekawszych funkcji GIMP-a. Aby zoptymalizować zdjęcie, należy je po prostu otworzyć, a następnie wyeksportować (polecenie Plik/Wyeksportuj jako) i zapisać pod nową nazwą. Program wyświetli okno pokazane na rysunku 5.2.   Rysunek 5.2. Jakość jest atrybutem, który nas szczególnie interesuje   Dzięki zmianie wartości parametru Jakość jesteśmy w stanie znacząco obniżyć rozmiar pliku zdjęcia bez widocznej zmiany jakości obrazu. Liczba podana na rysunku 5.2 często okazuje się dobrym kompromisem, pozwalającym na zmniejszenie wielkości pliku bez znaczącej utraty jakości grafiki. Aby uświadomić sobie, jak bardzo można wpływać na rozmiary pliku, spójrz na rysunek 5.3.   Rysunek 5.3. Rozmiar zdjęcia rzeczywiście się zmienił   Co możemy zatem z tego wywnioskować? Kosztem znikomej utraty jakości zdjęcia uzyskaliśmy przeszło sześciokrotne zmniejszenie się rozmiaru pliku! To bardzo dużo, jeżeli weźmiemy pod uwagę przepustowość łączy. Zoptymalizowaną grafikę zapisałem w nowym pliku, aby umożliwić Ci porównanie wielkości plików po przeprowadzeniu kompresji. Oczywiście warto też porównać wygląd zoptymalizowanej fotografii z oryginalnym plikiem, aby się przekonać, czy zdjęcie nadal wygląda estetycznie. Jeśli będziesz niezadowolony z jakości grafiki, możesz ją usunąć i zmienić ustawienia eksportu obrazu tak, by uzyskane wyniki były satysfakcjonujące.  

Optymalizacja obrazów za pomocą narzędzi online

  Istnieją także sposoby na zredukowanie rozmiarów pliku zdjęcia za pomocą narzędzi dostępnych online. Jednym z nich jest JPEG Optimizer, dostępny na stronie http://jpeg-optimizer.com/ (rysunek 5.4).   Rysunek 5.4. JPEG Optimizer — najpotrzebniejsze opcje w zasięgu ręki   Pozwala on na zmianę jakości zdjęcia poprzez wybór poziomu kompresji (właściwie takie samo działanie ma GIMP) oraz ewentualne zmniejszenie rozmiaru grafiki. Zastosujmy dla naszego zdjęcia powitalnego ten sam schemat optymalizacji co w przypadku programu GIMP. Czy osiągniemy lepszy rezultat w porównaniu do tego, który można uzyskać, korzystając z programu?   Rysunek 5.5. Uzyskujemy coraz lepsze efekty   A zatem działający online JPEG Optimizer dał nam jeszcze lepsze wyniki. Narzędzie to ma jednak swoje wady. Jedną, i z pewnością najważniejszą, z nich jest czas oczekiwania na rezultat jego pracy — w przypadku dużych zdjęć (i dużej ich liczby) uzyskanie zoptymalizowanych plików trwa dość długo. Kolejną wadą jest konieczność posiadania dostępu do internetu. Możliwie duża szybkość łącza będzie tu bardzo cenna ze względu na wielkość plików przed kompresją. GIMP jest zatem lepszym rozwiązaniem z uwagi na szybkość pracy i niezależność od dostępu internetu, ale stopień redukcji rozmiaru pliku jest większy w przypadku optymalizatora dostępnego online. GIMP natomiast pozwala na nieco dokładniejszą edycję obrazu, co jest jego ogromnym plusem. Warto też pamiętać, że pewne możliwości związane z modyfikacją plików graficznych są obecnie zapewniane przez CSS. Mimo to podczas pisania strony warto nie tylko uwzględnić oryginalny plik, ale także przygotować odpowiednio zoptymalizowany obraz. Dzięki temu opracowana strona będzie w większym stopniu kompatybilna ze starszymi przeglądarkami.  

Kompatybilność z różnymi przeglądarkami

  Skąd jednak mamy wiedzieć, czy w ogóle istnieje taka potrzeba? Trudno określić, w którym dokładnie momencie upowszechnia się obsługa danego elementu (jeżeli tej obsługi brakuje, rezultat jest widoczny). Szukanie informacji o tym, czy określony element CSS jest obecnie obsługiwany w danej przeglądarce, może być bardzo monotonne i męczące, dlatego też z pomocą przychodzi portal caniuse.com, w którym znajduje się zbiór aktualnie obsługiwanych znaczników języka HTML oraz tych stylizujących w CSS. Portal jest bardzo intuicyjny i objaśnianie sposobu jego działania jest zbędne. Sprawdźmy po prostu od razu, czy interesujące nas znaczniki są obsługiwane przez większość użytkowanych przeglądarek (rysunek 5.6).   Rysunek 5.6. Strona caniuse w akcji   Jak można zauważyć, w przypadku większości przeglądarek nie ma żadnego problemu, choć należy spełnić pewne wymagania. Wersje przeglądarek, które oznakowano żółtym prostokącikiem (rysunek 5.6), wymagają tego, aby w celu wykorzystania efektów CSS w kodzie znalazły się odpowiednie przedrostki (fachowo zwane prefiksami). W zależności od silnika przeglądarki tymi prefiksami są:

  • -webkit-nazwa — dla przeglądarek takich jak Chrome i Opera;
  • -moz-nazwa — dla przeglądarki Mozilla Firefox;
  • -ms-nazwa — dla przeglądarek Internet Explorer oraz Microsoft Edge.

  Istnieje jeszcze jeden prefiks (-o), ale ze względu na praktyczny brak udziału w rynku starszych wersji przeglądarki Opera raczej się go nie spotyka. Jeżeli prześledziłeś uważnie obsługę wybranych znaczników przez poszczególne przeglądarki, powinieneś przemyśleć zasadność utworzenia wersji plików przeznaczonych dla starszych rodzajów oprogramowania. W omawianym przypadku CSS Filter Effects należałoby zapewnić kopię obrazu z naniesionym trwale efektem. Z drugiej jednakże strony należy się zastanowić, czy ma sens tworzenie odrębnych wersji plików wyłącznie dla dwóch przeglądarek. Moim zdaniem lepiej pójść z duchem czasu — Internet Explorer wkrótce odejdzie w zapomnienie (zastąpi go MS Edge), a Opera Mini praktycznie już nie jest w użyciu.  

Badanie optymalizacji strony za pomocą narzędzi deweloperskich

  Skoro zadecydowaliśmy, że edycję obrazka wykonamy w CSS, skupmy się na szybkości jego pobierania. Aby móc porównywać szybkość ładowania się elementów i przekonać się, czy w rzeczywistości warto kompresować obrazy, wykorzystamy bardzo powszechne wśród projektantów stron narzędzia zwane, nomen omen, deweloperskimi. Aby je uruchomić, otwórz przeglądarkę i użyj klawisza F12 (rysunek 5.7).   Rysunek 5.7. Każda z zakładek służy do wykonywania oddzielnych zadań   Szybkość pobierania elementów Zanim zwięźle omówię możliwości narzędzi deweloperskich, spróbujmy przekonać się, w jakim czasie nastąpi załadowanie grafiki niezoptymalizowanej, a w jakim tej, którą poddaliśmy tej operacji. Aby wyświetlić wykres prezentujący szybkość pobierania poszczególnych elementów, wybierz zakładkę Network (rysunek 5.8).   Rysunek 5.8. Zakładka Network — przeglądarka Google Chrome   Jak łatwo zauważyć, pobieranie pliku main-bg.jpg trwa o wiele dłużej: plik zoptymalizowany ładował się 11 sekund, a plik oryginalny — prawie 36 sekund! Warto mieć na uwadze to, że zaznaczono tu opcję Disable cache, czyli ładowanie strony wygląda tak, jakby strona była odwiedzana po raz pierwszy. Wspomnę też o tym, że pierwsze odwiedzenie strony będzie się z pewnością łączyło z dłuższym czasem oczekiwania na jej załadowanie, ponieważ przeglądarka nie zachowała żadnych plików w pamięci podręcznej. Co więcej, w trzecim wierszu widać, że na wykresie są pokazane wyłącznie obrazy, dzięki czemu łatwiej jest przeglądać interesujące dane.   Kody HTML oraz CSS witryny Jak wcześniej wspomniałem, warto poznać poszczególne zakładki narzędzia deweloperskiego, ponieważ stanowi ono nieocenioną pomocą podczas pisania stron WWW. Pierwszą z nich jest Elements — zakładka ta wyświetla kod strony i po zaznaczeniu danego fragmentu kodu pokazuje jego style w oddzielnym oknie (rysunek 5.9).   Rysunek 5.9. Zakładka Elements   Co więcej, można tutaj edytować kod HTML, a także dodawać nowe style, badać reakcje elementów na zachowania użytkownika (pod kodem strony znajduje się Filter — po jego prawej stronie umieszczone są przyciski, za pomocą których mamy możliwość tworzenia nowych klas i badania interakcji elementów). Ta część narzędzi deweloperskich z pewnością jest najbardziej przydatna podczas pisania stron internetowych.   Konsola JS na stronie Jeśli mamy możliwość edycji kodów HTML oraz CSS, z pewnością chcemy także zyskać dostęp do modyfikacji kodu JavaScript. Aby przeglądać kod źródłowy strony, warto wykorzystać zakładkę Console. W tym miejscu łatwiej także znaleźć błędy w kodzie oraz uzyskać ewentualnie uwagi odnośnie do strony. Możemy się np. dowiedzieć, że zabrakło ikony witryny (chodzi o tak zwany favicon). Jest to druga zakładka od lewej strony (rysunek 5.10). Narzędzie to naprawdę może ułatwić pracę, szczególnie jeśli nie będziesz miał pojęcia, dlaczego kod nie działa tak, jak powinien.   Rysunek 5.10. Zakładka Console w działaniu   Treści na stronie Kolejną zakładką jest Network. Jest ona godna uwagi, ale skoro ją już omówiłem, przejdziemy do kolejnej. Jest to zakładka Resources, pokazująca treści, do których mają dostęp użytkownicy. Znajdziemy tam listę plików, zdjęć, skryptów — wszystkiego, co można spotkać na stronie. Dzięki temu możemy się dowiedzieć, czy osoba, która napisała stronę, zastosowała przezroczystość, czy może po prostu odpowiednio ułożyła grafiki, co dało wrażenie przezroczystości. Poza tym możemy otrzymać sporo cennych informacji o plikach cookies, które poszczególne witryny zapisują w komputerach użytkowników (rysunek 5.11). W ten sposób możemy się przekonać, co te pliki zawierają.   Rysunek 5.11. Pliki cookies ze strony helion.pl   Testy optymalizujące stronę Kolejną zakładką jest Audits. Są tu dostępne testy, dzięki którym można poprawić swoją stronę, tak aby działała szybciej. Warto pamiętać o tym narzędziu — już dzięki samej przeglądarce możemy zyskać wskazówki dotyczące możliwości optymalizacji strony (rysunek 5.12).   Rysunek 5.12. Dzięki tej zakładce możemy zoptymalizować działanie swojej strony   Po kliknięciu przycisku Run otrzymamy wynik, który jest widoczny po kliknięciu ikony widocznej pod słowem Results (rysunek 5.13).   Rysunek 5.13. Efekt po kliknięciu „Run” — przetestowałem stronę helion.pl   Dzięki takiemu testowi dowiemy się, co można poprawić na danej stronie. Należy jednak mieć na uwadze to, że nie zawsze można zoptymalizować witrynę dla każdej dostępnej przeglądarki. Innymi słowy, warto eliminować błędy, ale bardzo trudno jest uzyskać stronę bezbłędną. Tak oto dotarliśmy do końca prezentacji narzędzi deweloperskich dostępnych w przeglądarce. Podkreślam, że przedstawiony tu opis jest bardzo skrótowy — nie wymieniłem jeszcze wielu zalet i możliwości tych narzędzi. Nawet jednak taka skromna wiedza umożliwi Ci wykorzystanie ich na podstawowym poziomie.  

Narzędzia zewnętrzne

  YSlow Jeżeli jednak zależy Ci na nieco bardziej kompleksowych testach, powinieneś zaopatrzyć się w inne narzędzia. Jednym z nich jest dodatek do przeglądarki YSlow, którego autorem jest Yahoo!. YSlow pozwala na bardzo szczegółową ocenę strony internetowej. Dzięki rozbudowanej recenzji strony wygenerowanej przez ten dodatek można poprawić błędy, które może są niewidoczne podczas przeglądania kodu, ale utrudniają działanie strony. Aby wykonać test, należy zainstalować dodatek, a następnie wybrać w przeglądarce kartę z testowaną stroną. Po chwili zostanie wyświetlone okno z rezultatem badania (rysunek 5.14).   Rysunek 5.14. Okno rozszerzenia YSlow Jako że mówimy o poprawie wydajności strony, skupimy się głównie na tej karcie. Jak widać, możliwości sprawdzenia stopnia zoptymalizowania witryny internetowej są rzeczywiście duże. Testowana strona otrzymuje ocenę ogólną, która jest obliczana jako średnia z ocen uzyskiwanych po przeprowadzeniu testów cząstkowych. Można wybrać zestaw kryteriów, na podstawie których strona będzie oceniana. Możemy także wybrać wyłącznie jedną część oceny strony, dzięki czemu łatwiej będzie wykonywać poszczególne czynności w celu udoskonalenia witryny.   PageSpeed Insights Innym, równie ciekawym narzędziem jest produkt firmowany przez Google, czyli PageSpeed Insights (developers.google.com/speed/pagespeed/insights/). Pozwoli on na przeprowadzenie optymalizacji Twojej strony internetowej. Jest z pewnością mniej rozbudowany niż YSlow, ale dzięki temu jest łatwiejszy w obsłudze. Innymi słowy, jeżeli nie miałeś wcześniej styczności z „optymalizatorami” stron internetowych, ale chcesz zacząć korzystać z takich narzędzi, PageSpeed Insights będzie dla Ciebie odpowiednim wyborem (rysunek 5.15). Rysunek 5.15. Strona PageSpeed Insights   Po wykonaniu testu będziesz mógł nanieść poprawki na stronę. Co ciekawe, narzędzie to działa w dwóch trybach: pierwszy z nich ocenia stronę w odniesieniu do przeglądarek zainstalowanych na komputerach, a drugi — do potrzeb wyświetlaczy urządzeń mobilnych. Dzięki temu nie zapomnisz o odpowiednim dobraniu zdjęć (np. w zależności od szerokości ekranu urządzenia) i przez to uzyskasz rzeczywiście szybsze ładowanie strony internetowej. Jak jednak wcześniej wspomniałem, osiągnięcie celu nie zawsze będzie proste. Im większa strona, tym trudniej będzie uzyskać doskonały układ. Warto pamiętać także o tym, że głównym odbiorcą nie jest przeglądarka czy nawet urządzenie mobilne. Docelowym odbiorcą strony jest człowiek, osoba odwiedzająca stronę, dlatego nie starajmy się kompresować plików JPG z 25 MB do 50 kB. Jest to złe rozwiązanie przede wszystkim ze względu na pogorszenie się UX.  

Badanie strony w wersji dla urządzeń mobilnych

  Aby móc wygodnie testować stronę internetową w wersji dla urządzeń mobilnych, można wykorzystać narzędzia deweloperskie. W lewym górnym rogu, obok zakładek, znajdują się dwie ikony. Pierwsza z nich pomaga w określaniu elementów na stronie: pokazuje marginesy, ustalone odległości, wymiary bloku oraz jego właściwości. Jest to bardzo przydatne narzędzie, którego prawdopodobnie użyjemy podczas tworzenia strony. Druga ikona oferuje równie interesujące możliwości, ponieważ pozwala na przeglądanie witryny w widoku właściwym dla urządzeń mobilnych — dzięki temu bez problemu zbadamy m.in. UX oraz to, czy strona wyświetlona np. na smartfonie wygląda tak, jak oczekiwał tego projektant (rysunek 5.16).   Rysunek 5.16. Widok jak w urządzeniu mobilnym — narzędzie dostępne w Google Chrome   Możemy wybierać spośród predefiniowanych rozdzielczości lub dodawać nowe, dzięki czemu jesteśmy w stanie sprawdzić, jak elementy strony zachowują się na wyświetlaczach o różnych szerokościach. Zakładka No throttling pozwala na wybranie przepustowości łącza internetowego, co umożliwia ocenę szybkości ładowania się strony w różnych warunkach. Optymalizacja strony jest wyjątkowo ważnym etapem jej tworzenia — możemy się o tym przekonać właśnie podczas testowania. Oczywiste jest to, że strona, której pliki są mniejsze i która działa wydajniej, jest po prostu lepsza. Takie utrudnienia jak powolne uruchamianie się czy zacinanie się w trakcie przewijania bardzo skutecznie odstraszają osoby odwiedzające stronę.  

SEO — RWD a subdomena m.

  Aby pliki strony wczytywały się jeszcze szybciej, warto zastosować pliki cookies. W ten sposób w przeglądarce zostaną zapisane dane, które podczas kolejnej wizyty na stronie umożliwią jej szybsze załadowanie. Możemy też wykorzystać pamięć podręczną przeglądarki (tak zwane cache) i zapisać w niej pliki, które nie zmienią się w krótkim czasie, takie jak logo firmy. Zagadnienia związane z plikami cookies trochę się różnią w zależności od wykorzystywanego serwera. W dzisiejszych czasach ważną rzeczą jest zapewnienie bezproblemowego przeglądania strony przy użyciu urządzeń mobilnych. Istnieje na to kilka sposobów. Można np. zagwarantować optymalizację plików zarówno dla komputera, jak i urządzeń mobilnych. Innym rozwiązaniem jest utworzenie strony głównej dla komputerów osobistych oraz subdomeny (m.) dla telefonów komórkowych. Obecnie jednak to podejście jest stosowane niezwykle rzadko (chociaż np. Facebook nadal utrzymuje strony oddzielnie dla komputerów i oddzielnie dla telefonów). Istnieje ku temu kilka powodów. Jednym z nich jest to, że nie każda strona jest tak popularna jak Facebook i nie każdy może sobie pozwolić na utrzymywanie dwóch równorzędnych witryn. Jeśli przeanalizujesz przykład naszej strony utworzonej dla restauracji, pewnie dojdziesz do wniosku, że jeślibyśmy wybrali rozwiązanie z domeną m.adres-strony, osoby używające telefonu komórkowego nie mogłyby łatwo znaleźć wersji strony dla urządzeń mobilnych. Nawet jeżeli adres tej wersji znalazłby się na stronie głównej witryny, wyszukanie go na dużej stronie za pomocą urządzenia o małym wyświetlaczu byłoby dość uciążliwe. Poza tym po wpisaniu frazy w wyszukiwarce użytkownik otrzymałby dwa adresy: jeden dla urządzeń mobilnych, a drugi zwykły. Takie rozwiązanie byłoby nieoptymalne, ponieważ właściciel strony musiałby inwestować w pozycjonowanie dwóch adresów. Innym poważnym argumentem przemawiającym przeciwko stosowaniu omawianej metody jest to, że w praktyce trzeba utrzymać dwie strony. O wiele lepszym wyjściem jest wykorzystanie techniki projektowania RWD (Responsive Web Design), z którą Bootstrap jest silnie związany. Dzięki niej strony internetowe mogą otrzymać potężny zastrzyk mobilności. Użycie Bootstrapa sprawia, że praktycznie każdy może utworzyć responsywną stronę WWW. Czemu zatem Facebook utrzymuje dwie witryny (rysunek 5.17)? Nie ma w tym niczego dziwnego: ten przeogromny serwis jest codziennie odwiedzany przez setki tysięcy osób. W takiej sytuacji utrzymywanie subdomeny nie wpływa na SEO (Search Engine Optimization). Natomiast dla małej firmy, która chce mieć elegancką wizytówkę w sieci, lepszym wyborem jest utworzenie i utrzymywanie strony responsywnej.   Rysunek 5.17. Strona mobilna serwisu Facebook  

Ładowanie się plików

Bootstrap jest dość rozbudowanym narzędziem — to jeden z jego atutów. Z niego wyrasta jednak jeden z poważniejszych mankamentów frameworka: sam w sobie jest on ogromnym plikiem, który — jak na kaskadowy arkusz stylów — z pewnością ładuje się zbyt długo. Dlatego też warto się zastanowić, jak można uniknąć tych niedogodności. Rozważymy trzy możliwości:

  • modyfikację zestawu startowego Bootstrapa;
  • ładowanie plików z zewnętrznego serwera;
  • kompresję kodów CSS i JavaScript.

  Modyfikacja gotowych stylów Bootstrapa Zacznijmy od pierwszej metody: edycji wyjściowego zestawu stylów Bootstrapa. Najpierw zajrzymy do plików, aby ocenić, co można z nich usunąć. [sourcecode language="css"] .glyphicon { position: relative; top: 1px; display: inline-block; font-family: 'Glyphicons Halflings'; font-style: normal; font-weight: normal; line-height: 1; -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; } [/sourcecode] Przeanalizujmy powyższy fragment. Zastanów się, co możemy usunąć z tej klasy, aby Bootstrap działał wydajniej. Może pierwszy atrybut? Albo ostatni? Przypomnij sobie, że podczas planowania strony postanowiliśmy wykorzystać Font Awesome, a więc gotowe ikony glyphicon nie będą potrzebne. Logicznie rzecz biorąc, możemy po prostu usunąć wszystkie klasy dotyczące glyphicon. W tym celu trzeba jednak przeszukać prawie 7000 linii kodu CSS. Oczywiście za pomocą edytora kodu, takiego jak Atom, jesteśmy w stanie wykonać tę operację w miarę szybko. Mimo to nadal samodzielna edycja kodu nie jest optymalnym rozwiązaniem i zajmuje dużo czasu. Czy zatem jesteśmy skazani na stosowanie pliku Bootstrapa w jego pełnych rozmiarach? Naturalnie wszystko zależy od konkretnej sytuacji. W przypadku naszej strony okazuje się, że nie musimy. Bootstrap został napisany tak, aby bez problemu mógł działać bez określonej części kodu. Rzecz jasna nie zmienimy zasadniczych elementów, takich jak liczba kolumn, ale możemy usunąć elementy zbędne. Projekt strony restauracji jest dosyć rozbudowany, ale plik CSS Bootstrapa wciąż zawiera zbędne części kodu stylów. Jeśli framework nie zostanie skonfigurowany prawidłowo, to te zbędne, niewykorzystane części kodu zostaną i będą niepotrzebnie obciążać stronę. Często wystarczy pobrać z paczki Bootstrapa system siatki (grid) i nawigacji, a resztę zakodować samodzielnie, co jest dość prostym zadaniem. Dzięki takiej metodzie pracy uzyskamy rzeczywiście mniejsze pliki. Istnieją jednak istotne argumenty przeciwko takiemu działaniu, np. taki, że strona powinna być skalowalna, a zmniejszanie możliwości Bootstrapa jest prostą drogą do utraty tej cechy. Tyle że nie może być mowy o bezpowrotnej utracie funkcjonalności, gdyż w każdej chwili można pobrać każdą wersję Bootstrapa z wielu źródeł. To niewątpliwa zaleta tego imponującego frameworka. Innymi słowy, wciąż pozostaje nam jedno pytanie: jak zmniejszyć wielkość ładowanych do przeglądarki plików Bootstrapa? Okazuje się, że twórcy tego frameworka zapewnili nam gotowe narzędzie służące do wykonania tego zadania. Jeśli jednak nie lubisz gotowych narzędzi, możesz utworzyć sobie kilka uniwersalnych zestawów kodu CSS Bootstrapa samodzielnie, a następnie używać ich w razie potrzeby. Aby bezproblemowo dopasować Bootstrapa do konkretnego zastosowania, należy otworzyć stronę http://getbootstrap.com/customize/ i odpowiednio skonfigurować plik (rysunek 5.18).   Rysunek 5.18. Podstrona „Customize” na getbootstrap.com   Jak widać, znajomość preprocesora LESS może okazać się przydatna, zwłaszcza jeśli trzeba edytować takie cechy jak kolory okien, rodzaje czcionki itp. Warto też skorzystać ze wspominanych wcześniej stron udostępniających gotowe projekty, szczególnie jeśli masz ochotę na pracę z wyjściowym plikiem Bootstrapa, ale z ciekawszą kolorystyką. Wróćmy jednak do udostępnionej nam możliwości dostosowania pliku Bootstrapa i zastanówmy się, które elementy są zbędne w naszym projekcie. Z pewnością nie będziemy potrzebowali Glyphicons. Aby jednak zachować porządek, przemyślimy dobrze każdą z możliwych kategorii. Na początek Common CSS: które elementy są zbędne? Łatwo dojść do wniosku, że w projekcie nie wykorzystamy znacznika do ostylowania kodu tabel, nie zaplanowaliśmy też przycisków. Te elementy byłyby niepotrzebnym balastem. Z elementów wymienionych w Components możemy zrezygnować z Glyphicons. Nie potrzebujemy także Input groups (pozwalających na uzyskanie pól do wprowadzania danych). Aby nie przedłużać, od razu napiszę, że z grupy Components zostawimy tylko Navs (do utworzenia zakładek), Navbar (do zaprogramowania nawigacji strony), Media Items (do publikacji opinii klientów), Responsive Embed (w razie gdyby pan Oskar zechciał opublikować klip wideo) oraz Close Icon. Innymi słowy, z dwudziestu elementów pozostawiliśmy tylko pięć! To pokazuje, jak rozbudowanym narzędziem jest Bootstrap. Nasz projekt wykorzystuje jego możliwości w bardzo dużym stopniu, a przecież wiele elementów jest w nim zbędnych. Jak natomiast postąpić z sekcją JavaScript Compoments? W tym przypadku trzeba pamiętać, że będziemy korzystać z galerii Bootstrapa. Z tego względu lepiej zachować wszystkie elementy, aby później uniknąć problemów z jej działaniem. Ponadto warto wspomnieć, że galeria działa w sposób zoptymalizowany. Wyświetla miniatury zdjęć (w naszym projekcie 275 px na 275 px), a obrazek w pełnych rozmiarach jest pokazywany dopiero po kliknięciu łącza. Innymi słowy, zdjęcie jest pobierane z serwera dopiero po kliknięciu miniatury, co pozwala na szybsze ładowanie się strony. Poza tym plik skryptów nie jest na tyle obszerny, aby potrzebna była dodatkowa konfiguracja. Naturalnie może się zdarzyć, że skonfigurowany zestaw nie będzie działać poprawnie. W takich sytuacjach można po prostu wypróbować inną kombinację elementów. Gdy nabierzesz wprawy, zobaczysz, że taka konfiguracja nie jest problemem. Na tym etapie możemy się przekonać, że usunęliśmy sporo elementów z wyjściowego pliku Bootstrapa. Warto sprawdzić efekty tych działań i porównać wielkość zmodyfikowanego pliku z wielkością pełnej wersji pliku CSS. Aby pobrać wybraną konfigurację, należy przejść do samego dołu strony, a tam kliknąć przycisk Download (rysunek 5.19).   Rysunek 5.19. Pobieranie skonfigurowanej paczki Bootstrapa   W pobranym pliku znajdziesz foldery z zawartością oraz informację o konfiguracji w pliku o rozszerzeniu .json, dzięki czemu nie będzie trzeba wykonywać całej operacji po raz kolejny. Możemy więc sprawdzić rozmiary plików, aby przekonać się, jakie uzyskaliśmy różnice. Na rysunku 5.20 przedstawione są pliki po modyfikacjach.   Rysunek 5.20. Pliki po konfiguracji   Natomiast na rysunku 5.21 zaprezentowane są pliki pobrane bezpośrednio z witryny Bootstrapa, bez żadnych konfiguracji.   Rysunek 5.21. Pliki bez konfiguracji   Jak widać, pliki po optymalizacji dwukrotnie zmniejszyły rozmiar, co jest całkiem dobrym wynikiem. Mimo że zyskaliśmy jedynie kilkadziesiąt kilobajtów, nie zmienia to faktu, że przy dobrych chęciach możemy zmniejszyć rozmiar plików CSS. W powyższym porównaniu nie uwzględniłem plików związanych ze skryptami, ponieważ ich nie modyfikowaliśmy. Jak już wspomniałem, planujemy wykonać galerię zdjęć, w której pliki te mogą zostać wykorzystane. Niepoprawna konfiguracja tych plików mogłaby doprowadzić do powstania problemów z działaniem galerii. Być może zastanawiasz się, dlaczego bierzemy pod uwagę tylko dwa z czterech plików. Odpowiedź jest prosta: tylko te dwa pliki są powiązane z plikami HTML. Przyjrzyj się jeszcze ich rozmiarom — z pewnością zauważysz, że plik o nazwie zawierającej ciąg znaków .min jest mniejszy od swojego odpowiednika. Skąd się wzięła ta różnica? Plik o mniejszych rozmiarach został przetworzony w procesie minifikacji, który polega na usunięciu zbędnych elementów i pozwala na zmniejszenie ilości kodu. Nie są to duże różnice, ale dzięki nim przeglądarka szybciej wczytuje pliki. Tego rodzaju modyfikację można wykonać również własnoręcznie.   [sourcecode language="css"] .mouse{ backgroud-color: #EEEEEE; font-size: 14px; font-family: 'Courier New'; letter-spacing: 2px; } .glass{ width: 250px; height: 60px; letter-spacing: 2px; border: 2px solid #BACAEE; box-sizing: border-box; } .mouse, .glass{ letter-spacing:2px } .mouse{ background:#eee; font-size:14px; font-family:'Courier New'; letter-spacing:2px; } .glass{ width:250px; height:60px; letter-spacing:2px; border:2px solid #bacaee; } [/sourcecode]   Ręczne zminifikowanie takiego niedużego fragmentu kodu CSS nie stanowi problemu. Powyżej zamieściłem dwie wersje tego samego kodu: w postaci wyjściowej i w formie skompresowanej. Obydwie wersje są jednakowo czytelne dla przeglądarki, ale dla człowieka zrozumienie kodu przetworzonego może być trudniejsze. Jeżeli jednak dobrze się przyjrzysz temu kodowi, zauważysz, że nie został idealnie zminifkowany: jedna z wartości pojawia się dwa razy, poza tym pozostały spacje pomiędzy atrybutami. Na szczęście powstały narzędzia, które pozwalają na zautomatyzowanie tego procesu. Kod uzyskany dzięki ich użyciu jest w pełni zminifkowany.   Minifikacja plików CSS — generatory   Istnieje wiele narzędzi do minifikacji plików CSS. Ja zalecam stosowanie csscompressor.com (rysunek 5.22). Jest to narzędzie o dużych możliwościach w zakresie modyfikacji kodu. Jest ono w znacznym stopniu konfigurowalne. Przykładowo może usuwać średniki po ostatniej wartości w edytowanej klasie lub w ramach innego modyfikowanego elementu (wspomnę tylko, że średnik przed klamrą zamykającą jest zbędny), może też zmieniać wartości pisane tekstem na liczbowe (np. z font-weight:bold; na font-weight:700;).   Rysunek 5.22. Strona csscompressor.com   Pokazany wcześniej blok kodu CSS po minifikacji za pomocą strony csscompressor.com wygląda następująco:   [sourcecode language="css"] .mouse{ backgroud-color:#EEE; font-size:14px; font-family:'Courier New'; letter-spacing:2px } .glass{ width:250px; height:60px; letter-spacing:2px; border:2px solid #BACAEE; box-sizing:border-box } [/sourcecode] Kod został pomniejszony o 20%. Mimo to nadal nie jest idealnie skompresowany. Trzeba jeszcze połączyć obie klasy i zastosować właściwość letter-spacing. Jeżeli wykorzystamy wszystkie możliwości, wartość kompresji wzrośnie do 25%. Zapamiętaj również, że należy zachować oryginalną, nieskompresowaną wersję pliku. Dzięki temu w razie potrzeby łatwiej będzie przeglądać i edytować kod CSS. Co prawda narzędzia do minifikacji plików pozwalają również na ich dekompresję, jednak kod uzyskany w wyniku tego procesu może okazać się znacznie mniej czytelny od oryginalnego. Podobnie zresztą jest z plikami Bootstrapa — równie dobrze działałyby bez nieskompresowanej wersji pliku, ale minifikacja oryginalnego pliku jest łatwiejsza niż tego w pełni skompresowanego.   Content Delivery Network (CDN)   Po omówieniu metod polegających na modyfikacji wyjściowego pliku Bootstrapa i minifikacji plików CSS należałoby opisać jeszcze jedną: jest to pobieranie plików CSS i JS z serwera zewnętrznego, czyli wykorzystanie CDN. O tej technice, która ma tyle samo zwolenników co przeciwników, wspominałem już wcześniej w tej książce. Czym więc jest CDN? CDN (akronim od angielskiego wyrażenia Content Delivery Network) jest zbiorem wielu treści. W naszym przypadku są to pliki CSS oraz JavaScript. Dzięki CDN nie trzeba pobierać treści na komputer, a dostęp do nich uzyskujemy poprzez łącza. Dotyczy to zarówno tworzenia strony, jak i jej przeglądania. Wykorzystanie takich gotowych rozwiązań sprawia, że można się skupić wyłącznie na tworzeniu strony. Nie jest to jednak idealna metoda, gdyż CDN z reguły nie oferuje modyfikowalnych stylów CSS, a zatem pozbawienie plików zbędnych elementów będzie najczęściej niemożliwe. Ale CDN ma też swoje zalety: osoba, która odwiedza stronę zbudowaną przy jego użyciu, mogła już wcześniej przeglądać witrynę korzystającą z tych samych plików. W takich przypadkach mogą być one, dzięki pamięci podręcznej i plikom cookies, o wiele szybciej ładowane do przeglądarki. Portali oferujących łącza do zasobów jest bardzo dużo. Należą do nich np. narzędzia Google, maxCDN i Microsoft (rysunek 5.23). Czy jednak rzeczywiście ich potrzebujemy?   Rysunek 5.23. Strona getbootstrap.com daje możliwość korzystania z Bootstrapa poprzez CDN   Niekiedy sposób pracy uniemożliwia efektywne używanie CDN. Jeżeli często zdarza Ci się pisać stronę WWW w różnych miejscach, np. w autobusie podczas dojazdu do pracy czy w miejscach bez dostępu do internetu, stosowanie treści z CDN może być problematyczne. Jeśli nie zapewnisz sobie plików dostępnych lokalnie, tworzenie projektów będzie utrudnione. Co więcej, nie można wykluczyć tego, że przynajmniej niektóre zasoby udostępniane na serwerach CDN będą stopniowo wymieniane na nowsze. To wszystko sprawia, że warto zapewnić sobie lokalną kopię wykorzystywanych plików — mimo że w internecie istnieje kilkadziesiąt wersji narzędzia, nie zawsze mamy do nich dostęp. Wspomniałem wcześniej, że stosowanie CDN umożliwia szybsze wczytywanie strony internetowej, ale nie jest to jego jedyna zaleta. Inną jest bowiem korzystny wpływ na SEO, czyli pozycjonowanie strony WWW. Taka witryna będzie miała duże szanse na większą popularność, o ile tylko zostanie wybrany odpowiedni serwer CDN. Warto pamiętać, że istnieje także możliwość korzystania z płatnych portali CDN, jednak nie zawsze to rozwiązanie jest warte uwagi. Z wyborem serwera CDN są związane dwie ważne kwestie. Po pierwsze, chodzi o samą firmę dostarczającą treści, a po drugie — o lokalizację serwera przechowującego dane. Trzeba pamiętać, że duże firmy utrzymują kilkanaście, a nawet kilkadziesiąt serwerów. Z użytkownikiem łączy się ten, który jest zlokalizowany najbliżej. Jeżeli pliki strony będą przetrzymywane na jednym serwerze, a potrzebne treści na oddalonym serwerze CDN, czas uzyskiwania połączenia może okazać się nieco dłuższy. Istnieje wiele firm oferujących usługi CDN:

  • Twórcy Bootstrapa proponują maxCDN.
  • Google co prawda nie oferuje Bootstrapa, ale udostępnia jQuery, niezbędne do jego działania.
  • Microsoft udostępnia własne zasoby umożliwiające korzystanie z Bootstrapa.
  • CDNJS także pozwala na wykorzystanie łączy do swoich zasobów.

Miej na uwadze to, że plik Bootstrapa nie jest jedynym elementem strony, który można udostępniać poprzez CDN. W taki sposób można zaprojektować wiele części witryny. Galeria, którą mamy zamiar wykonać, także wymaga własnych zasobów. Aby nie przechowywać ich na swoim serwerze, można pobrać galerię bezpośrednio z GitHuba. Nie wiesz, jak to zrobić? Istnieją dwa sposoby. Pierwszy z nich polega na wykorzystaniu narzędzi deweloperskich, drugi natomiast wymaga podstawowej znajomości struktury GitHuba. Aby poćwiczyć wcześniej zdobyte umiejętności, zastosujmy pierwszą metodę. Najpierw należy uruchomić stronę galerii i otworzyć okno narzędzi deweloperskich (rysunek 5.24). Rysunek 5.24. Kod źródłowy strony z galerią Jak widać, strona ta korzysta z zasobów CDN. Aby uzyskać łącze do plików galerii, należy kliknąć prawym przyciskiem myszy odnośnik do wybranego skryptu, a następnie z menu kontekstowego wybrać opcję Open link in new tab (co oznacza Otwórz w nowej zakładce). W taki sposób (rysunek 5.25) będziemy mogli przejrzeć zawartość pliku, aby się upewnić, jakie treści zawiera. Następnie można skopiować łącze i zastosować je we własnym projekcie w takiej formie, jaką było widać na podglądzie kodu źródłowego w narzędziach deweloperskich.   Rysunek 5.25. Część menu kontekstowego po kliknięciu PPM na fragment kodu strony   Aby dokończyć temat CDN, warto porównać szybkość ładowania w przeglądarce zasobów pochodzących z poszczególnych serwerów CDN i z lokalnego pliku. W tym celu znów użyjemy narzędzi deweloperskich. Porównamy cztery źródła treści i aby zapewnić porównywalność wyników, nie będziemy używać cookies — w ten sposób unikniemy wykorzystywania pamięci podręcznej przeglądarki. Porównamy szybkość pobierania pliku zapisanego na serwerze, pliku z MaxCDN, pliku na serwerze CDN Microsoftu oraz dokumentu Bootstrapa dostępnego na GitHubie. Aby nie faworyzować żadnego CDN, plik jQuery zostanie załadowany ze strony producenta. Należy wspomnieć, że każdy z porównywanych plików będzie pełną wersją naszego narzędzia (rysunek 5.26).   Rysunek 5.26. Porównanie szybkości pobierania pliku z różnych serwerów   Jak widać, najszybciej został pobrany plik CSS pochodzący z dokumentacji Bootstrapa na GitHubie. Nieco dłużej trwało pobranie pliku zapisanego lokalnie, a trzecie miejsce zajmuje plik pochodzący z serwera CDN Microsoftu. Najdłużej trwało pobieranie pliku z serwera polecanego przez twórców Bootstrapa. Jego ładowanie trwało prawie sekundę, co w obecnych czasach jest bardzo słabym wynikiem. Takie rozbieżności występują jednak tylko podczas pierwszego ładowania plików — kolejne pobierania zajmą zbliżoną ilość czasu. Spróbuj samodzielnie sprawdzić, jak szybko ładowane będą zmodyfikowane pliki CSS. Wydaje się, że czas pobierania skompresowanego dokumentu będzie najkrótszy. Dlatego też będziemy korzystać ze zminifikowanych plików CSS Bootstrapa. Skrypty JS również zapiszemy lokalnie, aby uniknąć problemów w razie awarii serwera CDN lub niepoprawnego wpisania łączy do skryptów. Mimo wszystko zachęcam Cię, abyś w kolejnych projektach rozważył zastosowanie Bootstrapa z wykorzystaniem CDN. Pamiętaj tylko o zachowaniu własnych plików z danymi. Będziesz mógł z nich skorzystać np. w razie awarii serwera CDN albo usunięcia danego pliku z serwera.   Kolejność ładowania się plików   Jeśli już kiedyś tworzyłeś strony albo jesteś po prostu spostrzegawczy, zauważyłeś zapewne, że odniesienia do pliku CSS są z reguły umieszczane w nagłówku strony (czyli w sekcji head). Z kolei odnośniki do skryptów wpisuje się albo również w nagłówku, albo na końcu sekcji body — czyli właściwie na końcu strony. Taki układ wpływa na wydajność działania strony. Aby przeglądarka mogła wczytać stronę, na początku musi załadować sekcję head. To logiczne: najpierw trzeba przetworzyć „głowę” strony, a następnie jej „ciało”. Oznacza to, że pliki wypisane przed znacznikiem body muszą być załadowane jako pierwsze. Tutaj mogą nasunąć Ci się pierwsze ważne wnioski, np. taki, że ładowanie plików JS wraz z wczytywaniem sekcji head jest niewskazane, ponieważ opóźnia to wyświetlanie strony internetowej, a tego należy bardzo starannie unikać. Ponieważ chcemy zadbać o UX, w naszym projekcie będziemy umieszczać odnośniki do arkuszy stylów w sekcji head, a odnośniki do skryptów — w sekcji body. Być może zastanawiasz się, czemu nie można umieścić odnośników do plików stylów na końcu sekcji body, jeśli wpisuje się tam odnośniki do plików JS. Ponownie chodzi o UX. Pliki CSS muszą się załadować jako pierwsze, ponieważ dzięki nim użytkownik dostaje gotową stronę WWW. Skrypt JS natomiast może poczekać. W końcu to pierwsze wrażenie jest najważniejsze: jeżeli strona się załaduje, a przycisk z menu nie będzie działał przez początkowe 0,3 s, nikomu to nie będzie przeszkadzało. Z kolei odbiór strony, której wygląd przez pierwszy ułamek sekundy odbiega od oczekiwań, jest już dużo gorszy. Jak to się będzie przedstawiało w praktyce?   [sourcecode language="html"] <head> <!-- rzeczy ważne i mniej ważne -> <link rel="stylesheet" href="odnosnik_do.css"> </head> <body> <!-- rzeczy ważne i mniej ważne -> <script src="adres_do_skryptu.js"></script> </body> [/sourcecode]   Przypomnę jeszcze o dwóch ważnych rzeczach, o których zresztą pisałem już wcześniej. Po pierwsze, aby skrypt Bootstrapa (wydania starsze od 3.3.7) działał prawidłowo, najpierw należy załadować jQuery w wersji 2.x, a dopiero potem plik Bootstrapa. Jeżeli używasz Bootstrapa w wydaniu 3.3.7 lub nowszym, swobodnie możesz skorzystać z jQuery 3.x. W praktyce stosuje się dwa skrypty: JS oraz jQuery. Po drugie, istotna jest liczba skryptów — jeżeli na stronie wykorzystujemy ich więcej, warto umieścić je w jednym pliku. Dzięki temu będą się szybciej ładowały.

ZADANIA

 

  • Poznaj dokładnie program GIMP — z pewnością przyda Ci się podczas realizacji innych projektów.
  • Poczytaj o gotowych zestawach HTML oraz CSS. W ten sposób możesz otrzymać szablon na wzór tego z Bootswatch.

   


Tekst pochodzi z książki "Bootstrap. Tworzenie własnych stylów graficznych" (Radosław Gryczan) - Wyd. Helion 2017.Sprawdź książkę >>Sprawdź eBook >>