At opbygge et superhurtigt og sikkert websted med et CMS er ikke noget stort. Eller er det?

Kan jeg bryde dit websted? Har du nogle resterende scripts der, som jeg kan drage fordel af? Er der en måde at stjæle dine legitimationsoplysninger og ændre indhold på dit websted? Kan jeg få adgang til private oplysninger? Ingen? Er du sikker? Eller vil jeg aldrig finde ud af det, fordi din side tager aldre at indlæse?

På et tidspunkt, når du opretter et websted, skal du tænke på ydeevne og sikkerhed. Det betyder ikke noget, om du arbejder på din personlige hjemmeside eller din klients hjemmeside. Det er det samme som at sikkerhedskopiere dine lokale filer. Der er mennesker, der foretager regelmæssige sikkerhedskopier, og folk, der endnu ikke har mistet nogen, så er mindre tilbøjelige til at gøre det.

Traditionelt CMS

Hvis du bruger et traditionelt indholdsstyringssystem (CMS), er situationen mere kompliceret for dig. Disse systemer indeholder mange funktioner. De har brug for at dække alle mulige brugssager, som ethvert websted måtte have. Det betyder kode. En masse kode. Tusinder af filer. Og det er ikke alt - administrationsgrænsefladerne skal give dig et flot brugergrænseflade til at konfigurere alle disse funktioner. Potentielt endnu et par tusinde filer.

Sikkerhed

Det er ikke din kode, ikke? Så det burde allerede være sikkert. Nå, mange CMS-leverandører prøver deres bedste for at sikre, at deres implementeringer er sikre. De skal stadig dække mange filer. Og hver enkelt fil kan indeholde en fejl, en kode, der blev efterladt, eller måske en querystring-parameter, der udsætter en database. Det kan i sig selv skabe en potentiel sårbarhed.

Brug af open source CMS kan være endnu farligere, da implementeringen er offentligt kendt. Ja, du kan argumentere for, at open source er fordelagtigt. Alle kan bidrage og løse fundne problemer. Men dette dækker kun spørgsmål, der allerede er kendt. Angribere ville sandsynligvis holde deres bedrifter for sig selv. Selv hvis et problem blev fundet og løst, er du stadig nødt til at lægge en stor indsats for at sikre, at dit websted holdes opdateret. Du skal udføre opgraderinger hver gang et sikkerhedshotfix frigives.

Hvis du er interesseret i virkelige statistikker, skal du kigge på hacket webstedsrapport fra Sucuri.

Så hvad ville angribere gøre med dit websted? I det væsentlige ønsker de at få fat i dine data, så de kan misbruge dit websted ved at:

  • Få adgang til din database via et af scripts. Dette er normalt tilfældet med brugerdefinerede restskripter, testsider og andre.
  • Kompromitterer og misbruger dine hemmelige data. Konfigurationsfiler er en typisk lagringsmulighed for forskellige hemmelige nøgler og legitimationsoplysninger til andre tjenester eller databaser.
  • Ændring af dit webstedsindhold.
  • Gør dit websted utilgængeligt, dvs. luk det.

Ydeevne

Når du implementerer dit websted på et traditionelt CMS, skal du normalt tilpasse det, så der er filer til CMS og dine brugerdefinerede filer. Alle af dem skal kompileres, og derefter sammen med forudkompilerede biblioteker bringes op til serverhukommelsen, før serveren rent faktisk kan begynde at behandle anmodninger til dit websted. Eller værre, hvis du bruger en løsning baseret på tolket sprog som PHP, skal du fortolke al kode for hver anmodning.

Under alle omstændigheder ser dit websted ud til at køre fint, så hvorfor skulle dette være et problem? Nå, fordi:

  • du betaler for serverens computerkraft
  • du kompilerer og kopierer kode for funktionaliteter, du aldrig har til hensigt at bruge
  • dine besøgende på websiden venter på svaret

Tid til første byte på disse websteder kan være langt over 1 sekund. Sikker på, det kan optimeres, men så bruger du tid og penge på at finde ud af, hvordan du kan mindske ydelsesproblemer, og normalt ender med at øge CPU og hukommelse, eller værre, tilføje en ekstra server.

Tjek dit websted ved hjælp af Google PageSpeed, eller få mere detaljeret analyse ved hjælp af SpeedCurve for at se, hvordan dit websted klarer sig.

