mavicon.pl - Projekt WordPress | WPPoland

#mavicon.pl, nowoczesna strona prezentująca innowacyjne rozwiązania

Strona mavicon.pl powstała w 2012 roku i to jest pierwsza rzecz, którą trzeba o niej powiedzieć, bo bez tej daty reszta opisu wprowadza w błąd. Wdrożenie zajęło około sześciu tygodni. Rok 2012 to WordPress bez REST API w rdzeniu, bez edytora blokowego, z niestandardowymi typami treści dostępnymi od dwóch lat i z responsywnością, która dopiero co przestała być nowinką. React został udostępniony publicznie rok później, REST API trafiło do rdzenia WordPressa dopiero w wersji 4.7 pod koniec 2016 roku, a Tailwind CSS powstał w 2017. Lista technologii niżej opisuje więc stan po latach utrzymania, a nie stos, z którym projekt startował. Warto to nazwać wprost, bo opisy wdrożeń notorycznie podają dzisiejszą warstwę techniczną jako pierwotną i wtedy nie da się odróżnić decyzji projektowej od późniejszej wymiany wymuszonej przez upływ czasu.

Celem witryny było budowanie wizerunku eksperta w branży, prezentacja studiów przypadku oraz pozyskiwanie klientów zainteresowanych zaawansowanymi usługami IT i marketingu cyfrowego. Układ i rozmieszczenie elementów dostarczył klient, więc praca po naszej stronie dotyczyła modelu treści, szablonów i tego, co dzieje się z serwisem po starcie.

#co ta strona ma robić dla firmy

Firma sprzedająca rozwiązania techniczne ma na stronie problem odwrotny do sklepu. Sklep pokazuje produkt i cenę, a odbiorca w kilka sekund wie, czy to dla niego. Dostawca usług technicznych sprzedaje coś, czego nie da się pokazać, a odbiorca po drugiej stronie najczęściej nie potrafi jeszcze nazwać własnego problemu. Przychodzi z objawem, nie z zamówieniem.

Z tego wynika kilka konkretnych decyzji dotyczących treści. Po pierwsze, oferta musi być czytelna od strony objawu, a nie tylko od strony nazwy usługi. Osoba, której wolno działa system magazynowy, nie wpisuje w wyszukiwarkę nazwy technologii, którą trzeba wymienić. Po drugie, studium przypadku robi tu więcej niż opis usługi, bo pozwala rozpoznać własną sytuację w cudzej. Po trzecie, i to jest część najczęściej pomijana, strona musi wytrzymać czytanie przez osobę techniczną, która sprawdza, czy dostawca wie, o czym mówi. Ogólniki wypadają na tym teście natychmiast, a raz stracone zaufanie nie wraca kolejnym akapitem.

Dlatego model treści rozdziela trzy rzeczy, które w typowym serwisie firmowym siedzą razem: opis usługi, dowód w postaci realizacji i materiał wyjaśniający zagadnienie. Każde z nich ma innego odbiorcę, inny cykl aktualizacji i inne miejsce w ścieżce. Trzymanie ich w jednym typie treści oszczędza tydzień przy wdrożeniu i kosztuje przez kolejne lata, bo każda zmiana w jednym z nich wymusza ostrożność wobec dwóch pozostałych.

Druga decyzja dotyczy tego, czego na tej stronie celowo nie ma. Nie ma kalkulatora ceny, bo zakres tych usług wynika z audytu, a nie z listy parametrów, i kalkulator dawałby liczbę, której nikt nie potwierdzi. Nie ma licznika zrealizowanych projektów, bo taka liczba żyje własnym życiem i po roku nikt nie pamięta, co się do niej wliczało. Świadome pominięcie jest tu pełnoprawnym wynikiem pracy, nie luką w zakresie.

#kluczowe funkcjonalności i użyte technologie

Responsywność w 2012 roku nie polegała na dodaniu klas narzędziowych do gotowego szablonu. Siatki CSS i reguły responsywne pisało się ręcznie, a punkty łamania dobierało do treści, nie do listy popularnych rozdzielczości. Ta druga metoda wydaje się rozsądniejsza i starzeje się najgorzej, bo lista popularnych rozdzielczości zmienia się co dwa lata, a punkt, w którym tabela oferty przestaje się mieścić, jest właściwością tej tabeli i nie zmienia się nigdy.

