Astros fördelar och nackdelar: när är det värt att använda Astro?

Den som har sålt webbplatser utan underhåll vet hur ofta man säger till kunden att de ska få ett superenkelt CMS där de själva kan göra stora och små ändringar utan problem.

Kunden tycker att det låter toppen i offerten, men när webbplatsen väl är klar ändrar de ingenting på flera månader. Om de någon gång vill ändra något skriver de till dig och ber dig fixa det.

Det är normalt: kunden fokuserar på sitt företag och vill bara att webbplatsen ska ge fler kunder. Inget konstigt.

Efter att ha sett detta många gånger har jag alltid tyckt att WordPress är fantastiskt, särskilt för utvecklaren, eftersom det kräver underhåll som inte alltid borde vara nödvändigt.. 

Därför tänkte jag att det måste finnas alternativ. Andra vägar som jag hittills inte hade funnit.

För med webbplatser i ren HTML tar även en liten ändring, som att byta telefonnummer till kundtjänsten, en hel del tid. Dessutom behöver du ofta avancerade funktioner som i princip kräver ett serverspråk.

Och ja, PHP är ett alternativ, med sina includes och alla möjligheter. Men utvecklingen blir betydligt mer komplicerad än med WordPress. För att inte tala om att webbhotellet måste ha språket installerat och att du behöver hålla det uppdaterat.

Men nyligen upptäckte jag Astro. Och plötsligt föll allt på plats.

Astros filosofi: HTML först, JavaScript bara när det behövs

Om du ännu inte känner till verktyget kan du börja med att förstå vad Astro är och hur det fungerar, framför allt tekniskt. Här fokuserar vi på de praktiska konsekvenserna av dess arkitektur..

Upplägget är att leverera innehållet som HTML och bara använda webbläsarkod för de delar som behöver den. Förutom statisk generering stöder det också rendering på begäran.

Låt oss se vad det betyder.

Fördelarna med Astro

Först ska vi klargöra att vissa fördelar är generella medan andra bara gäller vissa typer av webbplatser.

Här kommer de.

Prestanda direkt i arkitekturen

För en tjänstesida undviker man arbete vid besöket genom att leverera ett färdigt dokument. Servern behöver inte skapa innehållet på nytt när det inte har ändrats; det räcker att skicka en sparad HTML-fil.

Det ger en mycket bra grund för (väldigt) snabb laddning. Särskilt med väloptimerade bilder (hej webp), optimerad CSS och effektiv leverans av filerna.

Fördelen är att du börjar med en lätt struktur och sedan medvetet bara lägger till det du verkligen behöver..

Väldigt lite JavaScript i webbläsaren

Astro försöker undvika allt onödigt JavaScript, eftersom mindre JavaScript minskar både nedladdningen och belastningen på enheten. På en dator är det oftast inget problem, men på en mobil, särskilt en billig, märks det mer: den måste tolka och köra koden samtidigt som den sköter allt annat.

På en informationssajt är det resursslöseri att skicka massor av logik som knappt tillför någon funktion för besökaren.

Astro däremot gör det enkelt att integrera de små interaktiva verktyg som verkligen behövs. Fördelen består så länge du håller koll på vad du lägger till.

Ren HTML och en bra grund för SEO

Att ha huvudinnehållet i HTML gör det lättare att komma åt.

Det är dessutom ganska enkelt att följa bästa praxis för SEO, eftersom man kan bygga en tydlig struktur med rubriker, länkar och avsnitt.

Mindre attackyta

Det här är bra om du vill slippa underhåll.

På en statiskt publicerad webbplats körs varken CMS eller databas i den publika delen. Det finns färre exponerade funktioner att skydda..

Det minskar vissa risker ENORMT, även om projektet inte blir osårbart. Webbhotellskontot, GitHub-arkivet och anslutna tjänster behöver fortfarande skyddas. Har du ett formulär med backend måste den också kontrollera indata och begränsa missbruk. Det fina är att vissa webbplatser nästan aldrig behöver detta.

Enkel och billig hosting

Ännu en generell fördel.

Att leverera statiska filer kräver oftast mindre infrastruktur än att köra en app med databas och serverspråk. För små projekt kan en statisk sajt passa i ett gratis eller billigt abonnemang, beroende på leverantörens villkor.

