Ewolucja podejścia do tworzenia stron internetowych
Pierwotnie renderowanie HTML całkowicie po stronie serwera było standardem, ale wraz z dynamicznym rozwojem JavaScriptu, sytuacja się zmieniła. Dziś podejście SPA (Single Page Application) stało się dla wielu firm nowym rozwiązaniem domyślnym. Warto jednak zastanowić się, z jakimi korzyściami i kosztami wiąże się implementowanie MPA (Multi-Page Application) i SPA.
MPA to klasyczne rozwiązanie, w którym dynamiczna treść HTML jest generowana po stronie serwerowej. Każde przejście między stronami to żądanie nowej strony HTML. Takie podejście nie oznacza wcale, że przerzucamy całą robotę na serwer – klient nadal musi parsować HTML, aplikować CSS i wykonywać skrypty JS, których nawet w tym podejściu nie brakuje.
SPA to podejście intensywnie rozwijane w ostatnich kilkunastu latach. Idea jest taka, by raz załadować cały front-end, który będzie ubierał w HTML dane, które przyjdą z serwera. Dzięki temu kolejne akcje nawigacji odbywają się bez przeładowania całej strony, a jedynie części drzewa DOM.
Wydajność MPA vs SPA
Powszechnie uważa się, że nawigacja w MPA jest dużo wolniejsza niż w SPA, natomiast pierwsze załadowanie strony w SPA będzie wolniejsze niż w MPA. I ogólnie to prawda, jednak obydwa podejścia mają do dyspozycji sporo narzędzi, sprawiających że mogą mieć podobną wydajność.
W ładowaniu kolejnych stron MPA najbardziej pomaga cache przeglądarki. Dzięki niemu – oprócz HTML i obrazków – rzadko trzeba będzie ładować coś więcej przy przejściu między stronami. Faktem jest, że trzeba przeładować pełne drzewo DOM i powtórnie zainicjalizować style oraz skrypty. Jeżeli tych zasobów jest dużo, mamy problem, który w SPA byłby mniej odczuwalny po załadowaniu aplikacji.
Przy pierwszym ładowaniu SPA, kłopot pojawia się, gdy najpierw ładowana jest pełna aplikacja, a dopiero potem dane. Właśnie to najbardziej wydłuża odczuwalny czas ładowania strony, a niestety takie podejście jest często spotykane. Współcześnie na wielu stronach występuje jednak ładowanie progresywne – czyli np. pre-renderowanie pewnej porcji danych już na back-endzie. Dzięki temu od razu można pokazać znaczące informacje.
Współcześnie mamy w arsenale wiele narzędzi, które pomagają w walce z powolną inicjalizacją: HTTP2 i Server Push, narzędzia deweloperskie, Service Workery, leniwe ładowanie, wskazówki ładowania zasobów. Gdy właściwie się ich użyje, strona będzie w pełni interaktywna w naprawdę krótkim czasie. To bardzo pomaga zarówno aplikacjom SPA, jak i MPA.
Podejście SPA a wydajność
Przejście na kolejną stronę w SPA wiąże się zarówno z kosztami, jak i korzyściami. Pod względem wydajności, SPA w dużej mierze przerzuca zapotrzebowanie na zasoby na klienta/użytkownika tego rozwiązania. Ładowanie głównej części strony, a następnie zmiana jej zawartości wedle potrzeb na żywo, jest rozwiązaniem, które umożliwia wprowadzanie znacznie bardziej rozbudowanej logiki. Nie musimy martwić się wtedy o użytkownika oczekującego na ładowanie strony.
Pewnym problemem dużych aplikacji SPA jest zarządzanie pamięcią – musi być ono sprawne, by uniknąć jej zaśmiecenia. Trzeba jednak spojrzeć na potrzeby użytkownika. Jeżeli logika pojedynczego zadania jest bardzo rozbudowana, może okazać się, że lepszym rozwiązaniem będzie przekazanie takiego zadania do serwera i przeładowanie strony w celu zwolnienia zasobów zarezerwowanych wcześniej. W ten sposób udaje się odciążyć komputer użytkownika.
Samo rozdzielenie prezentacji od reszty logiki poprzez API daje spore korzyści. Przede wszystkim wprowadza loose coupling między logiką backendową a frontendową. Nadal w podejściu SPA można stworzyć aplikację niemożliwą do rozwoju i utrzymania. Jednak jest parę bonusów, które po prostu łatwiej uzyskać.
Zalety SPA w kontekście architektury
SPA pozwala na zbudowanie strony modularnie – z front-endem niezależnym od back-endu, powiązanym tylko przez API. Działa to na zasadzie mikroserwisów generujących poszczególne zagadnienia logiki aplikacji. Łatwo wyobrazić sobie wtedy, że każdy taki mikroserwis może być nawet w niezależnej infrastrukturze, dając możliwość współbieżności na poziomie fizycznym.
To oczywiście nie znaczy, że to samo jest nieosiągalne w MPA. Zarówno zmniejszenie zależności, jak i oddzielenie infrastruktury, jest możliwe, jednak wymaga dokładnego przemyślenia. Aplikacje klasyczne również mogą posiadać taką strukturę, która będzie jednak znacznie bardziej uzależniona od usług sieciowych oraz administracji.
Ciekawą zaletą SPA jest to, że cały front-end to statyczne pliki, które można łatwo porozmieszczać na CDN. Ba, nie trzeba nawet mieć serwera typu Nginx czy Apache do hostowania plików związanych z frontendem.
Złożoność rozwiązań – MPA vs SPA
Jeżeli mowa o samym skomplikowaniu rozwiązania, w większości przypadków MPA będzie prostsze. Wsparcie frameworków MVC dla tego typu stron jest bardzo dobre, i w zasadzie każdy oferuje renderowanie HTML. To bardzo stabilna technologia, która nie zmieniła się na przestrzeni ostatnich lat – w przeciwieństwie do tego, co dzieje się w świecie JS.
Natomiast to, że backend wystawia API w SPA, będzie dużą zaletą, o ile w grę wchodzi aplikacja mobilna – co też warto podkreślić. Tu narosło sporo mitów i czas je wyprostować.
SEO w SPA – mity i rzeczywistość
Powszechnie uważa się, że SEO w SPA może być gorsze niż w MPA. Wymaga to co prawda dobrego przemyślenia i na pewno nie będzie to tak łatwe, jak w przypadku wielu stron generowanych na backendzie, jednak jest jak najbardziej możliwe.
Google w swoich zaleceniach promuje dziś technologię SPA. Mówi się o coraz lepszym odczytywaniu skryptów na stronach przez roboty indeksujące, mamy też strony mobilne w technologii AMP. Jak widać, wszystko idzie w kierunku coraz bardziej dynamicznych stron, i w ciągu ostatnich kilku lat widzieliśmy duży postęp, jeżeli chodzi o wsparcie dla takich aplikacji.
Google potwierdziło kilka lat temu, że ich robot jest w stanie czytać i wykonywać CSS i JS. Podobne umiejętności mają inne wyszukiwarki. Znacznie większym problemem jest poprawne używanie metatagów oraz stosowanie tzw. progressive enhancements, zalecanych przez Google. Obydwie kwestie są łatwiejsze do zaimplementowania w przypadku MPA.
Sytuacja z SEO wynika w dużej mierze z historii – SPA były najczęściej używane jako aplikacje biznesowe. W przypadku, gdy tworzymy aplikację narzędziową dla wybranej grupy użytkowników segmentu B2B, względy SEO nie mają praktycznie znaczenia. Aplikacja sama w sobie nie sprzedaje się przez Internet.
Do dziś firmy zachowują się bardzo zachowawczo. Ponieważ reguły SEO nie są przeważnie jednoznaczne, trudno wskazać przykłady firm, dla których Internet jest głównym źródłem dochodów i zaryzykowałyby pełne podejście typu SPA. Często spotykamy rozwiązanie, gdzie strony generują się klasycznie, a główna część strony oraz niektóre bloki, widgety, narzędzia doładowują się np. asynchronicznie.
Czas tworzenia – MPA vs SPA
Tempo tworzenia SPA i MPA będzie podobne. Na dzień dzisiejszy mamy gotowe rozwiązania pokroju Angular, React i Vue.js, zapewniające tworzenie strony SPA w zasadzie od ręki. W przypadku MPA wygląda to podobnie, bo mamy wiele gotowych silników/frameworków typu Django, Symfony, Yii.
W dużym skrócie, ilość pracy byłaby podobna, ale rozłożona w różnym stopniu pomiędzy back-end a front-end. Wydaje się więc, że wybór podejścia zależy też od kompetencji teamu tworzącego oprogramowanie oraz obszaru zastosowania tworzonego oprogramowania. Dwóch full-stack devów może rozwijać aplikację MPA tak samo szybko, jak para front-end i back-end dev aplikację SPA.
Scenariusze użycia MPA vs SPA
Istnieją pewne modelowe przypadki zastosowania obydwu typów stron:
Idealny scenariusz dla SPA:
Aplikacja typowo B2B, gdzie każda operacja wymaga wielu interakcji z użytkownikiem.
Idealny scenariusz dla MPA:
Serwis treściowy, na którym interakcja użytkownika jest niewielka, a istotna jest unikalność treści oraz pozycjonowanie w wyszukiwarkach.
Im więcej przeładowywania, doładowywania i prezentowania na różnych, zmieniających się dynamicznie widgetach, tym bardziej będzie się sprawdzać podejście SPA – do tego zostały stworzone rozwiązania dostępne na rynku. Natomiast gdy króluje treść i struktura, może być ciężko wykorzystać w pełni możliwości współczesnych frameworków. Wtedy MPA będzie z jednej strony szybsze do zaimplementowania, a z drugiej będzie bezpieczniejsze ze względu na SEO.
Podejście hybrydowe – łączące zalety MPA i SPA
Coraz częściej aplikacje webowe stają się hybrydami, których pewne elementy są renderowane na back-endzie, a inne na front-endzie. To rozwiązanie pozwala na wydobycie największych korzyści z obydwu rozwiązań, jednak zmusza programistów do radzenia sobie z problemami odziedziczonymi z obydwu podejść.
Wydaje się, że – pomimo najlepszego w historii dostępu do narzędzi – nadal bardzo dużo wysiłku kosztuje wykorzystanie wszystkich możliwości i ominięcie pułapek. Można wyobrazić sobie sytuację, w której mamy aplikację webową, gdzie logika jej front-endu składa widok z kilku źródeł danych, z których każde jest osobnym mikroserwisem/aplikacją back-endową, tworzoną przez osobne zespoły developerów.
Podsumowanie
Jak zawsze, wszystko zależy od tego, do czego dana strona/aplikacja będzie wykorzystywana. Oba rozwiązania posiadają duże zaplecze od strony technologicznej, są skomplikowane i wymagają dużego nakładu pracy, by wykorzystać je dobrze. Różnią się głównie zastosowaniami i odczuciami przy ich użytkowaniu.
Dziś świat idzie w kierunku rozwiązań aplikacyjnych i ograniczenia ilości przeładowań. Trudno jednak wskazać przykład znaczącego serwisu treściowego, dla którego najważniejsze jest pozyskanie ruchu z wyszukiwarek i opartego w całości na rozwiązaniach SPA. Wydaje się, że najlepsze efekty to połączenie zalet obydwu podejść – rozwiązanie hybrydowe, w którym części logiki są renderowane po stronie klienta, a części po stronie serwera.
