Aplikacja jednostronicowa
ponieważ SPA jest ewolucją od modelu bezstanowego przerysowywania stron, do którego pierwotnie zaprojektowano przeglądarki, pojawiły się nowe wyzwania. Możliwe rozwiązania (o różnej złożoności, kompleksowości i kontroli autora) obejmują:
- biblioteki JavaScript po stronie klienta.
- serwerowe frameworki www specjalizujące się w modelu SPA.
- ewolucja przeglądarek i specyfikacji HTML5, zaprojektowana dla modelu SPA.,
Search-engine optimizationEdit
ze względu na brak wykonywania JavaScript na crawlerach niektórych popularnych wyszukiwarek internetowych, SEO (ang. Search engine optimization) historycznie przedstawiało problem dla publicznych stron internetowych pragnących przyjąć model SPA.
W latach 2009-2015 Google Webmaster Central zaproponował, a następnie zalecił „schemat indeksowania AJAX” za pomocą początkowego wykrzyknika w identyfikatorach fragmentów dla stateful Ajax pages (#!)., Specjalne zachowanie musi być zaimplementowane przez witrynę SPA, aby umożliwić wydobycie odpowiednich metadanych przez gąsienicę Wyszukiwarki. W przypadku wyszukiwarek, które nie obsługują tego schematu skrótu URL, zahaszowane adresy URL SPA pozostają niewidoczne. Te Uri „hash-bang” zostały uznane za problematyczne przez wielu pisarzy, w tym Jeni Tennison z W3C, ponieważ sprawiają, że strony są niedostępne dla tych, którzy nie mają włączonego JavaScript w swojej przeglądarce. Łamią również nagłówki refererów HTTP, ponieważ przeglądarki nie mogą wysyłać identyfikatora fragmentu w nagłówku Referera., W 2015 roku Google wycofało swoją propozycję hash-bang AJAX crawling.
alternatywnie, aplikacje mogą renderować pierwsze ładowanie strony na serwerze, a kolejne aktualizacje strony na kliencie. Jest to tradycyjnie trudne, ponieważ kod renderujący może być napisany w innym języku lub frameworku na serwerze i w kliencie. Korzystanie z szablonów bez logiki, kompilowanie krzyżowe z jednego języka do drugiego lub używanie tego samego języka na serwerze i kliencie może pomóc zwiększyć ilość kodu, który może być udostępniony.,
w 2018 roku Google wprowadziło dynamiczne renderowanie jako kolejną opcję dla witryn, które chcą zaoferować crawlerom ciężką wersję strony do celów indeksowania bez JavaScript. Dynamiczne renderowanie przełącza się między wersją strony, która jest renderowana po stronie klienta, a wersją wstępnie renderowaną dla konkretnych agentów Użytkownika. Takie podejście polega na wykryciu przez serwer WWW robotów indeksujących (za pośrednictwem agenta użytkownika) i przekierowaniu ich do renderera, z którego są następnie serwowane w prostszej wersji zawartości HTML.,
ponieważ zgodność SEO nie jest trywialna w uzdrowiskach, warto zauważyć, że uzdrowiska nie są powszechnie stosowane w kontekście, w którym indeksowanie w wyszukiwarkach jest albo wymogiem, albo pożądanym. Przypadki użycia obejmują aplikacje, które ujawniają prywatne dane ukryte za systemem uwierzytelniania. W przypadkach, gdy te aplikacje są produktami konsumenckimi, często na stronie docelowej aplikacji i stronie marketingowej używany jest klasyczny model „przerysowania strony”, który zapewnia wystarczającą ilość metadanych, aby aplikacja pojawiła się jako hit w zapytaniu Wyszukiwarki., Blogi, fora wsparcia i inne tradycyjne artefakty przerysowywania stron często siedzą wokół SPA, które mogą zasiać Wyszukiwarki odpowiednimi terminami.
innym podejściem używanym przez serwerowe frameworki internetowe, takie jak Itsnat oparty na Javie, jest renderowanie dowolnego hipertekstu na serwerze przy użyciu tego samego języka i technologii szablonów. W tym podejściu serwer zna z precyzją stan DOM na kliencie, każda duża lub mała aktualizacja strony jest generowana na serwerze i transportowana przez Ajax, dokładny kod JavaScript, aby doprowadzić stronę Klienta do nowego stanu wykonującego metody DOM., Programiści mogą zdecydować, które Stany strony muszą być indeksowane przez pająki internetowe dla SEO i być w stanie wygenerować wymagany stan w czasie ładowania generując zwykły HTML zamiast JavaScript. W przypadku frameworka ItsNat jest to automatyczne, ponieważ ItsNat utrzymuje drzewo dom klienta na serwerze jako Drzewo Dom Java W3C; renderowanie tego drzewa DOM na serwerze generuje zwykły HTML w czasie ładowania i akcje JavaScript DOM dla żądań Ajax., Ta dualność jest bardzo ważna dla SEO, ponieważ programiści mogą budować z tym samym kodem Java i czystym szablonem HTML, tworząc żądany stan DOM na serwerze; w czasie ładowania strony konwencjonalny HTML jest generowany przez ItsNat, dzięki czemu ten stan dom jest zgodny z SEO.
od wersji 1.,3, ItsNat zapewnia nowy tryb bezstanowy, a Klient DOM nie jest utrzymywany na serwerze, ponieważ, z trybem bezstanowym klienta, stan DOM jest częściowo lub w pełni zrekonstruowany na serwerze podczas przetwarzania żądania Ajax na podstawie wymaganych danych wysłanych przez Klienta informującego serwer o bieżącym stanie DOM; tryb bezstanowy może być również zgodny z SEO, ponieważ zgodność SEO dzieje się w czasie ładowania strony początkowej bez wpływu trybów bezstanowych lub bezstanowych., Innym możliwym wyborem są frameworki takie jak PreRender, Puppeteer, Rendertron, które można łatwo zintegrować z dowolną witryną jako oprogramowanie pośredniczące z konfiguracją serwera www umożliwiającą obsługę żądań botów (Google bot i innych) przez oprogramowanie pośredniczące, podczas gdy żądania nie-botów są obsługiwane jak zwykle. Ramy te buforują okresowo odpowiednie strony internetowe, aby umożliwić wyszukiwarkom dostęp do najnowszych wersji. Te ramy zostały oficjalnie zatwierdzone przez google.
istnieje kilka obejść, które sprawiają, że wygląda to tak, jakby strona internetowa Była indeksowana., Oba obejmują tworzenie oddzielnych stron HTML, które odzwierciedlają zawartość SPA. Serwer może utworzyć wersję HTML strony i dostarczyć ją do robotów, lub możliwe jest użycie bezgłowej przeglądarki, takiej jak PhantomJS, aby uruchomić aplikację JavaScript i wydrukować wynikowy HTML.
oba te wymagają sporo wysiłku i mogą skończyć się bólem głowy podczas konserwacji dużych złożonych witryn. Istnieją również potencjalne pułapki SEO. Jeśli HTML wygenerowany przez serwer zostanie uznany za zbyt różny od treści SPA, witryna zostanie ukarana., Uruchamianie PhantomJS do wyjścia HTML może spowolnić szybkość reakcji stron, co jest czymś, dla czego wyszukiwarki – w szczególności Google-obniżają rankingi.
partycjonowanie kodu Klient/serweredytuj
jednym ze sposobów na zwiększenie ilości kodu, który może być współdzielony między serwerami i klientami, jest użycie języka szablonów bez logiki, takiego jak wąsy lub Kierownice. Takie szablony mogą być renderowane z różnych języków hosta, takich jak Ruby na serwerze i JavaScript w kliencie., Jednak samo udostępnianie szablonów zazwyczaj wymaga powielenia logiki biznesowej używanej do wyboru właściwych szablonów i wypełnienia ich danymi. Renderowanie z szablonów może mieć negatywny wpływ na wydajność przy aktualizowaniu tylko niewielkiej części strony—na przykład wartości tekstu wprowadzonego w dużym szablonie. Zastąpienie całego szablonu może również zakłócić wybór użytkownika lub pozycję kursora, podczas gdy aktualizacja tylko zmienionej wartości może nie być możliwa., Aby uniknąć tych problemów, aplikacje mogą używać powiązań danych interfejsu użytkownika lub granularnej manipulacji DOM do aktualizacji tylko odpowiednich części strony zamiast ponownego renderowania całych szablonów.
Historia Przeglądarkadytuj
z definicji „pojedyncza strona”, model przerywa projektowanie przeglądarki do nawigacji po historii stron za pomocą przycisków”do przodu „lub” do tyłu”., Przedstawia to utrudnienie użyteczności, gdy użytkownik naciska przycisk Wstecz, oczekując poprzedniego stanu ekranu w SPA, ale zamiast tego, aplikacja”s pojedyncza strona rozładowuje się i Poprzednia strona w historii przeglądarki jest prezentowana.
tradycyjnym rozwiązaniem dla SPAs jest zmiana identyfikatora fragmentu skrótu URL przeglądarki zgodnie z aktualnym stanem ekranu. Można to osiągnąć za pomocą JavaScript i powoduje, że zdarzenia historii adresów URL są budowane w przeglądarce., Dopóki SPA jest w stanie przywrócić ten sam stan ekranu z informacji zawartych w haszu adresu URL, oczekiwane zachowanie przycisku wstecz jest zachowywane.
aby rozwiązać ten problem, Specyfikacja HTML5 wprowadziła pushState i replaceState zapewniające programowy dostęp do rzeczywistego adresu URL i historii przeglądarki.
AnalyticsEdit
narzędzia analityczne, takie jak Google Analytics, polegają w dużym stopniu na ładowaniu całych nowych stron w przeglądarce, inicjowanym przez nowe ładowanie strony. Uzdrowiska nie działają w ten sposób.,
po pierwszym załadowaniu strony wszystkie kolejne zmiany strony i treści są obsługiwane wewnętrznie przez aplikację, która powinna po prostu wywołać funkcję aktualizacji pakietu analitycznego. Nie wywołując wspomnianej funkcji, przeglądarka nigdy nie uruchamia nowego ładowania strony, nic nie jest dodawane do historii przeglądarki, a pakiet analityczny nie ma pojęcia, kto robi co na stronie.
dodawanie ładowań stron do SPAEdit
możliwe jest dodawanie zdarzeń ładowania stron do SPA za pomocą HTML5 history API; pomoże to zintegrować analitykę., Trudność polega na zarządzaniu tym i zapewnieniu, że wszystko jest dokładnie śledzone – obejmuje to sprawdzanie brakujących raportów i podwójnych wpisów.Niektóre struktury zapewniają integracje analityczne typu open source adresujące większość głównych dostawców usług analitycznych. Programiści mogą zintegrować je z aplikacją i upewnić się, że wszystko działa poprawnie, ale nie ma potrzeby robienia wszystkiego od zera.
prędkość początkowego ładowaniaedit
Aplikacje jednostronicowe mają wolniejsze ładowanie pierwszej strony niż aplikacje serwerowe., Dzieje się tak, ponieważ pierwsze obciążenie musi obniżyć framework i Kod aplikacji przed renderowaniem wymaganego widoku jako HTML w przeglądarce. Aplikacja oparta na serwerze musi po prostu wypchnąć wymagany HTML do przeglądarki, zmniejszając opóźnienie i czas pobierania.
przyspieszenie strony loadEdit
istnieje kilka sposobów na przyspieszenie początkowego ładowania SPA, takich jak ciężkie podejście do buforowania i leniwe Ładowanie modułów w razie potrzeby., Ale nie jest możliwe, aby uciec od faktu, że musi pobrać framework, przynajmniej część kodu aplikacji, i najprawdopodobniej trafi API dla danych przed wyświetlaniem czegoś w przeglądarce. To jest” Zapłać mi teraz, albo zapłać mi później ” scenariusz kompromisu. Kwestia wydajności i czasu oczekiwania pozostaje decyzją, którą musi podjąć deweloper.