System zarządzania treścią opiera się na WordPressie z niestandardowymi typami postów. Rozdzielenie usług, realizacji i wpisów bloga na osobne typy zamiast wrzucenia wszystkiego do kategorii jest decyzją, która zwraca się dopiero po dwóch latach. W pierwszym miesiącu wygląda na zbędną komplikację, bo wszystko da się zrobić kategorią. Po dwustu wpisach różnica jest taka, że zmiana szablonu realizacji nie dotyka bloga, a redaktor dodający usługę widzi formularz z polami usługi, a nie uniwersalne pole treści z instrukcją w komentarzu.

Moduły prezentacyjne ładują treść asynchronicznie, bez przeładowania strony. Tu warto nazwać kompromis, bo asynchroniczne ładowanie w serwisie marketingowym ma cenę, o której się nie mówi: treść dociągnięta po fakcie jest treścią, której wyszukiwarka może nie zobaczyć, a na stronie, której jedynym zadaniem jest pozyskiwanie zapytań z wyszukiwania, to nie jest kompromis techniczny, tylko biznesowy. Rozstrzygnięcie polegało na tym, że asynchronicznie dociąga się nawigacja po treści, filtrowanie i kolejne strony listingu, a nigdy sama treść wizytówki usługi. Pierwszy ekran jest kompletny w źródle dokumentu.

Optymalizacja SEO obejmuje dane strukturalne, meta tagi i czytelne adresy. Dane strukturalne w 2012 roku były znacznie mniej opłacalne niż dzisiaj, bo wyszukiwarki dopiero zaczynały je wykorzystywać. Zwrot przyszedł później i przyszedł tylko tam, gdzie znaczniki opisywały realny byt, czyli firmę i jej usługi, a nie tam, gdzie były dosypane do każdej podstrony.

Galeria, materiały wideo i animacje podkreślają charakter serwisu, ale największym zagrożeniem dla takiej strony jest właśnie ta warstwa. Każdy dodany efekt kosztuje pasmo i czas do pierwszego renderowania, a na stronie firmowej nie ma mechanizmu, który zmusiłby kogokolwiek do czekania. Dlatego animacje są wtórne wobec treści i nie blokują jej wyświetlenia.

Formularz kontaktowy waliduje dane po stronie klienta i serwera oraz kieruje zgłoszenia do właściwych działów. Podwójna walidacja nie jest tu nadmiarem. Walidacja w przeglądarce istnieje po to, żeby użytkownik nie czekał na odpowiedź serwera, żeby dowiedzieć się o literówce. Walidacja po stronie serwera istnieje dlatego, że tę pierwszą można pominąć, a formularz kontaktowy bez niej jest po prostu otwartym wejściem dla botów.

#wyzwania i rozwiązania programistyczne

Integracja dynamicznych treści wymagała własnych punktów końcowych. Przy braku REST API w rdzeniu WordPressa oznaczało to napisanie własnej warstwy wejścia, z własnym sprawdzaniem uprawnień i własnym formatem odpowiedzi. Ta praca zestarzała się najszybciej z całego projektu i to jest w niej najciekawsze: kod, który powstał, bo platforma czegoś nie miała, jest pierwszym kandydatem do usunięcia w dniu, w którym platforma to dostaje. Przeciwne podejście, czyli utrzymywanie własnego rozwiązania obok rdzenia, kosztuje potem przy każdej aktualizacji.

Optymalizacja wydajności oparła się na wielowarstwowym buforowaniu z Redis i Memcached oraz na kompresji zasobów i dystrybucji przez CDN. Dwie pamięci podręczne w jednym wdrożeniu brzmią jak nadmiar, dopóki nie zobaczy się, że obsługują różne rzeczy: jedna cache obiektowy dla zapytań do bazy, druga sesje i fragmenty widoków. Zysk z cache obiektowego w serwisie marketingowym jest jednak mniejszy, niż się powszechnie zakłada, bo większość ruchu to użytkownicy anonimowi na kilkunastu podstronach, a tych da się obsłużyć taniej, oddając całą stronę z cache i w ogóle nie schodząc do PHP.

