Egyoldalas alkalmazás
mivel a SPA egy evolúció távol a hontalan oldal-redraw modell böngészők eredetileg tervezték, néhány új kihívások merültek fel. A lehetséges megoldások (különböző összetettségű, átfogó és szerzői kontroll) a következők:
- kliens oldali JavaScript könyvtárak.
- szerver oldali webes keretrendszerek, amelyek a SPA modellre szakosodtak.
- a böngészők fejlődése és a HTML5 specifikáció, melyet a SPA modellhez terveztek.,
Keresés-motor optimizationEdit
hiánya Miatt a JavaScript-végrehajtás a robotjai néhány népszerű Webes keresők, SEO (Search engine optimization) történelmileg bemutatott probléma nyilvános néző weboldalak, akik elfogadják a GYÓGYFÜRDŐ modell.
2009 és 2015 között a Google Webmaster Central egy “AJAX feltérképezési sémát” javasolt, majd egy kezdeti felkiáltójelet javasolt a stateful AJAX oldalak töredékazonosítóiban (#!)., Különleges viselkedést kell végrehajtani a SPA helyszínen, hogy a kitermelés a vonatkozó metaadatok a keresőmotor lánctalpas. Azok a keresőmotorok, amelyek nem támogatják ezt az URL-hash sémát, a SPA kivonatolt URL-címei láthatatlanok maradnak. Ezeket a” hash-bang ” Uri-kat számos író, köztük Jeni Tennison is problémásnak tartotta a W3C-n, mert az oldalakat elérhetetlenné teszik azok számára, akiknek nincs JavaScript aktiválva a böngészőjükben. Megszakítják a HTTP hivatkozó fejléceket is, mivel a böngészők nem küldhetik el a töredék azonosítót a hivatkozó fejlécében., 2015 – ben a Google leértékelte a hash-bang AJAX feltérképezési javaslatát.
Alternatív megoldásként az alkalmazások megjeleníthetik az első oldal betöltését a kiszolgálón, majd az ügyfél későbbi oldalfrissítéseit. Ez hagyományosan nehéz feladat, mert előfordulhat, hogy a renderelőkódot más nyelven vagy keretrendszeren kell írni a szerveren és a kliensen. Logikai sablonok használata, keresztfordítás egyik nyelvről a másikra, vagy ugyanazon nyelv használata a kiszolgálón, az ügyfél pedig hozzájárulhat a megosztható kód mennyiségének növeléséhez.,
2018-Ban, a Google bemutatta a dinamikus renderelés, mint egy másik lehetőség, a helyek kíván ajánlatot robotjai nem JavaScript nehéz változata oldal indexelés szempontjából. A dinamikus renderelés az oldal kliensoldali verziója és az adott felhasználói ágensek előrendelt verziója között vált át. Ez a megközelítés magában foglalja a webszerver feltérképező robotjait (a felhasználói ügynöken keresztül), majd átirányítja őket egy megjelenítőhöz, ahonnan a HTML-tartalom egyszerűbb verzióját szolgálják fel.,
mivel a SEO kompatibilitás nem triviális a gyógyfürdőkben, érdemes megjegyezni, hogy a gyógyfürdőket általában nem használják olyan környezetben, ahol a keresőmotor indexelése követelmény vagy kívánatos. A használati esetek közé tartoznak azok az alkalmazások, amelyek a hitelesítési rendszer mögött rejtett személyes adatokat fedik fel. Azokban az esetekben, amikor ezek az alkalmazások fogyasztói termékek, gyakran egy klasszikus “page redraw” modellt használnak az alkalmazások céloldalára és marketing webhelyére, amely elegendő meta-adatot biztosít ahhoz, hogy az alkalmazás találatként jelenjen meg a keresőmotor lekérdezésében., Blogok, támogató fórumok, és más hagyományos oldal újrarajzolása leletek gyakran ülnek a fürdő, amely vetőmag keresőmotorok releváns kifejezéseket.
a Szerverközpontú webes keretrendszerek, például a Java alapú ItsNat által alkalmazott másik megközelítés az, hogy a kiszolgálón bármilyen hipertext megjelenjen ugyanazon a nyelven és sablontechnológiával. Ebben a megközelítésben a szerver pontosan ismeri a kliens Dom állapotát, a kiszolgálón minden nagy vagy kis oldalfrissítés szükséges, az Ajax szállítja, a pontos JavaScript kódot, hogy az ügyféloldalt az új Dom metódusokhoz vezesse., A fejlesztők eldönthetik, hogy a webes pókok által a SEO számára melyik oldalállapotot kell feltérképezni, és képesek lesznek a betöltési idő alatt generálni a szükséges állapotot, sima HTML-t generálva a JavaScript helyett. Az ItsNat keretrendszer esetében ez automatikus, mivel az ItsNat a kliens Dom fát Java W3C DOM faként tartja a kiszolgálón; ennek a DOM fának a renderelése a kiszolgálón egyszerű HTML-t generál betöltési időben, valamint JavaScript Dom műveleteket az Ajax kérésekhez., Ez a kettősség nagyon fontos a SEO, mert a fejlesztők építeni ugyanazzal a Java kódot, majd tiszta HTML-alapú templating a kívánt DOM állam server; a oldal betöltési ideje, hagyományos HTML által generált ItsNat, hogy ez a DOM állami SEO-kompatibilis.
az 1. verziótól kezdve.,3, ItsNat egy új hontalan mód, és a kliens DOM nem tartják a szerveren, mert, a hontalan mód kliens, DOM állapot részben vagy teljesen rekonstruált a szerveren, amikor a feldolgozás minden Ajax kérés alapján szükséges adatokat küldött az ügyfél tájékoztatja a szerver a jelenlegi Dom állapot; a hontalan mód is SEO-kompatibilis, mert SEO kompatibilitás történik betöltési idő az eredeti oldal érintetlenül hontalan vagy hontalan mód., Egy másik lehetséges választás keretrendszerek, mint PreRender, Bábos, Rendertron, amely könnyen integrálható bármilyen weboldal, mint a vásárló a web szerver konfiguráció lehetővé teszi bot kérelmeket (a google bot, s mások), hogy szolgálja az a vásárló, míg a nem-bot kérések szolgált, mint mindig. Ezek a keretek rendszeresen gyorsítótárazzák a megfelelő webhelyoldalakat, hogy a legújabb verziók elérhetők legyenek a keresőmotorok számára. Ezeket a kereteket a google hivatalosan jóváhagyta.
van néhány megoldás, hogy úgy nézzen ki, mintha a webhely bejárható lenne., Mindkettő magában foglalja külön HTML oldalak létrehozását, amelyek tükrözik a SPA tartalmát. A szerver létrehozhat egy HTML-alapú változata a helyszínen, és szállít, hogy a crawlers, vagy lehetséges, hogy egy fej nélküli böngésző, mint PhantomJS futtatni a JavaScript alkalmazást, majd a kimenet a kapott HTML.
mindkét nem igényel egy kis erőfeszítést, és a végén így a karbantartási fejfájás a nagy komplex oldalak. Vannak potenciális SEO buktatók is. Ha a szerver által generált HTML túlságosan eltér a SPA tartalomtól, akkor a webhelyet büntetik., A PhantomJS futtatása a HTML megjelenítéséhez lelassíthatja az oldalak válaszsebességét, amelyre a keresőmotorok – különösen a Google – csökkentik a rangsorolást.
Client / server code partitioningEdit
A kiszolgálók és az ügyfelek között megosztható kód mennyiségének növelésének egyik módja egy logic-less template nyelv használata, mint például a bajusz vagy a kormány. Az ilyen sablonok különböző host nyelvekről is megjeleníthetők, mint például a Ruby a szerveren vagy a JavaScript az ügyfélben., A sablonok egyszerű megosztása azonban általában megkettőzi a megfelelő sablonok kiválasztásához használt üzleti logikát, és adatokkal tölti fel őket. A sablonokból történő megjelenítés negatív teljesítményhatásokkal járhat, ha csak az oldal egy kis részét frissíti-például egy nagy sablonon belüli szövegbevitel értékét. A teljes sablon cseréje zavarhatja a felhasználó kijelölését vagy kurzor pozícióját is, ahol előfordulhat, hogy csak a módosított érték frissítése nem történik meg., E problémák elkerülése érdekében az alkalmazások UI adatkötéseket vagy szemcsés DOM manipulációt használhatnak az oldal megfelelő részeinek frissítéséhez, ahelyett, hogy teljes sablonokat újra megjelenítenének.
Browser historyEdit
a SPA, hogy, definíció szerint, “egy oldal”, a modell megtöri a böngésző tervezési oldalelőzmények navigáció segítségével a “előre” vagy “vissza” gombokat., Ez bemutatja a használhatóság akadálya, ha a felhasználó megnyomja a vissza gombot, várja az előző képernyőre állami belül a FÜRDŐ, de ehelyett az alkalmazás”s egyetlen oldal kiüríti, valamint az előző oldalra a böngésző”s a történelem mutatja be.
a hagyományos megoldás gyógyfürdők az volt, hogy módosítsa a böngésző URL hash fragmentum azonosítója összhangban az aktuális képernyő állapotát. Ez a JavaScript használatával érhető el, ami URL előzmények eseményeit hozza létre a böngészőben., Mindaddig, amíg a SPA képes feltámasztani ugyanazt a képernyő állapotát szereplő információk az URL hash, a várható back-gomb viselkedés megmarad.
a probléma további kezelése érdekében a HTML5 specifikáció bevezette a pushState-t és a replaceState-t, amely programozott hozzáférést biztosít a tényleges URL-hez és a böngésző előzményeihez.
AnalyticsEdit
az olyan elemző eszközök, mint a Google Analytics, nagymértékben támaszkodnak a teljes új oldalak betöltésére a böngészőben, amelyet egy új oldalterhelés kezdeményez. A gyógyfürdők nem így működnek.,
az első oldal betöltése után az összes későbbi oldal-és tartalomváltozást belsőleg kezeli az alkalmazás, amelynek egyszerűen egy funkciót kell hívnia az elemzési csomag frissítéséhez. Ha nem hívja az említett funkciót, a böngésző soha nem indít új oldalterhelést, semmi nem kerül hozzáadásra a böngésző előzményeihez, az analytics csomagnak fogalma sincs, ki mit csinál az oldalon.
oldalterhelések hozzáadása egy SPAEdit
lehetőség van oldalbetöltési események hozzáadására egy SPA-hoz a HTML5 history API használatával; ez segít az analytics integrálásában., Ennek kezelése és annak biztosítása, hogy mindent pontosan nyomon kövessenek – ez magában foglalja a hiányzó jelentések és a kettős bejegyzések ellenőrzését.Egyes keretek nyílt forráskódú elemzési integrációkat biztosítanak, amelyek a legtöbb fő elemzési szolgáltatót érintik. A fejlesztők integrálhatják őket az alkalmazásba, és gondoskodhatnak arról, hogy minden megfelelően működjön, de nem kell mindent a semmiből megtenni.
A kezdeti betöltés Sebességeszerkesztés
az egyoldalas Alkalmazások lassabb első oldalterheléssel rendelkeznek, mint a szerver alapú alkalmazások., Ez azért van, mert az első terhelésnek le kell állítania a keretrendszert és az alkalmazáskódot, mielőtt a szükséges nézetet HTML-ként megjelenítené a böngészőben. Egy szerver alapú alkalmazásnak csak ki kell nyomnia a szükséges HTML-t a böngészőbe, csökkentve a késleltetést és a letöltési időt.
az oldal betöltésének Felgyorsításaszerkesztés
van néhány módja annak, hogy felgyorsítsuk a gyógyfürdő kezdeti terhelését, például a gyorsítótárazás nehéz megközelítése vagy a lusta betöltő modulok szükség esetén., De ez nem lehetséges, hogy távol az a tény, hogy le kell töltenie a keretrendszert, legalább néhány alkalmazás kód, és valószínűleg megüt egy API adatokat megjelenítés előtt valamit a böngészőben. Ez egy “fizess most, vagy fizess később” kompromisszum forgatókönyv. A teljesítmény és a várakozási idő kérdése továbbra is olyan döntés, amelyet a fejlesztőnek meg kell tennie.