En stor fördel är faktiskt att du kan publicera en gratis build av webbplatsen på CloudFlare och helt slippa hostingkostnaden. Ja, hela den utgiften försvinner.

Men du måste skilja mellan webbplatsens hosting och resten av projektet:

• Domännamnet måste du alltid betala för.
• E-post kan också vara gratis..
• Om du använder API:er, från Meta eller andra, beror kostnaden på användningen.

Kort sagt: att slippa en traditionell server gör inte hela systemet gratis, men tar bort den största utgiften för företagswebbplatser.

Komponenter utan att göra hela webbplatsen till en SPA

En SPA (Single Page Application) är en applikation där mycket av navigeringen och gränssnittet beror på kod i webbläsaren. Det kan passa vissa produkter, som sociala nätverk och deras flöden, men en tjänstesajt behöver sällan det.

Astro låter dig däremot återanvända komponenter och gemensamma strukturer där det behövs, utan att hela webbplatsen måste fungera som en SPA. Du kan ändra ett gemensamt block en gång och ändå leverera sidor som vanliga dokument.

Flexibilitet med innehållet

Att inget CMS behövs betyder inte att du inte kan lägga till ett.

Du kan börja med statiska filer för en företagswebbplats och koppla in ett CMS om du exempelvis vill börja blogga. Du kan också ansluta system som företaget redan använder och hämta data därifrån.

Den friheten ger olika lösningar för olika slags webbplatser.

Integration med Git

Eftersom bara filer behövs, ingen databas, fungerar Astro utmärkt tillsammans med Git.

Om du sparar projektets historik i Git blir det enklare att se vad som ändrats, testa före publicering och återgå till en tidigare version.

När AI skriver kod är den spårbarheten särskilt användbar: du kan granska en enskild ändring utan att förlita dig på att assistenten minns den.

Separation mellan frontend och externa tjänster

Visst är HTML toppen, men enbart HTML kan inte få ett formulär att fungera och skicka svaren till dig. Där behövs en server.

Det bra är att du med HTML kan koppla in API:er från tjänster som Zoho Mail så att svaren kommer till den e-postadress du anger. Helt gratis.

Om du redan använder det verktyget för företagets e-post behöver du inte lägga till något annat i din stack.

Astros största svagheter

Nu ska vi tala om nackdelarna som gör ramverket mindre lämpligt för vissa projekt.

Inget färdigt CMS ingår

När jag bygger en webbplats är min första praktiska fråga: vem ska uppdatera och underhålla den?

Om kunden vill öppna en kontrollpanel, byta en bild och publicera, erbjuder Astro inte den upplevelsen på egen hand. Man måste arbeta med filer eller lägga till ett redigeringsverktyg.

För kunder som behöver göra ändringar utan att ringa dig är Astro inte det bästa valet.

Fler tekniska beslut krävs

Du behöver bestämma var texterna ska ligga, hur ändringar publiceras, hur formuläret ska fungera och vad som händer om en tjänst slutar fungera.

I ett CMS som WordPress finns nästan allt detta från början.

Fördelen med Astro är däremot att du kan planera systemet en gång och återanvända det på många olika webbplatser.

Integrationer kräver utveckling

Vissa tjänster förenklar arbetet mycket, men du hittar inte alltid en lösning som bara kan installeras och som uppfyller alla behov, som vanliga CMS-plugin.

Det räcker till exempel inte att formge ett formulär. Du måste koppla ihop inskickningen, hantera fel, skydda inloggningsuppgifter och kontrollera att meddelandena kommer fram. Bokningar med tider, betalningar och avbokningar mångdubblar arbetet och därmed besluten.

AI kan snabba på genomförandet, men det behövs fortfarande någon som kan granska resultatet och ta ansvar för det.

Mindre smidigt för redaktionella team

Den som publicerar ibland kan jobba (ganska) bra med Markdown. Ett team med flera skribenter, granskningar, schemaläggning och ständig bildhantering behöver en mer komplett redaktionell miljö.

Alltså ett hederligt gammalt CMS.

Det går att bygga in ett lämpligt CMS i Astro, men varför göra det i stället för att bara använda CMS:et?

Builds kan bli komplicerade i jättestora projekt

Med statisk generering måste alla publicerade sidor byggas. Tiden beror på hur många de är, hur data hämtas och vilken bearbetning som behövs.

