Aplicație cu o singură pagină

0 Comments

deoarece SPA – ul este o evoluție departe de modelul apatrid page-redraw pentru care browserele au fost proiectate inițial, au apărut unele noi provocări. Solutii posibile (de complexitate diferite, comprehensiveness, și de control autor) includ:

  • biblioteci JavaScript Client-side.
  • cadre web din partea serverului care se specializează în modelul SPA.
  • evoluția browserelor și specificațiile HTML5, concepute pentru modelul SPA.,

Căutare-motor optimizationEdit

din Cauza lipsei de execuție JavaScript pe crawlerele de unele populare motoare de căutare Web, SEO (Search engine optimization), istoric, a prezentat o problemă pentru public cu care se confruntă site-uri care doresc să adopte SPA model.între 2009 și 2015, Google Webmaster Central a propus și apoi a recomandat o „schemă de crawling AJAX” folosind un semn de exclamare inițial în identificatorii de fragmente pentru paginile AJAX stateful (#!)., Un comportament Special trebuie implementat de site-ul SPA pentru a permite extragerea metadatelor relevante de către crawlerul motorului de căutare. Pentru motoarele de căutare care nu acceptă această schemă de hash URL, adresele URL hash ale SPA rămân invizibile. Aceste URI-uri” hash-bang ” au fost considerate problematice de un număr de scriitori, inclusiv Jeni Tennison la W3C, deoarece fac pagini inaccesibile celor care nu au JavaScript activat în browserul lor. De asemenea, rup anteturile REFERITORULUI HTTP, deoarece browserele nu au voie să trimită identificatorul de fragment în antetul Refererului., În 2015, Google și-a depreciat propunerea de crawling AJAX hash-bang.în mod alternativ, aplicațiile pot face încărcarea primei pagini pe server și actualizările ulterioare ale paginii pe client. Acest lucru este în mod tradițional dificil, deoarece codul de redare ar putea fi necesar să fie scris într-o altă limbă sau cadru pe server și în client. Utilizarea șabloanelor fără logică, compilarea încrucișată dintr-o limbă în alta sau utilizarea aceleiași limbi pe server și pe client poate contribui la creșterea cantității de cod care poate fi partajat.,în 2018, Google a introdus redarea dinamică ca o altă opțiune pentru site-urile care doresc să ofere crawlerelor o versiune non-JavaScript grea a unei pagini în scopuri de indexare. Redarea dinamică comută între o versiune a unei pagini care este randată pe partea clientului și o versiune pre-randată pentru anumiți agenți utilizator. Această abordare implică serverul dvs. web detectarea crawler-urilor (prin intermediul agentului utilizator) și rutarea acestora către un renderer, din care sunt apoi servite o versiune mai simplă a conținutului HTML.,deoarece compatibilitatea SEO nu este banală în spa-uri, este de remarcat faptul că spa-urile nu sunt utilizate în mod obișnuit într-un context în care indexarea motorului de căutare este fie o cerință, fie de dorit. Cazurile de utilizare includ aplicații care afișează date private ascunse în spatele unui sistem de autentificare. În cazurile în care aceste aplicații sunt produse de consum, adesea se utilizează un model clasic de „redesenare a paginii” pentru pagina de destinație și site-ul de marketing al aplicațiilor, care oferă suficiente meta-date pentru ca aplicația să apară ca un hit într-o interogare a motorului de căutare., Blogurile, forumurile de asistență și alte artefacte tradiționale de redesenare a paginilor stau adesea în jurul SPA-ului care pot sămânța motoarele de căutare cu termeni relevanți.

o altă abordare folosită de cadrele web centrate pe server, cum ar fi ItsNat-ul bazat pe Java, este de a reda orice hipertext pe server folosind aceeași limbă și tehnologie de templare. În această abordare, serverul cunoaște cu precizie starea DOM pe client, orice actualizare de pagină mare sau mică necesară este generată în server și transportată de Ajax, codul JavaScript exact pentru a aduce pagina clientului la noua stare de executare a metodelor DOM., Dezvoltatorii pot decide care stări de pagină trebuie să fie crawlable de păianjeni web pentru SEO și să fie capabil de a genera starea necesară la momentul de încărcare generatoare HTML simplu în loc de JavaScript. În cazul cadrului ItsNat, acest lucru este automat, deoarece ItsNat păstrează arborele DOM client în server ca un copac Java W3C DOM; redarea acestui arbore DOM în server generează HTML simplu la momentul încărcării și acțiuni JavaScript DOM pentru cererile Ajax., Această dualitate este foarte importantă pentru SEO, deoarece dezvoltatorii pot construi cu același cod Java și templating pur bazat pe HTML starea DOM dorită în server; la timpul de încărcare a paginii, html convențional este generat de ItsNat făcând acest stat Dom compatibil SEO.

începând cu versiunea 1.,3, ItsNat oferă o nouă apatrid modul, iar clientul DOM nu este ținut pe server deoarece, cu apatrizi modul client, DOM stat este parțial sau complet reconstruit pe server atunci când prelucrarea orice cerere Ajax bazate pe date necesare trimis de catre client informarea server de curent DOM stat; apatrid modul poate fi, de asemenea, SEO-compatibil pentru SEO compatibilitate se întâmplă la timpul de încărcare a paginii inițiale neafectat de statefull sau apatrid moduri., O altă variantă posibilă este de cadre, cum ar fi redați în avans, Păpușar, Rendertron care poate fi ușor integrat în orice site web ca un middleware cu configurație de server web care să permită bot cereri (google bot și altele) să fie deservite de middleware în timp ce non-bot cererile sunt servite ca de obicei. Aceste cadre cache paginile relevante site-ul periodic pentru a permite cele mai recente versiuni să fie disponibile pentru motoarele de căutare. Aceste cadre au fost aprobate oficial de google.

există câteva soluții pentru a face să pară că site-ul web poate fi accesat cu crawlere., Ambele implică crearea de pagini HTML separate care reflectă conținutul SPA-ului. Serverul ar putea crea o versiune bazată pe HTML a site-ului și o poate livra crawlerelor sau este posibil să folosiți un browser fără cap, cum ar fi PhantomJS, pentru a rula aplicația JavaScript și a afișa HTML-ul rezultat.ambele necesită destul de un pic de efort, și poate sfârși prin a da o durere de cap de întreținere pentru site-uri complexe mari. Există, de asemenea, potențiale capcane SEO. Dacă HTML generat de server este considerat a fi prea diferit de conținutul SPA, atunci site-ul va fi penalizat., Rularea PhantomJS pentru a scoate HTML – ul poate încetini viteza de răspuns a paginilor, ceea ce este ceva pentru care motoarele de căutare – în special Google-downgrade clasamentul.

Client/server cod partitioningEdit

O modalitate de a crește cantitatea de cod care pot fi partajate între servere și clienți este de a utiliza o logica-mai puțin șablon de limbaj cum ar fi Mustata sau Ghidon. Astfel de șabloane pot fi redate din diferite limbi gazdă, cum ar fi Ruby pe server și JavaScript în client., Cu toate acestea, simpla partajare a șabloanelor necesită de obicei duplicarea logicii de afaceri utilizate pentru a alege șabloanele corecte și a le popula cu date. Redarea din șabloane poate avea efecte negative de performanță atunci când actualizați doar o mică parte a paginii—cum ar fi valoarea unei intrări de text într-un șablon mare. Înlocuirea unui întreg șablon ar putea perturba, de asemenea, selecția unui utilizator sau poziția cursorului, în cazul în care actualizarea numai valoarea modificată s-ar putea să nu., Pentru a evita aceste probleme, aplicațiile pot utiliza legăturile de date UI sau manipularea granulară DOM pentru a actualiza doar părțile corespunzătoare ale paginii în loc să redea șabloane întregi.cu un SPA fiind, prin definiție, „o singură pagină”, modelul sparge designul browserului pentru navigarea în istoricul paginilor folosind butoanele”Înainte „sau” înapoi”., Aceasta prezintă un impediment de utilizare atunci când un utilizator apasă butonul din spate, așteptând starea anterioară a ecranului în SPA, dar în schimb, este prezentată pagina unică a aplicației și pagina anterioară din istoricul browserului.

soluția tradițională pentru spa-uri a fost schimbarea identificatorului fragmentului hash al URL-ului browserului în acord cu starea curentă a ecranului. Acest lucru poate fi realizat cu JavaScript și determină construirea evenimentelor din istoricul URL-urilor în browser., Atâta timp cât SPA-ul este capabil să reînvie aceeași stare a ecranului din informațiile conținute în hash-ul URL, comportamentul așteptat al butonului din spate este păstrat.

pentru a aborda în continuare această problemă, specificația HTML5 a introdus pushState și replaceState oferind acces programatic la URL-ul real și istoricul browser-ului.

AnalyticsEdit

instrumentele de analiză, cum ar fi Google Analytics, se bazează foarte mult pe încărcarea de pagini întregi noi în browser, inițiată de o nouă încărcare a paginii. Spa-urile nu funcționează în acest fel.,după încărcarea primei pagini, toate modificările ulterioare ale paginii și conținutului sunt gestionate intern de aplicație, care ar trebui să apeleze pur și simplu la o funcție pentru a actualiza pachetul analytics. Dacă nu apelați funcția menționată, browserul nu declanșează niciodată o nouă încărcare a paginii, nimic nu este adăugat la istoricul browserului, iar pachetul analytics nu are nicio idee cine face ce pe site.

adăugarea încărcărilor de pagină la un SPAEdit

este posibil să adăugați evenimente de încărcare a paginii la un SPA folosind API-ul istoric HTML5; acest lucru va ajuta la integrarea analizelor., Dificultatea vine în gestionarea acestui lucru și asigurarea faptului că totul este urmărit cu exactitate – aceasta implică verificarea rapoartelor lipsă și a înregistrărilor duble.Unele cadre oferă integrări de analiză open source care se adresează majorității furnizorilor majori de analize. Dezvoltatorii le pot integra în aplicație și se pot asigura că totul funcționează corect, dar nu este nevoie să faceți totul de la zero.

viteza încărcării inițialedit

aplicațiile cu o singură pagină au o încărcare mai lentă a primei pagini decât aplicațiile bazate pe server., Acest lucru se datorează faptului că prima încărcare trebuie să reducă cadrul și codul aplicației înainte de a reda vizualizarea necesară ca HTML în browser. O aplicație bazată pe server trebuie doar să împingă HTML-ul necesar în browser, reducând latența și timpul de descărcare.există câteva modalități de a accelera încărcarea inițială a unui SPA, cum ar fi o abordare grea a modulelor de cache și de încărcare leneșă atunci când este necesar., Dar nu este posibil să scăpați de faptul că trebuie să descărcați cadrul, cel puțin o parte din codul aplicației și, cel mai probabil, va lovi un API pentru date înainte de a afișa ceva în browser. Acesta este un scenariu de compromis „plătește-mă acum sau plătește-mă mai târziu”. Problema performanței și a timpului de așteptare rămâne o decizie pe care dezvoltatorul trebuie să o ia.


Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *