Alle som har solgt nettsteder uten vedlikehold, vet hvor ofte man forteller kunden at de skal få et superenkelt CMS der de lett kan gjøre små og store endringer selv.
Kunden synes det høres flott ut i tilbudet, men etter levering endrer de ingenting på månedsvis. Og de få gangene de ønsker en endring, skriver de til deg for å få deg til å ordne det.
Det er helt normalt: De konsentrerer seg om virksomheten og vil bare at nettstedet skal skaffe kunder. Greit nok.
Etter å ha sett dette mange ganger har jeg alltid ment at WordPress er fantastisk, særlig for utvikleren, fordi det krever vedlikehold som ikke alltid burde være nødvendig..
Derfor tenkte jeg at det måtte finnes alternativer. Andre måter å gjøre det på som jeg ikke hadde funnet ennå.
For med nettsteder i ren HTML tar selv den minste endringen, som et nytt kundeservicenummer, ganske mye tid. Og ofte trenger du avanserte funksjoner som i utgangspunktet krever et serverspråk.
Og ja, PHP er et alternativ, med sine includes og mulighetene de gir. Men utviklingen blir mye mer komplisert enn med WordPress. For ikke å snakke om at webhotellet må ha språket installert, og at du må holde det oppdatert.
Men ganske nylig oppdaget jeg Astro. Og plutselig falt alt på plass.
Astros filosofi: HTML først, JavaScript bare når det trengs
Hvis du ikke kjenner verktøyet ennå, kan du begynne med å forstå hva Astro er og hvordan det fungerer, særlig teknisk. Her skal vi konsentrere oss om de praktiske konsekvensene av arkitekturen..
Tilnærmingen er å levere innholdet som HTML og bruke nettleserkode bare på de delene som trenger den. I tillegg til statisk generering støtter Astro også rendering ved behov.
La oss se hva dette betyr.
Fordelene med Astro
Før vi begynner, er det viktig å avklare at noen fordeler gjelder generelt, mens andre bare gjelder visse typer nettsteder.
Her kommer de.
Ytelse gjennom arkitekturen
For en tjenesteside slipper serveren å gjøre arbeid under besøket når dokumentet allerede er klart. Innholdet har ikke endret seg, så det holder å sende en lagret HTML-fil.
Det gir et glimrende utgangspunkt for (svært) rask lasting. Spesielt med godt optimaliserte bilder (hei, webp), optimalisert CSS og effektiv levering av filene.
Fordelen er at du starter med en lett struktur og deretter bevisst bare legger til det du faktisk trenger..
Veldig lite JavaScript i nettleseren
Astro prøver å unngå alt unødvendig JavaScript, siden mindre JavaScript reduserer både nedlastingen og belastningen på enheten. På en PC er det sjelden et problem, men på en mobil, særlig en rimelig modell, merkes det: den må tolke og kjøre koden samtidig som den gjør alt annet.
På et informasjonsnettsted er det bortkastede ressurser å sende masse logikk som knapt tilfører brukeren noen funksjon.
Astro, derimot, gjør det enkelt å integrere de små interaktive verktøyene som faktisk trengs. Fordelen varer så lenge du følger med på hva du legger til.
Ren HTML og et godt utgangspunkt for SEO
Når hovedinnholdet er tilgjengelig i HTML, blir det lettere å nå.
Det er også forholdsvis enkelt å følge beste praksis for SEO, siden du kan bygge en tydelig struktur med overskrifter, lenker og seksjoner.
Mindre angrepsflate
Denne er god hvis du vil unngå vedlikehold.
På en statisk publisert side kjører verken CMS eller database i den offentlige delen. Det er færre eksponerte funksjoner å beskytte..
Det reduserer enkelte risikoer ENORMT, men gjør ikke prosjektet usårbart. Hostingkontoen, GitHub-repositoriet og tilkoblede tjenester må fortsatt sikres. Har du et skjema med backend, må denne også validere inndata og begrense misbruk. Det fine er at enkelte nettsteder nesten aldri trenger dette.
Enkel og rimelig hosting
En annen generell fordel.
Å levere statiske filer krever vanligvis mindre infrastruktur enn å kjøre en applikasjon med database og serverspråk. For mindre prosjekter kan statiske nettsteder passe inn i en gratis eller rimelig plan, avhengig av leverandørens vilkår.
En av de store fordelene er faktisk at du kan publisere en gratis build av nettstedet på CloudFlare og slippe å betale for hosting. Ja, den kostnaden forsvinner helt.
Men du må skille mellom hosting av nettstedet og resten av prosjektet:
- Domenet må du alltid betale for.
- E-post kan også være gratis..
- Bruker du API-er fra Meta eller andre, avhenger det av bruken.
Kort sagt: å kutte ut en tradisjonell server gjør ikke hele systemet gratis, men fjerner den største kostnaden for bedriftsnettsteder.
Komponenter uten å gjøre hele nettstedet til en SPA
En SPA (Single Page Application) er en applikasjon der store deler av navigasjonen og grensesnittet avhenger av kode i nettleseren. Det kan passe til visse produkter, som sosiale nettverk og feedene deres, men et tjenestenettsted trenger det sjelden.
Astro lar deg derimot gjenbruke komponenter og felles strukturer ved behov, uten at hele nettstedet må fungere som en SPA. Du kan endre én felles blokk én gang og fortsatt levere sider som vanlige dokumenter.
Fleksibilitet med innhold
At du ikke trenger et CMS, betyr ikke at du ikke kan integrere ett.
Du kan starte med statiske filer for et bedriftsnettsted og koble til et CMS hvis du for eksempel vil begynne å blogge. Du kan også koble til systemer bedriften allerede bruker, og hente data fra dem.
Denne friheten gir ulike løsninger for alle slags nettsteder.
Integrasjon med Git
Siden du bare trenger filer, ikke en database, fungerer Astro svært godt med Git.
Når prosjekthistorikken ligger i Git, blir det enklere å se hva som er endret, teste før publisering og gå tilbake til en tidligere versjon.
Når KI skriver kode, er denne sporbarheten særlig nyttig: du kan kontrollere en konkret endring uten å stole på at assistenten husker hva den gjorde.
Skille mellom frontend og eksterne tjenester
Ja, HTML er flott, men HTML alene kan ikke få et skjema til å fungere og sende svarene til deg. Til det trenger du en server.
Det fine er at du med HTML kan koble til API-et til tjenester som Zoho Mail og få svarene sendt til e-postadressen du velger. Helt gratis.
Hvis du allerede bruker dette verktøyet til bedriftens e-post, trenger du ikke legge til noe i stacken.
Astros viktigste svakheter
La oss nå snakke om ulempene som gjør rammeverket mindre egnet til enkelte prosjekter.
Inkluderer ikke et ferdig CMS
Når jeg utvikler et nettsted, er mitt første praktiske spørsmål: hvem skal oppdatere og vedlikeholde det?
Hvis kunden forventer å åpne et kontrollpanel, bytte et bilde og publisere, tilbyr ikke Astro den opplevelsen alene. Man må jobbe med filer eller legge til et redigeringsverktøy.
For kunder som trenger å endre nettsiden uten å ringe deg, er ikke Astro det beste valget.
Flere tekniske avgjørelser
Du må bestemme hvor tekstene skal ligge, hvordan endringer publiseres, hvordan skjemaet implementeres, og hva som skjer hvis en tjeneste svikter.
I et CMS som WordPress er det meste av dette nesten ferdig.
Fordelen med Astro er likevel at du kan planlegge systemet én gang og gjenbruke det på mange forskjellige nettsteder.
Integrasjoner krever utvikling
Noen tjenester gjør arbeidet mye enklere, men du finner ikke alltid en løsning du bare kan installere og bruke til alt, slik som vanlige CMS-pluginer.
Det holder for eksempel ikke å utforme et skjema. Du må koble til innsendingen, håndtere feil, beskytte påloggingsopplysninger og kontrollere at meldingene kommer frem. Bestillinger med tidspunkt, betalinger og avbestillinger mangedobler implementeringen og dermed avgjørelsene.
KI kan øke farten på utviklingen, men du trenger fortsatt noen som kan vurdere resultatet og ta ansvar for det.
Mindre praktisk for redaksjoner
En som publiserer av og til, kan jobbe (relativt) greit med Markdown. Et team med flere forfattere, gjennomganger, planlegging og stadig bildehåndtering trenger et mer komplett redaksjonelt oppsett.
Altså et godt gammeldags CMS.
Du kan bygge et passende CMS oppå Astro, men spørsmålet er hvorfor du ikke bare skulle bruke CMS-et.
Builds kan bli kompliserte i enorme prosjekter
Ved statisk generering må sidene som publiseres, bygges. Tiden avhenger av antallet, hvordan data hentes og hvilken behandling som trengs.
En stor katalog med mange bilder eller eksterne forespørsler kan komplisere prosessen. Det finnes ikke et universelt antall URL-er der Astro slutter å være egnet: du må måle prosjektet og bestemme hva som skal bygges på forhånd og hva som skal rendres ved behov.
Hvis en viktig oppdatering er avhengig av en build som feiler, blir det gamle innholdet liggende ute til problemet er løst.
Mindre økosystem enn WordPress
Astro har integrasjoner og maler, men ikke like mange ferdige løsninger for svært forskjellige forretningsbehov.
I WordPress finner du ofte flere alternativer for bestillinger, medlemskap eller redaksjonelle arbeidsflyter. Med Astro må du kanskje koble sammen tjenester eller utvikle deler selv. Det påvirker tidsbruken, budsjettet og hvem som kan ta over vedlikeholdet.
En læringskurve for dem som kommer fra PHP eller WordPress
Hvis du vanligvis installerer et tema og konfigurerer pluginer, dukker nye verktøy opp: pakker, repositorier, builds og utrullinger.
Du trenger ikke beherske alt med én gang. Men du må forstå veien fra filene du redigerer til det som faktisk publiseres. Ellers kan du be KI om en rettelse, se den lokalt og tro at den allerede ligger på den ekte nettsiden.
Ikke alle prosjekter passer med en statisk arkitektur
Alt jeg har sagt, kan oppsummeres her.
En relativt stabil offentlig side og et kontrollpanel med personopplysninger i sanntid har ulike behov.
Astro kan inkludere server og dynamiske funksjoner, men kanskje en annen plattform løser helheten bedre. Spørsmålet er ikke om Astro kan, men om det lønner seg.
Presiseringer om begrensningene til Astro
Jeg har allerede tatt opp dette i artikkelen, men vil oppsummere det her for å være tydelig.
At Astro ikke har et innebygd CMS, betyr ikke at du ikke kan bruke et CMS
Du kan legge til en editor og en innholdskilde. Den virkelige begrensningen er at du må velge dem, integrere dem og vedlikeholde dem, med tilhørende kostnader.
Ingen database nødvendig betyr ikke at du ikke kan bruke en
Astro krever ikke database for en enkel nettside.
Hvis prosjektet trenger å lagre brukere, bestillinger eller informasjon som endres, kan du koble til en database. Nøkler og sensitive spørringer må holdes i et sikkert servermiljø.
Statisk generering betyr ikke at Astro bare kan lage statiske nettsteder
Du kan kombinere strategier og tjenester.
En ferdiglaget side kan sende et skjema til en backend. Offentlig innhold og behandling av meldingen er forskjellige oppgaver.
JavaScript i utviklingen betyr ikke at alt sendes til nettleseren
For lastehastigheten er det hva brukeren mottar som teller.
Noe av koden brukes bare til å bygge siden og kjører ikke under besøket. Hvis du blander disse to fasene, vurderer du nettstedets faktiske størrelse feil.
Når jeg ville valgt Astro
Nå til det viktigste.
Jeg ville vurdert Astro for:
- Et bedriftsnettsted.
- En portefølje.
- Dokumentasjon.
Forutsatt at:
- Sidene er relativt stabile.
- Ingen andre enn meg skal endre dem.
- Jeg ønsker god ytelse.
- Lave kostnader (ingen server å betale for).
- Og stacken min inkluderer KI-assistert utvikling og Git-integrasjon.
Når jeg ikke ville valgt Astro
Jeg ville ikke brukt det hvis:
- Kunden trenger å redigere selv.
- Frontend må endres hele tiden.
- Bloggen skal være kjernen i nettstedet.
- For et magasin.
- For en nettbutikk.
- For en medlemstjeneste.
Kort sagt når et CMS gjør jobben enklere.
Konklusjon: Astro er ikke alltid bedre, det avhenger av prosjektet
Jeg elsker Astros tilnærming. Dette har jeg lett etter lenge, for det lar meg bygge mange nettsteder med statisk innhold og en struktur som er veldig, veldig godt tilpasset det de faktisk trenger.
Dessuten fungerer det svært godt med KI til å utvikle nesten alt.
Men du må også tenke på nettstedets liv etter at det er levert.
Hvis kunden kan vedlikeholde det, integrasjonene er løst og innholdet passer, er det et veldig interessant alternativ.
Som du sikkert har gjettet, er sammenligningen jeg oftest gjør for hvert prosjekt, Astro vs WordPress. I artikkelen jeg lenker til, forklarer jeg hvordan du velger basert på hele jobben, fra redigering og vedlikehold til kundens budsjett.
Ofte stilte spørsmål
Hva er de viktigste ulempene med Astro?
Det inkluderer ikke et ferdig CMS, krever flere tekniske valg, og noen funksjoner trenger utvikling eller eksterne tjenester. Det er også mindre praktisk for team som publiserer hele tiden.
Er Astro bra for SEO?
Ja. Det gjør det enklere å levere HTML-innhold og bygge lette sider med tydelig struktur. Det gir et godt teknisk grunnlag, men rangering avhenger også av innhold, lenker og andre forhold.
Trenger Astro en database?
Nei. En enkel nettside kan bruke statiske filer, men Astro kan også kobles til databaser når prosjektet må lagre eller hente dynamisk informasjon.
Kan man bruke et CMS med Astro?
Ja. Du kan koble til et CMS for innholdsstyring, men må velge, integrere og vedlikeholde det selv. Astro har ikke et komplett redaksjonelt kontrollpanel som standard.
Kan man hoste et Astro-nettsted gratis?
Ja. En statisk nettside kan publiseres på tjenester med gratisplaner, som Cloudflare, så lenge vilkårene oppfylles. Domene, e-post og andre tjenester kan koste ekstra.
Kan Astro lage dynamiske nettsteder?
Ja. Selv om statisk generering er en styrke, støtter det også serverrendering og tilkobling til API-er og eksterne tjenester for dynamiske funksjoner.
Er Astro egnet til en bedriftsnettside?
Etter min mening er dette et av de beste bruksområdene, særlig når innholdet endres lite og noen med teknisk kompetanse tar seg av vedlikeholdet. Det gir raske nettsteder uten et tradisjonelt CMS.
Er Astro å anbefale for en blogg eller et magasin?
Det kan brukes, men jeg ville ikke valgt det først for et magasin eller en blogg med hyppige publiseringer og flere redaktører. WordPress gir som regel enklere redaksjonell styring.
Er Astro bedre enn WordPress?
Det avhenger av prosjektet. Jeg ville valgt Astro for relativt stabile bedriftsnettsteder og WordPress når kunden ofte må redigere innhold eller benytte funksjoner som allerede finnes i pluginer.
Legg igjen en kommentar