Integracja z systemami zewnętrznymi objęła dwukierunkową wymianę z CRM i platformami analitycznymi. Najważniejsza decyzja dotyczyła zachowania przy awarii. Domyślne zachowanie większości wtyczek to pokazać błąd albo pustą sekcję, co na stronie sprzedażowej wygląda jak awaria całego serwisu. Tutaj każde połączenie ma wartość zapasową: ostatnią znaną odpowiedź, a gdy i tej nie ma, statyczny wariant sekcji. Odwiedzający widzi wtedy stronę bez jednego modułu, a nie komunikat o błędzie.

Migracja treści z archiwalnych wersji strony korzystała z narzędzi importu i eksportu oraz z zasobów Web Archive. Przenoszenie treści z archiwum ma pułapkę, którą widać dopiero po publikacji: archiwum zachowuje tekst, ale nie zachowuje adresów, pod którymi ten tekst był indeksowany, ani obrazków, które ładowały się z zewnętrznych domen. Jeśli nie odtworzy się starych adresów przekierowaniami, migracja wygląda na udaną i jednocześnie kasuje całą historię pozycji w wyszukiwarce.

#wydajność serwisu marketingowego, czyli gdzie naprawdę leży czas

Przy stronie firmowej dyskusja o wydajności najczęściej schodzi na minifikację i kompresję obrazów, czyli na te kilkanaście procent, które widać w narzędziu pomiarowym. Realny koszt siedzi gdzie indziej i jest tym samym w niemal każdym wdrożeniu WordPressa tej klasy.

Pierwszy koszt to liczba zapytań do bazy na jedno żądanie. Motyw, który buduje menu, listę realizacji i sekcję powiązanych usług osobnymi zapytaniami w pętli, generuje ich kilkadziesiąt tam, gdzie wystarczyłyby trzy. Na pustej instalacji nie widać tego wcale, bo baza ma po kilkanaście rekordów w każdej tabeli. Po dwóch latach publikowania różnica jest wyraźna i objawia się jako ogólne spowolnienie bez jednej wyraźnej przyczyny, czyli najgorszy rodzaj problemu wydajnościowego.

Drugi koszt to zasoby ładowane globalnie. Wtyczka formularza kontaktowego domyślnie dokłada swój arkusz stylów i skrypt do każdej podstrony, łącznie z tymi, na których żadnego formularza nie ma. To samo robi wtyczka galerii i wtyczka slidera. Zsumowane dają kilkaset kilobajtów, których nikt nigdy nie użyje, i żadna z nich nie wygląda na winną z osobna.

Trzeci koszt jest najmniej oczywisty i dotyczy skryptów zewnętrznych. Narzędzia analityczne, czat i piksele reklamowe wchodzą na stronę przez kod wklejony do nagłówka i przestają podlegać jakiejkolwiek kontroli wersji. Awaria po stronie dostawcy takiego skryptu potrafi zablokować renderowanie strony, na której poza tym wszystko jest w porządku, a diagnoza zaczyna się od sprawdzania własnego kodu, bo nikt nie pamięta o linijce wklejonej rok wcześniej.

Kolejność prac wydajnościowych wynika wprost z tych trzech punktów: najpierw oddawanie całych stron z pamięci podręcznej dla ruchu anonimowego, potem porządek w zapytaniach dla widoków, których nie da się buforować, a kompresja zasobów na końcu. Odwrócenie tej kolejności daje ładny wynik w teście syntetycznym i nie zmienia nic w tym, co odczuwa odwiedzający.

#narzędzia i technologie

WordPress pozostaje podstawą, bo pozwala klientowi edytować treść bez wsparcia programisty, a to w serwisie marketingowym jest najważniejszym kryterium. PHP i MySQL obsługują warstwę serwerową. Warto zaznaczyć, że wersja PHP 7 pojawiła się dopiero w 2015 roku, więc aktualizacja środowiska z gałęzi 5.x była osobnym zadaniem utrzymaniowym kilka lat po starcie, a nie decyzją podjętą przy wdrożeniu.

