Sukurti itin greitą ir saugią svetainę su TVS nėra didelė problema. Ar tai yra?

Ar galiu sulaužyti jūsų svetainę? Ar turite ten likusių scenarijų, kuriais galėčiau pasinaudoti? Ar yra būdas pavogti savo kredencialus ir pakeisti savo svetainės turinį? Ar galiu pasiekti privačią informaciją? Ne? Ar tu tuo tikras? Arba aš niekada to nesužinosiu, nes jūsų puslapis įkeliamas per amžius?

Tam tikru metu kurdami svetainę turite galvoti apie našumą ir saugumą. Nesvarbu, ar dirbate savo asmeninėje, ar savo kliento svetainėje. Tai tas pats, kas kurti atsargines vietinių failų kopijas. Yra žmonių, kurie reguliariai daro atsargines kopijas, ir dar nepraradę žmonių, todėl yra mažiau linkę tai daryti.

Tradicinė TVS

Jei naudojate tradicinę turinio valdymo sistemą (TVS), situacija jums yra sudėtingesnė. Šiose sistemose yra daugybė funkcijų. Jie turi apimti visus galimus bet kokio tinklalapio naudojimo atvejus. Tai reiškia kodą. Daug kodo. Tūkstančiai bylų. Ir tai dar ne viskas - administravimo sąsajos turi suteikti gražų vartotojo sąsają, kad galėtumėte sukonfigūruoti visas šias funkcijas. Potencialiai dar keli tūkstančiai bylų.

Saugumas

Tai ne tavo kodas, tiesa? Taigi jis jau turėtų būti saugus. Na, daugelis TVS pardavėjų stengiasi užtikrinti, kad jų diegimas būtų saugus. Jie vis tiek turi apimti daugybę bylų. Kiekviename faile gali būti klaida, kodas, kuris buvo paliktas, arba užklausos eilutės parametras, atskleidžiantis duomenų bazę. Tai savaime gali sukurti potencialų pažeidžiamumą.

Atvirojo kodo TVS naudojimas gali būti dar pavojingesnis, nes įgyvendinimas yra viešai žinomas. Taip, jūs galite teigti, kad atviras šaltinis yra naudingas. Kiekvienas gali prisidėti ir išspręsti rastas problemas. Tačiau tai apima tik jau žinomus klausimus. Užpuolikai tikriausiai pasiliks savo išnaudojimus. Net jei problema buvo rasta ir išspręsta, vis tiek turite įdėti daug pastangų, kad jūsų svetainė būtų nuolat atnaujinama. Naujinimus turite atlikti kiekvieną kartą, kai išleidžiamos saugos karštosios pataisos.

Jei jus domina realaus pasaulio statistika, pažvelkite į nulaužtą „Sucuri“ svetainės ataskaitą.

Taigi, ką užpuolikai norėtų daryti su jūsų svetaine? Iš esmės jie nori sugauti jūsų duomenis, kad galėtų netinkamai naudoti jūsų svetainę:

  • Gauti prieigą prie savo duomenų bazės per vieną iš scenarijų. Paprastai tai būna pasirinktinių scenarijų, testavimo puslapių ir kitų atvejų.
  • Kompromituoti ir netinkamai naudoti savo slaptus duomenis. Konfigūracijos failai yra tipinė įvairių slaptųjų raktų ir prisijungimo duomenų saugojimo parinktis į kitas paslaugas ar duomenų bazes.
  • Jūsų svetainės turinio modifikavimas.
  • Padarykite savo svetainę nepasiekiamą, ty uždarykite ją.

Spektaklis

Kai diegiate savo svetainę tradicinėje TVS, paprastai turite ją pritaikyti, todėl yra TVS ir jūsų pasirinktinių failų. Visus juos reikia sukompiliuoti ir kartu su iš anksto sukompiliuotomis bibliotekomis pakelti į serverio atmintį, kol serveris iš tikrųjų galės pradėti tvarkyti užklausas į jūsų svetainę. Arba dar blogiau, jei naudojate sprendimą, pagrįstą interpretuota kalba, pvz., PHP, interpretuokite visus kiekvienos užklausos kodus.

