A szupergyors és biztonságos weboldal felépítése CMS-sel nem nagy ügy. Vagy ez?

Megtörhetem a webhelyét? Van ott megmaradt szkriptje, amelyet kihasználhatok? Van-e mód arra, hogy ellopja a hitelesítő adatait és megváltoztassa a webhely tartalmát? Hozzáférhetek privát információkhoz? Nem? biztos vagy ebben? Vagy soha nem fogom megtudni, mert az oldalad korokba telik?

Egy webhely létrehozásakor el kell gondolkodnia a teljesítményen és a biztonságon. Nem számít, hogy a személyes webhelyén dolgozik, vagy az ügyfél webhelyén. Ez megegyezik a helyi fájlok biztonsági mentésével. Van, aki rendszeresen készít biztonsági másolatot, és olyan ember, aki még nem veszítette el, ezért kevésbé hajlandó erre.

Hagyományos CMS

Ha hagyományos tartalomkezelő rendszert (CMS) használ, akkor a helyzet bonyolultabb az Ön számára. Ezek a rendszerek rengeteg funkciót tartalmaznak. Fel kell tüntetniük a webhely bármely lehetséges felhasználási esetét. Ez kódot jelent. Sok kód. Több ezer fájl. És ez még nem minden - az adminisztrációs interfészeknek szép felhasználói felületet kell biztosítaniuk, hogy konfigurálhassák ezeket a szolgáltatásokat. Potenciálisan további néhány ezer fájl.

Biztonság

Ez nem a te kódod, igaz? Tehát már biztosnak kell lennie. Nos, sok CMS-gyártó mindent megtesz annak érdekében, hogy megvalósításuk biztonságos legyen. Még mindig sok fájlt kell lefedniük. És minden egyes fájl tartalmazhat hibát, valamilyen hátrahagyott kódot, vagy egy lekérdezési karakterlánc-paramétert, amely adatbázisot tár fel. Ez önmagában potenciális sebezhetőséget okozhat.

A nyílt forráskódú CMS használata még veszélyesebb lehet, mivel a megvalósítás nyilvánosan ismert. Igen, azt állíthatja, hogy a nyílt forráskód előnyös. Bárki hozzájárulhat és megoldhatja a talált problémákat. De ez csak a már ismert kérdéseket fedi le. A támadók valószínűleg magukra tartanák kihasználásaikat. Még akkor is, ha problémát találtak és kijavítottak, akkor is nagy erőfeszítéseket kell tennie annak érdekében, hogy webhelye naprakész legyen. Minden frissítést végre kell hajtania, amikor egy biztonsági gyorsjavítást kiadnak.

Ha érdekli a valós statisztikák, nézze meg Sucuri feltört webhelyjelentését.

Szóval mit akarnak tenni a támadók az Ön weboldalával? Lényegében meg akarják szerezni az Ön adatait, így visszaélhetnek a webhelyével:

  • Hozzáférés az adatbázisához az egyik szkript segítségével. Ez általában az egyedi megmaradt szkriptek, tesztelő oldalak és mások esetében fordul elő.
  • Titkos adatainak megsértése és visszaélése. A konfigurációs fájlok a különböző titkos kulcsok és más szolgáltatások vagy adatbázisok hitelesítő adatainak tipikus tárolási lehetőségei.
  • A webhely tartalmának módosítása.
  • A weboldal elérhetetlenné tétele, azaz bezárása.

Teljesítmény

Amikor webhelyét hagyományos CMS-re telepíti, általában testre kell szabnia, így vannak a CMS és az Ön egyéni fájljai. Mindegyiket össze kell állítani, majd az előre lefordított könyvtárakkal együtt fel kell vinni a kiszolgáló memóriájába, mielőtt a szerver ténylegesen megkezdheti a kérelmek feldolgozását a webhelyére. Vagy ami még rosszabb, ha olyan értelmezésen alapuló megoldást használ, mint a PHP, értelmezze minden kéréshez az összes kódot.

Egyébként úgy tűnik, hogy a weboldala rendben működik, akkor miért kell ez aggályosnak lennie? Nos, mert:

  • fizet a szerver számítási teljesítményéért
  • olyan funkciók kódját állítja össze és másolja, amelyeket soha nem kíván használni
  • webhelye látogatói megvárják a választ

A webhelyek első byte-jának ideje 1 másodpercnél hosszabb lehet. Persze, optimalizálható, de akkor időt és pénzt fordít arra, hogy kitalálja, hogyan lehet enyhíteni a teljesítményproblémákat, és általában növeli a CPU-t és a memóriát, vagy ami még rosszabb, ha további szervert ad hozzá.

Ellenőrizze webhelyét a Google PageSpeed ​​használatával, vagy részletesebb elemzéseket végezhet a SpeedCurve segítségével, hogy megtudja, hogyan áll a webhelye.

API-alapú webhelyek

