search check home clock-o tag tags chevron-left chevron-right chevron-up chevron-down twitter facebook github rss comment comments terminal code

[Joomla!] Czym jest szablon TemplateMonster Wegy dla Joomli? – recenzja szablonu

[Joomla!] Czym jest szablon TemplateMonster Wegy dla Joomli? – recenzja szablonu

Nadchodzi wielkie wydarzenie w świecie Joomla! - coroczna konferencja J and Beyond 2015, która w tym roku odbędzie się w Pradze. Dlatego chcąc pozostać w tematyce około-joomlowej postanowiłem napisać recenzję szablonu dostępnego na stronie TemplateMonster, szablonu Wegy.

W recenzji postaram się ocenić jakość wykonania szablonu, stopień domyślnej optymalizacji oraz przedstawić wskazówki co można by zrobić aby strona oparta o ten szablon działała sprawniej.

Instalacja

Szablon postanowiłem zainstalować na najnowszej wersji Joomla! - 3.4.1. Do instalacji wykorzystałem pełny zestaw demo dostarczony wraz z szablonem. Dzięki temu, nie będę musiał konfigurować od zera całego szablonu. Nie będę opisywał pełnego przebiegu instalacji systemu Joomla! ponieważ nie odbiega on od standardowej procedury instalacyjnej systemu.

Co nam oferuje szablon? Opinie na temat możliwości

53576-responsive-layout

TemplateMonster oferuje nam szablon responsywny, tj. szablon dopasowujący się do rozdzielczości ekranu. Tak jak w większości szablonów na sprzedaż, szczególny nacisk położono na efektowność szablonu. Domyślnie jest dużo zdjęć, dużo efektów JS i animacji. To wszystko ma niebagatelny wpływ na wydajność strony na urządzeniach mobilnych oraz na szybkość ładowania się strony w przeglądarce. Do ściągnięcia jest około 3MB plików, co jest bardzo dużą wartością i przeglądarka musi wykonać około 70 requestów do serwera aby pobrać wszystkie pliki za pierwszym razem i potrafi to zająć nawet ponad 5 sekund. W testach wykazanych przez przeglądarkę Firefox w systemie Windows 7 wyniki wyglądają następująco:

Szybkość ładowania szablonu TemplateMonster Wegy

Jak widać czas pobrania plików jest bliższy 2 sekundom niż 5, ale to jest jakaś nieścisłość po stronie przeglądarki (co można porównać z wykresem poniżej):

template-monster-perfomance-2

Twórca szablonu dodatkowo zapewnił wsparcie szablonu dla kilku komponentów Joomla!, m.in.:

  • Kunena Forum,
  • AcyMailing,
  • JoomGallery.

Podobnie jak cały CMS Joomla!, szablon wykorzystuje dość intensywnie możliwości frameworka Bootstrap w wersji 2.3.2, czyli de facto korzysta z przestarzałych rozwiązań CSS, które mimo to dalej się sprawdzają w zwykłych stronach internetowych. Dodam, że najnowsza wersja frameworka CSS to 3.3.4.

Szablon posiada dużo kodu HTML, częściowo totalnie zbędnego, lecz może to wynikać z faktu wykorzystywania różnorakich rozwiązań z frameworka Bootstrap jak i wykorzystywanych pluginów jQuery. Szablon wykorzystuje bibliotekę jQuery ładowaną lokalnie z serwera, a nie z serwera CDN (np. hostowanego przez Google).

Końcowa ocena szablonu

Ciężko oceniać mi tego typu szablony. Z jednej strony widzę mnóstwo kodu HTML, CSS i JS który jest zupełnie zbędny; widzę mnóstwo wodotrysków, które nie wpływają dobrze na wydajność strony internetowej, natomiast z drugiej strony widzę próbę przygotowania szablonu "wszystko mającego", który będzie spełniał zdecydowaną większość wymagań użytkownika, który zdecyduje się na tego typu rozwiązanie. Taka jest specyfika branży projektantów szablonów, gdzie klienci kupują oczami oglądając zdjęcia i wodotryski a niespecjalnie zwracają uwagę na kod, który mieliby ewentualnie ręcznie modyfikować.

Dlatego ogólna ocena będzie raczej pozytywna, ponieważ szablon spełnia wymagania zwykłego klienta tego typu twórców.

Wskazówki jak zoptymalizować szablon

W tej części zamierzam przedstawić kilka wskazówek na to jak można zoptymalizować działanie szablonu i przyspieszyć jego ładowanie. Wykonanie części wskazówek będzie wymagało przynajmniej podstawowej znajomości HTML i CSS.

Łączenie wielu plików CSS w jeden plik