API-baserede websteder

Websteder bygget oven på en API muliggør stor fleksibilitet. Spørg dig selv, har du brug for indholdsstyring? I så fald kan du bruge et hovedløst CMS. Har du brug for at gemme formularindsendelser? Perfekt, brug en formtjeneste. Bygger du et websted for bjerghotel og vil have en vejrudsigt? Der er en vejretjeneste med sin API til dig.

Antallet af filer, der bruges til sådanne websteder, svarer til dets funktionalitet. Men hvad med administrationsgrænsefladen til redigering af indhold? Bare rolig. Det headless CMS håndterer den del for dig uden yderligere kode, du har brug for at være vært for eller vedligeholde.

Sikkerhed

Når du bruger API-tjenester, behøver du ikke en administrationstjeneste oven på dit websted. Du konfigurerer alle komponenter, når du bygger hjemmesiden. Ligesom vejrkomponenten, der skal vise en vejrudsigt i tre dage. Eller at der skulle være fire blogindlæg på hovedsiden. Resten af ​​det dynamiske indhold kan administreres i det headless CMS.

Den største fordel ved denne tilgang er, at du ikke har brug for en database. Det er rigtigt, intet enkelt datalagringspunkt, som en hacker kan få adgang til.

Hvis dit websted er baseret på JavaScript, er dets implementering stort set åben. Det kan kompileres, men hvad der leveres til browseren er læsbart. Dette er endnu en fordel. Ja, alle kan forespørge tjenesternes slutpunkter direkte. Det offentliggjorte indhold, du får fra dem, vises alligevel på dit websted, kun omdannet til et pænere billede. Det er som med nyhedsartikler på websteder og RSS-læsere. For følsomt indhold kan du altid godkende hver bruger via en anden tjeneste, få deres unikke adgangstoken og bruge det til at bede om følsomt indhold via sikker protokol.

Hvis du husker, at JS-implementeringen er åben for alle og behandler følsomme data på den rigtige måde, har du meget mindre arbejde at gøre for at gøre dit websted sikkert. Ikke at have en database og forbruge alle API-tjenester gennem sikre kanaler lukker næsten alle døre for en potentiel angriber.

Ydeevne

I dette scenarie leverer webserveren kun aktiver. Virksomhedslogikken for din applikation er gemt i en JS-fil. Indhold fra forskellige slutpunkter indsamles via asynkrone anmodninger fra besøgende browsere.

Async anmoder om at få indhold fra tredjeparts tjenester? Det må være langsomt, ikke? Nå, de tager noget tid. Men deres leveringsendepunkter er normalt bygget til hastighed, hostet i Cloud og meget fleksible. Du kan også vælge et hovedløst CMS, der bruger et CDN til levering, en af ​​dem er Kentico Cloud. På den måde håndteres anmodningen altid af det datacenter, der er geografisk tættest på hver af dine besøgende.

Selvom du bruger flere tjenester til at opbygge en enkelt side, er disse anmodninger alle asynkrone. Besøgende venter kun på den langsomste. Når en side er sammensat på en server ved hjælp af traditionelt CMS, er al kommunikation med databasen og andre tjenester normalt synkron. Derfor venter serveren på, at hver transaktion er afsluttet, før den starter en anden. Og når alt dette er gjort, sættes alt sammen og sendes tilbage som et stort svar.

Se, hvor lang tid det tog webserveren at behandle indgående anmodninger (lysegul baggrund). I hele denne tid venter den besøgende aktivt og kan ikke begynde at downloade billeder og andre aktiver. De vil kun være kendt af den besøgendes browser, efter at svaret er modtaget.

Et API-baseret websted er meget hurtigere, da det indledende svar med en statisk HTML-fil er øjeblikkelig. Browseren downloader hjemmesidens forretningslogik som en af ​​aktiverne og genererer alle efterfølgende asynkrone anmodninger om indhold. Besøgende ser en fuldt gengivet side meget hurtigere, og de ser også, at der sker noget. Når de venter på en servergengivet side, er alt, hvad de ser, en forudindlæser i adresselinjen i deres browser. Den samlede præstationsforbedring af API-baseret websted er i dette tilfælde over 50%. Det kan være meget højere afhængigt af implementeringen af ​​webstedet.

Statiske websteder

Så hvorfor ville vi gider med at løse ydeevne, hvis vi allerede har et API-baseret websted?