En stor katalog med många bilder eller externa förfrågningar kan komplicera processen. Det finns inget universellt antal URL:er där Astro slutar fungera: du måste mäta projektet och avgöra vad som ska byggas i förväg och vad som ska renderas vid behov.

Om en akut uppdatering är beroende av en build som misslyckas ligger det gamla innehållet kvar tills problemet lösts.

Mindre ekosystem än WordPress

Astro har integrationer och mallar men inte lika många färdiga lösningar för väldigt olika affärsbehov.

I WordPress hittar du ofta flera alternativ för bokningar, medlemskap eller redaktionella arbetsflöden. Med Astro kan du behöva koppla ihop tjänster eller utveckla delar själv. Det påverkar arbetstid, budget och vem som kan sköta webbplatsen senare.

En inlärningströskel för den som kommer från PHP eller WordPress

Om du brukar installera ett tema och ställa in plugin dyker nya verktyg upp: paket, kodarkiv, builds och driftsättningar.

Du behöver inte kunna allt direkt. Men du måste förstå vägen från de filer du redigerar till det som faktiskt publiceras. Annars kan du be AI rätta något, se ändringen lokalt och tro att den redan finns på den riktiga webbplatsen.

Inte alla projekt passar en statisk arkitektur

Allt ovan kan sammanfattas så här.

En relativt stabil offentlig sida och en kontrollpanel med personuppgifter i realtid har inte samma behov.

Astro kan använda serverfunktioner och dynamiska funktioner, men en annan plattform kan lösa helheten bättre. Frågan är inte om Astro klarar det, utan om det är värt det.

Förtydliganden om Astros begränsningar

Jag har redan tagit upp det i artikeln, men vill sammanfatta det tydligt här.

Att inget CMS ingår betyder inte att du inte kan använda ett CMS

Du kan lägga till en redigerare och en innehållskälla. Den verkliga begränsningen är att du måste välja, integrera och underhålla dem, med tillhörande kostnader.

Att ingen databas krävs betyder inte att du inte kan använda en

För en enkel webbplats kräver Astro ingen databas.

Om projektet behöver lagra användare, bokningar eller föränderlig information går det att koppla en databas. Nycklar och känsliga frågor ska stanna i en säker servermiljö.

Statisk generering betyder inte att Astro bara kan skapa statiska webbplatser

Du kan kombinera strategier och tjänster.

En förbyggd sida kan skicka ett formulär till en backend. Offentligt innehåll och meddelandehantering är skilda uppgifter.

JavaScript under utvecklingen betyder inte att allt skickas till webbläsaren

För laddningen är det viktiga vad besökaren faktiskt får.

En del kod används för att skapa sidan och körs inte under besöket. Blandar du ihop de två faserna blir din bedömning av webbplatsens verkliga tyngd fel.

När jag skulle välja Astro

Nu till det viktiga.

Jag skulle överväga Astro för:

• En företagswebbplats.
• En portfolio.
• Dokumentation.

Under förutsättning att:

• Sidorna är relativt stabila.
• Ingen annan än jag ska ändra dem.
• Jag vill ha bra prestanda.
• Låg kostnad (slippa servern).
• Och min stack innehåller AI-stödd utveckling och Git-integration.

När jag inte skulle välja Astro

Jag skulle inte använda det om:

• Kunden måste kunna redigera själv.
• Frontend behöver ändras hela tiden.
• Bloggen ska vara webbplatsens centrum.
• För en tidskrift.
• För en webbutik.
• För en medlemstjänst.

Kort sagt när ett CMS gör jobbet enklare.

Slutsats: Astro är inte alltid bättre, det beror på projektet

Jag älskar Astros upplägg. Det är något jag letat efter länge, eftersom det låter mig bygga många sajter med statiskt innehåll och en struktur som passar deras behov väldigt, väldigt väl.

Dessutom fungerar det mycket bra med AI för att utveckla nästan allt.

Men du måste också tänka på webbplatsens liv efter leveransen.

Om kunden kan underhålla den, integrationerna är lösta och innehållet passar, är det ett mycket intressant alternativ.

Som du nog har gissat är jämförelsen jag oftast gör för varje projekt Astro vs WordPress. I den länkade artikeln förklarar jag hur man väljer med hänsyn till hela jobbet, från redigering och underhåll till kundens budget.