Czy jest pushStateźle, jeśli potrzebujesz wyszukiwarek do czytania treści?
Nie, rozmowa dotyczy pushStatewykonania tego samego ogólnego procesu z hashbangami, ale z lepiej wyglądającymi adresami URL. Pomyśl o tym, co naprawdę się dzieje, gdy używasz haszowania ...
Mówisz:
Dzięki hashbangom Google wie, jak przejść do adresu URL escaped_fragment, aby pobrać ich statyczną zawartość.
Innymi słowy,
- Google widzi link do
example.com/#!/blog
- Prośby Google
example.com/?_escaped_fragment_=/blog
- Ci powrócić zrzut zawartości użytkownik powinien zobaczyć
Jak widać, już polega na serwerze. Jeśli nie udostępniasz migawki zawartości z serwera, oznacza to, że witryna nie jest poprawnie indeksowana.
Jak więc Google zobaczy cokolwiek z pushState?
Dzięki pushState Google po prostu nic nie widzi, ponieważ nie może użyć javascript do załadowania json, a następnie utworzenia szablonu.
Właściwie Google zobaczy wszystko, o co poprosi, pod adresem site.com/blog. Adres URL nadal wskazuje na zasób na serwerze, a klienci nadal przestrzegają tej umowy. Oczywiście dla współczesnych klientów Javascript otworzył nowe możliwości pobierania i interakcji z treścią bez odświeżania strony , ale umowy są takie same.
Tak więc zamierzona elegancja pushStatepolega na tym, że udostępnia te same treści wszystkim użytkownikom, starym i nowym, obsługującym JS i nie, ale nowi użytkownicy uzyskują lepsze wrażenia .
Jak sprawić, by Google zobaczyło Twoje treści?
Podejście Facebooka - serwuj te same treści pod adresem URL, w site.com/blogktóry Twoja aplikacja kliencka przekształci się, gdy przejdziesz /blogdo stanu. (Facebook pushStatejeszcze nie używa , o których wiem, ale robią to z haszami)
Podejście Twittera - przekierowuj wszystkie przychodzące adresy URL do odpowiednika hashbang. Innymi słowy, odsyłacz do „/ blog” jest przekazywany /blogdo stanu. Ale jeśli zażądano bezpośrednio, przeglądarka kończy się na #!/blog. (W przypadku Googlebota przekierowanie to będzie _escaped_fragment_zgodne z oczekiwaniami. W przypadku innych klientów możesz pushStatewrócić do ładnego adresu URL).
Więc czy tracisz _escaped_fragment_zdolność pushState?
Powiedziałeś w kilku różnych komentarzach
uciekający fragment jest zupełnie inny. Możesz wyświetlać czystą zawartość bez motywu, zawartość z pamięci podręcznej i nie dać się obciążać, jak zwykłe strony.
Idealnym rozwiązaniem dla Google jest wykonanie witryn JavaScript lub zaimplementowanie w pewien sposób informacji o adresie URL fragmentu ze zmianą znaczenia nawet w przypadku witryn pushstate (robots.txt?).
Korzyści, o których wspomniałeś, nie są odosobnione _escaped_fragment_. To, że robi to za Ciebie i używa specjalnie nazwanego GETparametru, jest naprawdę szczegółem implementacji. Nie ma nic szczególnego o tym, że nie można zrobić ze standardowych adresów URL - innymi słowy, przepisać /blogdo /?content=/blogna własnym wykorzystaniem mod_rewrite lub odpowiednik serwera.
A jeśli w ogóle nie udostępniasz treści po stronie serwera?
Jeśli nie możesz przepisać adresów URL i udostępniać jakiejś treści w /blog(lub w jakimkolwiek stanie, w którym umieściłeś w przeglądarce), oznacza to, że twój serwer naprawdę nie przestrzega już kontraktu HTTP.
Jest to ważne, ponieważ ponowne załadowanie strony (z dowolnego powodu) spowoduje pobranie zawartości z tego adresu URL. (Zobacz https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review - „view-source i reload pobiorą zawartość pod nowym identyfikatorem URI, jeśli został on przekazany”).
Nie chodzi o to, że rysowanie interfejsów użytkownika raz po stronie klienta i ładowanie treści za pośrednictwem interfejsów API JS jest złym celem, po prostu nie jest to tak naprawdę uwzględniane przez HTTP i adresy URL i w zasadzie nie jest kompatybilne wstecz.
W tej chwili jest to dokładnie to, do czego służą hashbangi - do reprezentowania odrębnych stanów strony, po których nawiguje się po kliencie, a nie na serwerze. Na przykład przeładowanie spowoduje załadowanie tego samego zasobu, który może następnie odczytać, przeanalizować i przetworzyć zaszyfrowaną wartość.
Tak się składa, że były one również wykorzystywane (zwłaszcza przez Facebooka i Twittera) do zmiany historii na lokalizację po stronie serwera bez odświeżania strony. To właśnie w tych przypadkach użycia ludzie zalecają rezygnację z haszowania dla pushState.
Jeśli renderujesz całą zawartość po stronie klienta, powinieneś pomyśleć o tym pushStatejako o części wygodniejszego interfejsu API historii, a nie o sposobie rezygnacji z używania skrótów.