Bet kokiu atveju jūsų svetainė atrodo gerai, tad kodėl tai turėtų kelti nerimą? Na, nes:

  • mokate už savo serverio skaičiavimo galią
  • sudarote ir nukopijuojate funkcijų, kurių niekada neketinate naudoti, kodą
  • jūsų svetainės lankytojai laukia atsakymo

Laikas iki pirmojo šių svetainių baito gali būti ilgesnis nei 1 sekundė. Aišku, jį galima optimizuoti, bet tada jūs išleidžiate laiko ir pinigų, kad suprastumėte, kaip sušvelninti našumo problemas, ir dažniausiai padidinate procesorių ir atmintį, o dar blogiau - pridėdami papildomą serverį.

Patikrinkite savo svetainę naudodami „Google PageSpeed“ arba gaukite išsamesnę analizę naudodami „SpeedCurve“, kad sužinotumėte, kaip jūsų svetainei sekasi.

API pagrįstos svetainės

Svetainės, sukurtos ant API, suteikia didelį lankstumą. Paklauskite savęs, ar jums reikia turinio valdymo? Jei taip, galite naudoti TVS be galvos. Ar turite saugoti formos pateikimus? Puiku, naudokitės formos paslauga. Kuriate kalnų viešbučių svetainę ir norite rodyti orų prognozę? Jums yra orų tarnyba su savo API.

Tokioms svetainėms naudojamų failų skaičius atitinka jo funkcionalumą. Bet ką daryti su turinio redagavimo administravimo sąsaja? Nesijaudink. TVS be galvos tvarko tą dalį už jus, be jokio papildomo kodo, kurį jums reikia priglobti ar prižiūrėti.

Saugumas

Naudojantis API paslaugomis, jūsų svetainės viršuje nereikia administravimo paslaugos. Kurdami svetainę sukonfigūruojate visus komponentus. Kaip ir oro komponentas, kuris turėtų rodyti orų prognozę trims dienoms. Arba kad pagrindiniame puslapyje turėtų būti keturi tinklaraščio įrašai. Likusį dinaminį turinį galima valdyti CMS be galvų.

Pagrindinis šio požiūrio pranašumas yra tas, kad jums nereikia duomenų bazės. Tiesa, nėra vieno duomenų saugojimo taško, prie kurio užpuolikas galėtų naudotis.

Jei jūsų svetainė yra paremta „JavaScript“, jos diegimas iš esmės yra atviras. Jis gali būti sudarytas, bet viskas, kas pateikiama naršyklėje, yra įskaitoma. Tai dar vienas privalumas. Taip, kiekvienas gali tiesiogiai atlikti užklausą dėl paslaugų galinių taškų. Iš jų gautas paskelbtas turinys vis tiek rodomas jūsų svetainėje, tik paverstas gražesniu vaizdu. Tai panašu į naujienų straipsnius svetainėse ir RSS skaitytojus. Dėl neskelbtino turinio jūs visada galite autentifikuoti kiekvieną vartotoją naudodami kitą paslaugą, gauti jo unikalų prieigos raktą ir naudoti jį prašydami neskelbtino turinio per saugų protokolą.

Jei turėsite omenyje, kad JS diegimas yra atviras visiems ir teisingai elgiatės su neskelbtinais duomenimis, turėsite daug mažiau dirbti, kad jūsų svetainė būtų saugi. Neturint duomenų bazės ir vartojant visas API paslaugas saugiais kanalais, potencialiam užpuolikui uždaromos beveik visos durys.

Spektaklis