Az API tetejére épített webhelyek nagy rugalmasságot tesznek lehetővé. Kérdezd meg magadtól, szükséged van-e tartalomkezelésre? Ha igen, használhat fej nélküli CMS-t. Tárolnia kell az űrlap beküldéseket? Tökéletes, használjon űrlap szolgáltatást. Honlapot épít a hegyi szállodák számára, és időjárás-előrejelzést szeretne megjeleníteni? Van egy időjárási szolgáltatás az API-val az Ön számára.

Az ilyen weboldalakhoz használt fájlok száma megfelel annak funkcionalitásának. De mi a helyzet a tartalomszerkesztéshez szükséges adminisztrációs felülettel? Ne aggódj. A fej nélküli CMS kezeli ezt a részt az Ön számára, nem szükséges további kódot tárolnia vagy fenntartania.

Biztonság

API-szolgáltatások használatakor nincs szüksége adminisztrációs szolgáltatásra a webhely tetején. Az összes összetevőt konfigurálja a weboldal készítésekor. Mint az időjárási elem, amelynek három napra időjárás-előrejelzést kell megjelenítenie. Vagy hogy négy blogbejegyzés legyen a főoldalon. A többi dinamikus tartalom a fej nélküli CMS-ben kezelhető.

A megközelítés legfőbb előnye, hogy nincs szüksége adatbázisra. Így van, nincs egyetlen adattárolási pont, amelyhez a támadó hozzáférhet.

Ha webhelye JavaScript alapú, annak megvalósítása alapvetően nyitott. Lehet, hogy össze van állítva, de bármi is elérhető a böngészőben, olvasható. Ez még egy előny. Igen, bárki közvetlenül lekérdezheti a szolgáltatások végpontjait. A tőlük kapott közzétett tartalom egyébként is megjelenik a webhelyén, csak átalakítva szebb látványt. Ez olyan, mint a weboldalakon található hírcikkeknél és az RSS-olvasóknál. Érzékeny tartalom esetén mindig hitelesíthet minden felhasználót egy másik szolgáltatáson keresztül, megszerezheti egyedi hozzáférési jogkivonatát, és felhasználhatja arra, hogy bizalmas tartalmat kérjen biztonságos protokollon keresztül.

Ha szem előtt tartja, hogy a JS megvalósítása mindenki számára nyitott, és a bizalmas adatokat a megfelelő módon kezeli, akkor sokkal kevesebb munkája lesz a webhelye biztonságossá tétele érdekében. Az adatbázis hiánya és az összes API szolgáltatás biztonságos csatornákon keresztül történő fogyasztása szinte minden ajtót bezár egy potenciális támadó előtt.

Teljesítmény

Ebben a forgatókönyvben a webszerver csak eszközöket nyújt. Az alkalmazás üzleti logikáját egy JS fájl tárolja. A különböző végpontokból származó tartalmat a látogatói böngészők aszinkron kérelmeken keresztül gyűjtik össze.

Az Async harmadik fél szolgáltatásaitól kér tartalmat? Ez biztosan lassú, igaz? Nos, bizonyos időbe telik. De a kézbesítési végpontjaikat általában a sebességre építik, felhőben tárolják és nagyon rugalmasak. Választhat egy fej nélküli CMS-t is, amely CDN-t használ a szállításhoz, az egyik a Kentico Cloud. Így a kérést mindig az az adatközpont kezeli, amely földrajzilag a legközelebb van minden látogatóhoz.

Még ha több szolgáltatást is használ egy oldal elkészítéséhez, ezek a kérések mind aszinkronak. A látogatók csak a leglassabbra várnak. Ha egy oldalt egy hagyományos CMS-t használó szerveren állítanak össze, az adatbázissal és más szolgáltatásokkal folytatott kommunikáció általában szinkron. Ezért a kiszolgáló megvárja az egyes tranzakciók befejezését, mielőtt újabbakat kezdene. És miután mindez megtörtént, mindent összeállítunk és egy nagy válaszként visszaküldünk.

Vessen egy pillantást arra, hogy a webszervernek mennyi ideig tartott a beérkező kérések feldolgozása (világos sárga háttér). A látogató egész idő alatt aktívan várakozik, és nem tudja elkezdeni a képek és egyéb eszközök letöltését. Csak a válasz beérkezése után ismerhetik meg őket a látogató böngészője.

Az API-alapú webhely sokkal gyorsabb, mivel a statikus HTML-fájlra adott kezdeti válasz azonnali. A böngésző az egyik eszközként letölti a webhely üzleti logikáját, és minden későbbi aszinkron tartalmi kérelmet generál. A látogató sokkal gyorsabban lát egy teljesen renderelt oldalt, és azt is látja, hogy valami történik. Amikor egy kiszolgáló által renderelt oldalra várnak, csak egy előzetes betöltőt látnak a böngészőjük címsorában. Az API-alapú webhely teljesítményének javulása ebben az esetben meghaladja az 50% -ot. Sokkal magasabb lehet a weboldal megvalósításától függően.

Statikus weboldalak

Miért zavarna tehát a teljesítmény megoldása, ha már van API alapú webhelyünk?

