Nie samym WordPressem człowiek żyje – o generatorach stron statycznych

Swoje pierwsze strony WWW robiłem jeszcze w czasach, kiedy mało kto słyszał o CSS, a układ strony projektowało się za pomocą tabelek. Jako że nie znałem wówczas nawet podstaw PHP, to poszczególne podstrony były po prostu osobnymi plikami html. Szkopuł w tym, że edycja jakiegokolwiek elementu powtarzającego się na każdej podstronie (jak nagłówek, menu, stopka) wymagała żmudnego wprowadzania zmiany w każdym pliku z osobna. Na dłuższą metę – niezbyt wygodne.

WordPress

Wybawieniem okazał się dla mnie WordPress. Umożliwił odseparowanie szablonu od treści strony, dzięki czemu zmianę w stopce czy nagłówku wystarczyło wprowadzić w jednym miejscu, a nie – dajmy na to – czterdziestu. Przy okazji dał dostęp do wielu zaawansowanych funkcji, jak filtrowanie wpisów według kategorii i tagów, paginacja, komentarze, formularze kontaktowe. Od tamtej pory, gdy tylko trzeba było zrobić stronę – nie ważne: dużą czy małą, rozbudowany portal czy prostą wizytówkę – korzystałem z WordPressa. Postawiłem ich kilkadziesiąt.

Z czasem (oraz rosnącą liczbą instancji, których musiałem doglądać) coraz bardziej dokuczliwe stawały się jednak uciążliwości, jakie wynikały z bezkrytycznego polegania na najpopularniejszym CMS-ie.

Problemy związane z WordPressem

Z prostego narzędzia do blogowania w przeciągu dekady WordPress przeobraził się w silnik odpowiedzialny za napędzanie 1/5 całego Internetu. Nie dziwota, że stał się celem hakerskich ataków. Znalezienie luki w rdzeniu systemu, bądź którejś z popularnych wtyczek, daje możliwość włamania się na nie jedną, ale tysiące stron. Na szczęście dziury takie są z reguły szybko wyłapywane i łatane. Twoja jednak Użytkowniku głowa (i interes) w tym, byś zawsze korzystał z najnowszej, a nie przestarzałej wersji oprogramowania, a w razie najgorszego – dysponował aktualną kopią zapasową bazy danych oraz plików witryny.

Kiedy posiadasz jedną stronę na WP, to jeszcze nie jest problem – problem pojawia się wtedy, gdy masz ich kilkadziesiąt i każda powinna być regularnie aktualizowana, a wpierw backupowana, gdyż nieraz upgrade któregoś pluginu potrafi sprawić, że „coś nie hula”. Istnieją wprawdzie narzędzia do hurtowego zarządzania stronami opartymi o WordPress, lecz ani nie są one darmowe, ani nie chronią przed ewentualną niekompatybilnością nowej wersji danej wtyczki z Twoim szablonem czy którymś z pozostałych pluginów.

Syzyfowe prace przy aktualizacjach to niestety nie jedyne zmartwienie. Kiedy ktoś odwiedza stronę na WordPressie, ten – zanim ją wyświetli – musi „poprosić serwer” o wykonanie całego szeregu operacji – m.in. parsowanie kodu PHP i pobieranie pożądanych treści z bazy danych. Dopiero zebrawszy wszystko do kupy w postaci czytelnego dla przeglądarki kodu HTML może zaprezentować stronę odwiedzającemu. Operacje te muszą zostać wykonane dla każdej podstrony, na którą zawędruje użytkownik oraz za każdym razem, gdy jakaś kolejna osoba odwiedzi stronę.

Jeśli prowadzimy blog, na którego i tak pies z kulawą nogą nie zagląda, to nie ma się czym przejmować. Ale gdy nasz adres zaczyna być popularny albo trafi na główną stronę Wykopu, to możemy mieć problem. Dobry hosting, który zdoła obsłużyć duży ruch, do najtańszych nie należy. A jeszcze niech przypałęta się jakiś bot, próbujący sforsować nasz login i hasło metodą „brutalnej siły” albo przyczepi się do pliku xmlrpc… Oczywiście przed takimi atakami da się bronić, jednak znów wymaga to poświęcania naszej stronie dodatkowego czasu.

