Kolejna strona oparta na Hugo (www.aqua-tech.net.pl)
Przeszło trzy lata (2018) temu zrobiłem stronę dla firmy AQUA TECH. Podobnie jak strona Turbo Kliniki, nie był to jakiś nadzwyczajnie duży projekt.
Kolejny raz wybrałem WordPress jako bazę, wiedząc, że jest to jak wkładanie silnika z porsche do fiata 125p. Na tamten okres było to jednak słuszne rozwiązanie i pozwoliło na ograniczenie kosztów związanych ze stroną internetową oferowaną przez innego dostawcę.
Strona bazowała na zmodyfikowany motywie Appointment i spisywała się w marę dobrze, do czasu, jak kolejne aktualizacje WordPress oraz ich wtyczek zaczęły go psuć.
Niechętny byłem nad naprawą tego, co jest zepsute, gdyż straciłbym na tym więcej czasu niż stworzenie odpowiednika strony w Hugo.
I tak zacząłem pracę, a jednocześnie dla mnie, naukę.
Elementy zastosowane na stronie AQUA TECH były nieco inne a niżeli na Turbo Klinice, jak i na mojej stronie, więc musiałem nieco pomyśleć.
Mimo że sekcje strony są podobne, przez co wykorzystałem podobny kod, to podczas tworzenia musiałem użyć nieco innego podejścia.
Nie lada wyzwaniem stała się karuzela ze zdjęciami na pierwszej stronie.
Nie problem jest znaleźć gotowe rozwiązanie bazujące na JavaScript. Problem z tym jest jednak, że powoduje to nadmierne wykorzystanie zasobów, co negatywnie wpływa na wydajność strony mierzonej w Google PageSpeed Insight.
Po przeczytaniu wpisu Best practices for carousels wiedziałem, jak zdjęcia muszą być ładowane. To, co nie zostało tam poruszone, to fakt, że pierwsze zdjęcie musi się ładować od razu, natomiast każde kolejne powinno posiadać atrybut loading="lazy". W przeciwieństwie otrzymamy wysoki wynik LCP i cała strona będzie się ładowała, dopóki wszystkie zdjęcia nie zostaną załadowane.
Nie udało mi się uniknąć JavaScriptu, ale wykorzystałem go jedynie do funkcji zmiany zdjęcia a niżeli samego ładowania obrazów jak, w co niektórych zastosowaniach.
Jako, że znalezienie dobrego rozwiązania na karuzele jest nieco problematyczne, postanowiłem udostępnić użyty kod na GitHub (podobnie, jak to zrobiłem w przypadku paska informującego o ciasteczkach, który źle zastosowany może negatywnie wpływać na CLS).
Kolejnym wyzwaniem stały się galerie ze zdjęciami.
Otóż gdy strona, tak jak Turbo Klinika, zawiera nieco mniej zdjęć, wstawienie ich pojedynczo w Markdown nie jest tak problematyczne. W przypadku gdy mamy wstawić ich setkę. Wówczas nie jest tak fajnie.
Przypomniałem sobie o zastosowaniu, które znalazłem, gdy próbowałem rozwiązać mój problem z galeriami w Hugo, a mianowicie galerie bazujące na zdjęciach w folderach.
Polega to na tym, że zdjęcia, które mają wyświetlić się w postaci galerii, wrzucamy do osobnego folderu, który później przywołujemy “shortcode’m”.
Nie do końca wiem, jakie jest sensowne tłumaczenie “shortcode” na język polski, bo “którki kod” brzmi dziwnie.
Pomocny okazał się wpis Building an image gallery for Hugo, który musiałem odpowiednio zmodyfikować, aby dodać między innymi format zdjęć WebP.
Na stronie z ofertą firmy zastosowane zostały tak zwane “collapsable”, czyli elementy, po kliknięciu na które pokazują zawartość danej sekcji.
Problem z WordPress był taki, że czasem to działało, ale jeszcze częściej nie. Tym razem, przy użyciu rozwiązania z W3School, minimalnym zastosowaniu HTML, CSS i JavaScriptu udało mi się osiągnąć zamierzony efekt.
Oczywiście, całość używa “shortcode” w Hugo i jest ładnie zintegrowane z tekstem przechowywanym w Markdown.
Oprócz przeniesienia strony musiałem jeszcze rozwiązać jeden problem niezwiązany bezpośrednio ze stroną, a mianowicie adres email.
W obecnym ustawieniu, maile wysyłane na kontakt@ przekazywane są na odpowiednie adresy firmowe.
Firma ta nie używa poczty we własnej domenie, gdyż nie ma to aż takie potrzeby. Skupiają się oni na świadczeniu wysokich jakości usług a niżeli zbędnej wymiany korespondencji elektronicznej.
W związku z tym przypomniałem sobie o Mailgun, który używałem w przeszłości przy innym projekcie.
Mailgun jest swego rodzaju pośrednikiem w przesyłaniu poczty elektronicznej. Jest on skierowany głównie do programistów, jednakże nie stoi nic na przeszkodzie w wykorzystaniu tego do innych celów, szczególnie że do 1000 maili (w miesiącu) wysłanych na adres przez nich obsługiwany nie zapłacimy nic. Dla tego typu projektu jest to jak znalazł.
Jednakże, oprócz Mailgun w internecie dostępne są również inne usługi:
Chciałem spróbować ForwardEmail, który oferuje w darmowym planie nielimitowaną liczbę domen, nielimitowaną liczbę adresów, adresy jednorazowe (disposable emails), zaawansowaną ochronę oraz obsługę załączników do 50MB. Niestety, podczas dodawania domeny otrzymałem komunikat, że domena z końcówką PL jest uważana przez nich za złośliwą i wymaga to, aby jeden użytkownik (administrator) posiadał płatną subskrypcję.
Gratuluje wszystkim tym idiotom w Polsce, którzy przysłużyli się do takiego stanu rzeczy.
W związku z tym postanowiłem spróbować ImprovMX.
ImprovMX w darmowym planie (oznaczonym jako “za darmo, na zawsze”) oferuje możliwość dodania jednej domeny, maksymalnie 25 adresów (aliasów) na domenę oraz załączniki do 10MB.
Nie ma możliwość wysyłania maili z domeny, co w moim przypadku nie jest problemem (chyba że ma się pocztę na Gmail w której można użyć opcji Wysyłaj jako — szczegóły tutaj).
Doręczenie adresów email odbywa się z “normalną” prędkością w porównaniu z “szybką” na płatnym planie. Słowo “normalną” lub “szybką” nic nie mówi więcej, więc będzie mi spróbować to w praktyce. Z tego, co widzę, wiadomość trafia do odbiorcy z około kilkunastosekundowym opóźnieniem, w skrajnych przypadkach kilku minutowym.
Wszystko można śledzić w logach dostępnych w panelu administracyjnym.
Z przenosin tej strony nauczyłem się kolejnych rzeczy. Jedną z nich jest to, że nie da się wykorzystać gotowego rozwiązania, lekko go dostosowując, szczególnie gdy strony, mimo że proste, stanowczo różnią się od siebie zawartością.
Im więcej rozwiązań za sobą, tym większe pole do popisu mamy tworząc kolejne strony, spędzając mniej czasu na poszukiwaniach (research).
W między czasie efekt końcowy możemy podziwiać na aqua-tech.net.pl.
Pozdrawiam.