Mivel a webszerver csak statikus fájlokat és eszközöket nyújt, teljesítménye jó. Az a tény, hogy a dinamikus tartalom később gyűlik össze, amikor a webhelyet a látogató böngészőiben renderelik, bizonyos műtermékekhez vezethet. A látogatók láthatnak egy üres összetevőt, amely kitöltődik, amikor aszinkron kérésből kap adatokat, és így tovább. A lassú internetkapcsolattal rendelkező vagy régebbi számítógépeket használó emberek számára ez zavaró lehet.

Mit tehetünk ez ellen? Nem, nem adunk hozzá előfeltöltőket. Milyen érzéssel tölt el, amikor egy végtelen előfeltöltőt lát, amely csak forog és forog és forog? Webhelyeinket statikussá tehetjük, ugyanakkor dinamikusak maradhatunk.

A statikus webhelyek fogalma a webhely kimenetéről szól. A tartalommal kezdődik. A szerkesztők általában nem frissítik olyan gyakran a tartalmat. A weboldalt minden egyes kérésre össze kell állítani (mint a hagyományos CMS-ek). Az ötlet hasonló a gyorsítótárhoz - tárolja a létrehozott adatokat vagy oldalakat a memóriában. De a statikus helyek valamivel tovább mennek. A teljes weboldal, az összes tartalommal rendelkező oldal minden egyes alkalommal elkészül, amikor egy szerkesztő tartalmat tesz közzé. Tehát ha 153 blogbejegyzésed van a blogodban, akkor a webhelynek mostantól 153 statikus oldala lesz (plusz néhány más, például kezdőlap, kapcsolattartó stb.).

Hogyan fogja kezelni a 153 oldalt? Nos, nem. Ön továbbra is csak egyetlen dinamikus oldal megvalósítását kezeli. A statikus webhelyet úgy hozza létre, hogy ötvözi a megvalósítást a fej nélküli CMS tartalmával. Tehát, ha új tartalom van, a webhelyet automatikusan automatikusan létrehozzák.

Úgy látja, a sebesség előnye nem olyan jelentős a dinamikus API-alapú webhelyekhez képest. Azonban:

  • látogatói az első válaszban megkapják az oldalt és az összes tartalmat. Nem fognak egy épülő oldalt nézegetni. Böngészőiknek nem kell további aszinkron kéréseket létrehozniuk a tartalomhoz
  • minden későbbi kérés ugyanúgy viselkedik
  • a látogatók statikus oldalak között mozognak, ami nagyon gyors
  • a statikus webhelyek generálásának egyes eszközei további hűvös funkciókat tesznek lehetővé a látogatók számára, például a linkelt oldalak előzetes betöltését (ami azonnali navigációt tesz lehetővé), vagy a képeket alacsony minőségben jeleníti meg, mielőtt azokat teljesen letöltenék.

Mindez egy lángoló, gyors weboldal benyomását kelti a látogatókban.

Természetesen minden weboldal más és más. Szüksége lehet néhány személyre szabási funkcióra, vagy érzékeny tartalmat szeretne megjeleníteni. Ezekben az esetekben kombinálhatja mindkét megközelítést. Legyen statikus webhelye, és továbbra is használja az API-alapú szolgáltatásokat a látogatóktól függően eltérő tartalom szállításához.

Következtetés

Minden webhely teljesítménye és biztonsági szempontjai nagyon fontosak. A hagyományos CMS-ek általában erőforrásigényesebbek, mint az API-alapú webhelyek, de több funkcionalitást nyújtanak out-of-the-box.

Másrészt az API-alapú webhelyek sokkal gyorsabbak és biztonságosabbak. Ezek lehetővé teszik, hogy pénzt takarítson meg a tárhelyen, és jobb élményt nyújtsanak látogatóinak.

A statikus oldalak manapság nagy sikert aratnak, mivel teljesítményük messze a legjobb. Lehetővé teszik részleges statikus részdinamikus webhelyek létrehozását JavaScript alapján, amelyeket a keresőmotorok jól indexelhetnek.

A webhelye már statikus? Használt már statikus webhely-generátort? Tájékoztasson tapasztalatairól az alábbi megjegyzések részben.

A következő cikkemben bemutatom, hogyan lehet webhelyet készíteni a Vue.js webhelyen statikus webhelygenerátor segítségével.

A cikk további cikkei:

  1. Hogyan kezdjünk el először létrehozni egy lenyűgöző weboldalt?
  2. Hogyan dönthetünk a webhelyének legjobb technológiájáról?
  3. Hogyan lehet feltölteni webhelyét a Vue.js segítségével és minimális erőfeszítéssel
  4. Hogyan keverjük össze a Headless CMS-t egy Vue.js weboldallal és a Pay Zero-val
  5. Az űrlapok beküldésének biztonságossá tétele az API webhelyén
  6. A szupergyors és biztonságos weboldal felépítése CMS-sel nem nagy ügy. Vagy ez?
  7. Hogyan lehet pillanatok alatt létrehozni egy statikus weboldalt a Vue.js segítségével
  8. Hogyan lehet gyorsan beállítani egy statikus webhely összeépítési folyamatát