Skoro już przy czasie jesteśmy: generowanie witryny na żądanie, jak czyni to WordPress, nie tylko obciąża serwer, ale też trwa – niekiedy nawet kilka sekund. Nieoptymalnie napisany szablon i duża liczba wtyczek mogą sprawić, że strona „zamula”. Tymczasem prędkość ma kluczowe znaczenie – udowodniono, że im wolniej działa dany serwis, tym mniej użytkowników będzie skłonnych z niego korzystać. Szybkość działania jest też brana pod uwagę przez Google przy ustalaniu pozycji strony w wyszukiwarce.

W rozwiązaniu obu opisanych powyżej problemów pomocne mogą być wtyczki cashujące – potrafią one postawić na nogi WordPress, który ugiął się pod ciężarem zmasowanego ruchu i przyspieszyć serwowanie stron. Prawidłowa konfiguracja takiego pluginu nie jest jednak łatwa (są to prawdziwe kombajny), zaś źle skonfigurowany może przynieść więcej szkód niż pożytku. Poza tym, jest to leczenie objawów – a gdyby tak dało się zlikwidować przyczynę?

Czy naprawdę potrzebuję WordPressa?

Wiele spośród stron, które postawiłem na WordPressie, tak naprawdę spokojnie mogłoby się obejść bez niego. Jak wspomniałem na początku – genezą mojego zainteresowania tym CMS-em była możlwość korzystania z szablonów, dzięki którym poszczególne podstrony współdzieliły fragmenty kodu odpowiedzialne za wyświetlanie nagłówka, stopki etc. Oprócz tego WordPress, z całym uniwersum wtyczek, oferował niezliczoną liczbę dodatkowych, mniej lub bardziej zaawansowanych funkcji (jak choćby dodawanie treści przez wielu użytkowników z różnymi poziomami uprawnień czy zastrzeżenie dostępu do części artykułów tylko dla osób, które zań zapłaciły). Sęk w tym, że w przypadku wielu witryn funkcje te są całkowicie zbędne.

Wizytówki firm czy NGO-sów, ich strony projektowe, portfolio artystów i tym podobne strony można by określić wspólnym mianem „tylko do odczytu”. Poza ewentualnym formularzem kontaktowym nie przewidują one z reguły interakcji z użytkownikami. Do zbudowania takiej witryny nadal wystarczyłby zwykły, statyczny HTML – gdyby tylko dało się go pisać bardziej efektywnie niż kiedyś, tj. nie każdą podstronę osobno…

Generatory stron statycznych

Okazuje się, że narzędzia to umożliwiające już istnieją (a wręcz – jest ich całe mnóstwo), mają otwarty kod, są darmowe i zdobywają coraz większą popularność. Mowa o tzw. „generatorach stron statycznych” (static site generators). Najbardziej znany (bo powiązany z serwisem GitHub) jest Jekyll. Osobiście mogę polecić też MiddleMana (za pomocą którego zbudowana jest niniejsza strona).

Podobnie jak CMS-y, generatory te pozwalają oddzielić treści poszczególnych podstron od szablonu. Różnica polega na tym, że proces „wlewania” tych treści do „skórki” odbywa się nie „w locie”, za każdym razem, kiedy ktoś odwiedzi naszą stronę, ale a priori – wszystkie podstrony w wygodny, zautomatyzowany sposób zostają wygenerowane wcześniej lokalnie, na naszym komputerze. Na serwer wrzucamy już komplet plików całej witryny – każdej podstronie odpowiada gotowy plik html i tylko czeka, by zostać zaserwowany temu, kto na nią wejdzie.

Rozwiązanie takie ma wiele plusów: strony ładują się błyskawicznie; są o wiele bezpieczniejsze – nie ma kodu PHP ani bazy danych, które mogłyby zostać zhakowane; tańsze (a nawet darmowe) w utrzymaniu – nie obciążają pamięci obliczeniowej serwera; mniej czasochłonne – nie trzeba co i rusz aktualizować CMS-a i wtyczek, a wykonanie kopii zapasowej czy ewentualna migracja strony na inny serwer sprowadza się do skopiowania plików (nie trzeba się użerać z bazą danych).