Da webserveren kun leverer statiske filer og aktiver, er dens ydeevne god. Det faktum, at dynamisk indhold indsamles senere, når webstedet gengives i de besøgendes browsere, kan føre til nogle artefakter. Besøgende kan muligvis se en tom komponent, der bliver udfyldt, når den modtager data fra asynkron anmodning og så videre. Personer med en langsom internetforbindelse eller bruger ældre computere kan finde dette foruroligende.

Hvad kan vi gøre ved dette? Nej, vi tilføjer ingen forudindlæser. Hvordan får det dig til at føle dig, når du ser en uendelig forudlader, der bare drejer og drejer og drejer? Vi kan gøre vores websteder statiske, men alligevel holde dem dynamiske.

Begrebet statiske websteder handler om output fra dit websted. Det starter med indholdet. Redaktører opdaterer normalt ikke indhold så ofte. Webstedet skal sammensættes efter hver enkelt anmodning (som traditionelle CMS'er gør). Ideen ligner cache - gem genererede data eller sider i hukommelsen. Men statiske steder går lidt længere. Hele hjemmesiden, alle sider med alt indhold, genereres hver eneste gang en redaktør offentliggør indhold. Så hvis du har 153 blogindlæg i din blog, vil hjemmesiden nu have 153 statiske sider (plus nogle andre som startside, kontakt og mere).

Hvordan skal du styre 153 sider? Det gør du ikke. Du administrerer stadig kun implementeringen af ​​en enkelt dynamisk side. Det statiske sted genereres ved at kombinere din implementering med indhold fra et headless CMS. Så når der er nyt indhold, genereres webstedet bare automatisk igen.

Du ser fordelene ved hastighed ikke er så signifikant sammenlignet med dynamiske API-baserede websteder. Imidlertid:

  • dine besøgende får siden og alt indhold i det første svar. De vil ikke se på en side, der bygges. Deres browsere behøver ikke at oprette yderligere async-anmodninger om indhold
  • alle efterfølgende anmodninger opfører sig på samme måde
  • besøgende navigerer mellem sæt statiske sider, hvilket er meget hurtigt
  • nogle værktøjer til generering af statiske websteder muliggør yderligere seje funktioner for besøgende såsom forudindlæsning af linkede sider (hvilket gør det muligt at navigere direkte til dem) eller vise billeder i lav kvalitet, før de downloades fuldt ud

Alt dette vil efterlade dine besøgende indtryk af et lynhurtigt websted.

Selvfølgelig er alle websteder forskellige. Du har muligvis brug for nogle personaliseringsfunktioner eller ønsker at vise følsomt indhold. I disse tilfælde kan du kombinere begge tilgange. Har et statisk websted, og brug stadig API-baserede tjenester til at levere indhold, der varierer blandt besøgende.

Konklusion

Ydelses- og sikkerhedsaspekterne på hvert websted er meget vigtige. Traditionelle CMS'er er normalt mere ressourcekrævende end API-baserede websteder, men de giver mere funktionalitet uden for kassen.

På den anden side er API-baserede websteder meget hurtigere og mere sikre. De giver dig mulighed for at spare penge på hosting og give dine besøgende en bedre oplevelse.

Statiske websteder bliver et stort hit i dag, da deres præstationer er langt den bedste. De giver dig også mulighed for at oprette delstatiske deldynamiske sider baseret på JavaScript, der pænt kan indekseres af søgemaskiner.

Er dit websted allerede statisk? Har du brugt generatorer til statiske websteder? Fortæl mig om din oplevelse i kommentarfeltet nedenfor.

I min næste artikel vil jeg vise dig, hvordan du opbygger et websted på Vue.js ved hjælp af statisk stedgenerator.

Andre artikler i serien:

  1. Sådan starter du oprettelse af et imponerende websted for første gang
  2. Hvordan vælger man den bedste teknologi til dit websted?
  3. Sådan tændes dit websted med Vue.js og minimal indsats
  4. Sådan blandes headless CMS med et Vue.js-websted og betal nul
  5. Sådan oprettes formularindsendelser på et API-websted
  6. At opbygge et superhurtigt og sikkert websted med et CMS er ikke noget stort. Eller er det?
  7. Sådan oprettes et statisk websted med Vue.js på ingen tid
  8. Sådan oprettes hurtigt en byggeproces for et statisk sted