Šiuo atveju žiniatinklio serveris teikia tik turtą. Jūsų programos verslo logika saugoma JS faile. Turinys iš įvairių galinių taškų surenkamas naudojant asinchronines lankytojų naršyklių užklausas.

„Async“ prašymai gauti turinį iš trečiųjų šalių paslaugų? Tai turi būti lėta, tiesa? Na tikrai, jie užtrunka šiek tiek laiko. Tačiau jų pateikimo galiniai taškai paprastai yra sukurti greičiui, priglobti debesyje ir labai lankstūs. Taip pat galite pasirinkti CMS be galvos, kuris pristatymui naudoja CDN, vienas iš jų yra „Kentico Cloud“. Tokiu būdu užklausą visada tvarkys duomenų centras, kuris yra geografiškai arčiausiai jūsų lankytojų.

Net jei naudojate kelias paslaugas kurdami vieną puslapį, visos šios užklausos yra asinchroninės. Lankytojai laukia tik lėčiausio. Kai puslapis serveryje sudaromas naudojant tradicinę TVS, visas ryšys su duomenų baze ir kitomis paslaugomis paprastai vyksta sinchroniškai. Todėl serveris laukia, kol kiekviena operacija bus baigta, prieš pradėdama kitą. Po to, kai visa tai bus padaryta, viskas bus sudėta ir išsiųsta atgal kaip vienas didelis atsakymas.

Pažiūrėkite, kiek laiko truko žiniatinklio serveris, kol apdorojo gaunamas užklausas (šviesiai geltonas fonas). Visą šį laiką lankytojas aktyviai laukia ir negali pradėti atsisiųsti vaizdų bei kito turto. Jie bus žinomi lankytojo naršyklėje tik gavus atsakymą.

API pagrindu sukurta svetainė yra daug greitesnė, nes pradinis atsakymas naudojant statinį HTML failą yra greitas. Naršyklė atsisiunčia verslo logiką kaip vieną iš išteklių ir sugeneruoja visas paskesnes asinchronines užklausas dėl turinio. Lankytojas mato visiškai atvaizduotą puslapį daug greičiau, taip pat mato, kad kažkas vyksta. Kai jie laukia serverio pateikto puslapio, viskas, ką jie mato, yra išankstinis krautuvas jų naršyklės adreso juostoje. Šiuo atveju API pagrįstos svetainės našumas šiuo metu yra didesnis nei 50%. Jis gali būti daug didesnis, atsižvelgiant į svetainės įgyvendinimą.

Statinės svetainės

Tad kodėl mes turėtume vargti spręsdami našumą, jei jau turime svetainę, pagrįstą API?

Kadangi interneto serveris teikia tik statinius failus ir išteklius, jo našumas yra geras. Tai, kad dinaminis turinys surenkamas vėliau, kai svetainė pateikiama lankytojo naršyklėse, gali sukelti tam tikrų artefaktų. Lankytojai gali matyti tuščią komponentą, kuris užpildomas, kai gauna duomenis iš asinchroninės užklausos ir pan. Žmonėms, turintiems lėtą interneto ryšį arba naudojantiems senesnius kompiuterius, gali pasirodyti, kad tai kelia nerimą.

Ką mes galime padaryti? Ne, mes nepridėsime jokių išankstinių krautuvų. Kaip jaustis, kai pamatai begalinį išankstinį kroviklį, kuris tik sukasi ir sukasi, ir sukasi? Mes galime padaryti savo svetaines statiškas, tačiau išlaikyti jas dinamiškas.

Statinių svetainių sąvoka yra susijusi su jūsų svetainės išvestimi. Tai prasideda nuo turinio. Redaktoriai paprastai taip dažnai neatnaujina turinio. Svetainę reikia sudaryti pagal kiekvieną prašymą (kaip tai daro tradiciniai TVS). Idėja panaši į talpyklą - saugokite sugeneruotus duomenis ar puslapius atmintyje. Tačiau statinės svetainės eina šiek tiek toliau. Visa svetainė, visi puslapiai su visu turiniu, sugeneruojami kiekvieną kartą, kai redaktorius skelbia turinį. Taigi, jei jūsų tinklaraštyje yra 153 tinklaraščio įrašai, svetainėje dabar bus 153 statiniai puslapiai (be to, kai kurie kiti, pvz., Pagrindinis puslapis, kontaktai ir kt.).