HTML5, CSS3, SASS i JavaScript tworzą warstwę prezentacji. SASS porządkuje arkusze stylów w projekcie, który ma rosnąć, i tu leży jego realna wartość: nie w skróceniu zapisu, tylko w tym, że zmienna z kolorem marki ma jedno miejsce, a nie czterdzieści. Bootstrap i Tailwind CSS przyspieszają budowanie spójnego układu, przy czym Tailwind powstał w 2017 roku i wszedł do projektu w ramach późniejszych prac, nie przy starcie.

Redis i Memcached odpowiadają za pamięć podręczną, Git za wersjonowanie kodu. Wersjonowanie w projekcie tej wielkości bywa uznawane za formalność i jest dokładnie odwrotnie: to jedyny mechanizm, dzięki któremu poprawka wprowadzona w pośpiechu daje się cofnąć bez zgadywania, co dokładnie zostało zmienione.

#wsparcie i utrzymanie strony na WordPress

Opieka nad witryną obejmuje reagowanie na problemy techniczne i naprawę błędów po aktualizacjach, regularne aktualizacje rdzenia, motywu i wtyczek, monitorowanie logów, tworzenie kopii zapasowych według harmonogramu oraz drobne modyfikacje funkcjonalne i graficzne.

Jedna rzecz z tej listy zasługuje na rozwinięcie, bo jest źródłem większości incydentów w serwisach o tym profilu. Aktualizacja wtyczki rzadko psuje stronę sama z siebie. Psuje ją wtedy, gdy motyw nadpisywał zachowanie tej wtyczki, opierając się na szczególe implementacyjnym, którego autor nigdy nie obiecał utrzymywać. Dlatego aktualizacje idą najpierw na środowisko testowe będące kopią produkcji, a nie czystą instalacją. Na pustej instalacji z motywem domyślnym wszystko działa i test nie mówi nic o tym, co się stanie na produkcji.

Kopie zapasowe mają wartość dopiero wtedy, gdy ktoś przynajmniej raz z nich odtworzył serwis. Kopia, której nigdy nie przywracano, jest deklaracją, nie zabezpieczeniem, i różnicę tę odkrywa się zawsze w najgorszym możliwym momencie.

#podsumowanie i wstępna analiza wymagań klienta

Wstępna analiza potrzeb ustaliła kilka rzeczy, które stały się fundamentem projektu. Celem było budowanie wizerunku firmy jako dostawcy zaawansowanych rozwiązań i pozyskiwanie klientów zainteresowanych takimi usługami. Wymagania obejmowały dynamiczną prezentację oferty, integrację z systemami zewnętrznymi i elastyczny system zarządzania treścią. Zakres prac objął modernizację architektury serwisu, wdrożenie responsywnych widoków i moduły prezentacyjne. Projekt podzielono na etapy, co pozwoliło wdrażać funkcje stopniowo. Klient wskazał serwisy z przejrzystą prezentacją oferty jako punkt odniesienia i to wpłynęło na ostateczny kształt.

Z perspektywy czasu najciekawsza jest ta ostatnia pozycja. Wskazanie referencji przez klienta zwykle traktuje się jako materiał na moodboard. W praktyce te referencje niosą informację o czymś zupełnie innym niż estetyka: mówią, w jakiej kolejności klient uważa za naturalne czytanie oferty, gdzie spodziewa się ceny, a gdzie kontaktu. To są rozstrzygnięcia dotyczące modelu treści, a nie wyglądu, i przenoszą się na kolejne projekty znacznie lepiej niż układ graficzny.

Strona mavicon.pl została przygotowana jako narzędzie marketingowe z przejrzystą strukturą oferty, miejscem na studia przypadku i zapleczem do dalszej aktualizacji treści. To, co z tego wdrożenia przenosi się dalej, to sposób pracy: model treści wyprzedzający szablon, testy na kopii produkcji i wyraźne rozdzielenie tego, co ma być w źródle dokumentu, od tego, co może dociągnąć się później. Nie przenosi się sam stos, bo stos z 2012 roku jest dziś w połowie inny, i to jest normalna kolej rzeczy, a nie wada projektu.