Aby to zrobić, należy utworzyć jeden plik CSS a w nim, wg kolejności umiejscowienia plików CSS w kodzie szablonu, należy zamieścić skopiowane style z plików CSS. Taki plik ładujemy pod sam koniec kodu HTML (nie w sekcji HEAD) strony, tuż przed znacznikiem zamykającym </body>, przed skryptami JS. Pozostałe pliki CSS usuwamy z kodu HTML.

Łączenie wielu plików JS w jeden plik

Postępujemy tak samo jak z plikami CSS. Zawartość wielu plików JS przenosimy do jednego pliku i link do pliku umiejscawiamy przez znacznikiem zamykającym </body>, po pliku CSS, który wstawiliśmy w poprzedniej wskazówce.

Optymalizacja zestawu czcionek

Szablon od TemplateMonster ładuje kilka różnych zestawów czcionek z ikonami, m.in. FontAwesome. Naszym celem jest wybranie ikon które nas interesują a następnie połączenie ich w jeden zestaw za pomocą narzędzia IcoMoon. Dzięki temu nie będziemy ładować ikon, których nie potrzebujemy a także zmniejszymy ilość danych jakie trzeba pobrać z serwera.

Wygenerowanie krytycznych stylów CSS

Krytyczne style CSS to minimalny zestaw stylów CSS potrzebny do wygenerowania strony w wersji mobilnej. Najczęściej jest to zestaw stylów potrzebny do wygenerowania strony dla urządzeń z ekranem o szerokości do 480px.

Taki zestaw stylów możemy wygenerować za pomocą tego narzędzia, a następnie tak wygenerowane style wstawiamy do sekcji HEAD na wzór:

<head>
<style>
a,body,div,form,h1,h2,html,iframe,img,li,p,span,strong,ul{margin:0;padding:0;border:0;outline:0;font-size:100%;vertical-align:baseline;background:0 0}....
</style>
</head>

Podsumowanie

Mam nadzieję, że ten wpis okaże się przydatny dla Ciebie. Jego celem było pokazanie, że rozwiązania dla wielu mogą być dobre, mimo że mogą mieć kilka rozwiązań które sprawiają, że nie są najbardziej optymalne. Jednakże, zakładając że tego typu szablony mają spełniać mnóstwo, często niezdefiniowanych wymagań, to jest to dobry szablon.

  • Szablon ładny w gtmetrixie nie ma tragedii. Te wszystkie scripty do footera …nieładnie tylko, że do demówki używają CDN przez to im to tak ładnie śmiga 🙂

  • >Taki plik ładujemy pod sam koniec kodu HTML (nie w sekcji HEAD) strony, tuż przed znacznikiem zamykającym </body>, przed skryptami JS
    Z tym, że takie działanie na 90% spowoduje FOUC (zwłaszcza, że nic wcześniej nie zblokuje renderingu, bo skrypty mamy po CSS). Tego typu działanie ma sens jedynie wówczas, gdy równocześnie inlinujemy above-the-fold CSS na początku head. A nawet wówczas niekiedy opóźnienie wczytania CSS-a okaże się tragiczne dla perceived performance (np gdy stronka jest mała; oczywiście przy tej kobyle to średnio grozi ;)). I nie jest to problem związany jedynie z 1. wczytaniem strony – bo przecież parser DOM za każdym razem CSS-a znajdzie dopiero na dole. Dlatego ja proponowałbym inne rozwiązanie: skorzystanie z czegoś na wzór loadCSS od Filament Group i wsadzenie tego do head. A jeśli ktoś nie ma JS – fallback do normalnego, blokującego CSS-a. I tu znowu warto pamiętać, że przy lekkich stronach to po prostu się nie sprawdza. Próbowałem stosować obydwie praktyki na swojej domowej i z 90 pkt spadało do 70 – właśnie dlatego, że następował FOUC.
    Zatem – tak, opóźniać wczytanie dodatkowego CSS-a, ale tylko wówczas gdy style krytyczne zostały zinlinowane.

    Co do skryptów: dalej się zastanawiam czy wsadzenie ich do head z [async][defer] nie będzie wydajniejsze od standardowej praktyki z wsadzaniem ich na koniec body… Trza w końcu będzie spiąć poślady i przeprowadzić badania 😀 Na logikę winno być szybciej (skrypty będą wczytywane w tle i uruchomione po wczytaniu DOM), ale np może to źle wpłynąć na parallel download (przeglądarki biorą bodaj 6/8 requestów na domenę, więc 1/2 będzie na JS).

    No i nie wspomniałeś o minifikacji 😉

  • To może warto iść śladem demówek i też serwować content z CDN? 😉

  • Dziękuję! 🙂