Kaip ketinate tvarkyti 153 puslapius? Na, tu ne. Jūs vis tiek valdote tik vieno dinaminio puslapio įgyvendinimą. Statiška svetainė sukuriama derinant jūsų įgyvendinimą su turiniu iš BSG be galvos. Taigi, kai yra naujo turinio, svetainė vėl automatiškai sugeneruojama.

Matote, kad greitis nėra toks reikšmingas, palyginti su dinaminėmis API pagrįstomis svetainėmis. Tačiau:

  • jūsų lankytojai gauna puslapį ir visą turinį per pirmąjį atsakymą. Jie nežiūrės į statomą puslapį. Jų naršyklėms nereikia kurti papildomų asinchroninių užklausų dėl turinio
  • visi vėlesni prašymai elgiasi taip pat
  • lankytojai naršo tarp statinių puslapių rinkinio, kuris yra labai greitas
  • kai kurie statinių svetainių generavimo įrankiai suteikia lankytojams papildomų šaunių funkcijų, tokių kaip išankstinis susietų puslapių įkėlimas (todėl greitas naršymas prie jų) arba žemos kokybės vaizdų rodymas prieš juos visiškai atsisiunčiant.

Visa tai paliks jūsų lankytojams įspūdingą greitą internetinę svetainę.

Žinoma, kiekviena svetainė yra skirtinga. Jums gali prireikti kai kurių suasmeninimo funkcijų arba norite rodyti neskelbtiną turinį. Tais atvejais galite derinti abu metodus. Turėkite statišką svetainę ir vis tiek naudokite API pagrįstas paslaugas, kad pristatytumėte turinį, kuris skiriasi nuo lankytojų.

Išvada

Kiekvienos svetainės našumas ir saugumas yra labai svarbūs. Tradiciniai TVS paprastai reikalauja daugiau išteklių nei API pagrindu sukurtos svetainės, tačiau jie suteikia daugiau funkcionalumo iš pat pradžių.

Kita vertus, API pagrįstos svetainės yra daug greitesnės ir saugesnės. Jie leidžia sutaupyti pinigų talpinant ir suteikia geresnę patirtį lankytojams.

Statiškos svetainės šiais laikais tampa dideliu hitu, nes jų veikimas kol kas yra geriausias. Jie taip pat leidžia jums kurti dalines ir dinamines svetaines, pagrįstas „JavaScript“, kurias paieškos sistemos gerai indeksuoja.

Ar jūsų svetainė jau statiška? Ar naudojatės statinių svetainių generatoriais? Praneškite man apie savo patirtį žemiau esančiame komentarų skyriuje.

Kitame savo straipsnyje aš jums parodysiu, kaip sukurti svetainę Vue.js naudojant statinį svetainės generatorių.

Kiti šios serijos straipsniai:

  1. Kaip pirmą kartą pradėti kurti įspūdingą svetainę
  2. Kaip nuspręsti dėl geriausios jūsų svetainės technologijos?
  3. Kaip įjungti savo svetainę naudojant „Vue.js“ ir minimaliomis pastangomis
  4. Kaip sumaišyti TV be galvos su „Vue.js“ svetaine ir „Pay Zero“
  5. Kaip apsaugoti formos pateikimą API svetainėje
  6. Sukurti itin greitą ir saugią svetainę su TVS nėra didelė problema. Ar tai yra?
  7. Kaip greitai sukurti statinę svetainę naudojant „Vue.js“
  8. Kaip greitai nustatyti statinės svetainės kūrimo procesą