Mimo, że produktem generatorów są statyczne pliki html, nie oznacza to wcale, że narzędzia te same w sobie są prymitywne. Skórki pisze się za pomocą „języków templatkowych” (templating languages), które umożliwiają korzystanie ze zmiennych oraz wykonywanie pętli. Generatory mają też z reguły wbudowaną obsługę popularnych narzędzi ułatwiającyh pisanie HTML-a (Markdown), CSS-a (Sass, Less) i JavaScriptu (CoffeeScript). Arkusze stylów i skrypty mogą być automatycznie zmniejszane (minify). Dostępne są mechanizmy wspomagające efektywne cashowanie. Można też zautomatyzować tworzenie mapy strony i kanału RSS.

Poszczególnym stronom/wpisom można przyporządkować metadane, np. autora, datę, kategorie, tagi. Nic nie stoi zatem na przeszkodzie, aby za pomocą generatora statycznych stron prowadzić nawet blog. Istnieją zresztą gotowe narzędzia służące właśnie do blogowania.

Wprawdzie nie da się zbudować na samym tylko HTML-u systemu umożliwiającego czytelnikom komentowanie artykułów (a niewątpliwie przydałby się taki, gdybyśmy zechcieli prowadzić „statyczny blog”), ale w dzisiejszych czasach możemy na szczęście zlecić obsługę takiej funkcjonalności na zewnątrz. Mam tu na myśli serwis Disqus, który nierzadko przecież zastępuje tradycyjne komentarze także na blogach napędzanych przez WordPress – oszczędzając tym samym ich autorom bólu głowy związanego z uporczywym spamem. Również formularze kontaktowe da się zaimplementować korzystając z zewnętrznych narzędzi (Simple Form, PooleApp), a wewnętrzną wyszukiwarkę zastąpić zaembedowanym okienkiem Google z ustawionym ograniczaniczeniem wyszukiwania tylko w obrębie naszej domeny.

Podsumowanie

Nie chciałbym zostać źle zrozumiany – celem niniejszego artykułu nie jest bynajmniej zniechęcanie kogokolwiek do używania WordPressa w ogóle. To świetne narzędzie i sam na pewno nie raz jeszcze będę z niego korzystał przy niejednym projekcie. Cały myk polega jednak na tym, by narzędzie dobierać świadomie i wykorzystywać je przy projektach, do realizacji których faktycznie będzie ono najodpowiedniejsze – a nie do wszystkiego, jak leci. Skoro za pomocą Jekylla zostały zbudowane nawet takie strony jak platforma fundraisingowa na rzecz kampanii prezydenckiej Baracka Obamy, Healthcare.gov czy Google Web Fundamentals, to coś musi być na rzeczy.

Główną przeszkodą w szerszym wykorzystaniu generatorów statycznych stron, którą dostrzegam, nie są ich możliwości – te bowiem są całkiem spore i w przypadku wielu witryn wystarczające. Problem może stanowić nieco wyżej zawieszona poprzeczka, jeśli chodzi o łatwość ich obsługi. Możliwość własnoręcznego aktualizowania strony jest jednym z tych wymagań, które pojawiają się przy okazji każdego zlecenia. Nie każdy klient będzie natomiast skłonny znaleźć w sobie dość determinacji, by treści edytować w plikach Markdown (a nie za pomocą edytora WYSIWYG) oraz przyswoić sobie obsługę wiersza poleceń – nawet jeśli liczbę niezbędnych komend da się policzyć na palcach jednej ręki.

Na szczęście twórcy generatorów zdają sobie sprawę z tego problemu i starają się mu zaradzić. Twórca Middlemana rozwija dodatek (płatny) umożliwiający edycję treści za pomocą wizualnego interfejsu. A jeżeli zależy nam na czymś darmowym, możemy skorzystać z Prose.io – edytora stron generowanych przez Jekylla bezpośrednio na GitHub Pages.

Rozwiązaniem pośrednim mogą być też (ostatnio coraz bardziej popularne) tzw. „flat file CMS-y” – stojące mniej więcej w pół drogi pomiędzy tradycyjnymi, korzystającymi z bazy danych CMS-ami (jak WordPress) a generatorami stron statycznych. Ale to już temat na osobny artykuł…

Na sam koniec garść linków dla pragnących zgłębić temat:

comments powered by Disqus