winniemethmann.com — fra WordPress til Astro

2026-04-19T00:00:00+00:00

`Hvorfor væk fra WordPress</h2> For en portfolio, der opdateres et par gange om måneden, lavede WordPress for meget:</p>`

PHP-runtime og MySQL</strong> for et site, der i praksis er statisk.</li>
Titusindvis af plugins</strong> til billedgallerier, kontaktformularer, SEO og caching — hver med sin egen opdateringskadence og sikkerhedshuller.</li>
Et halvt-forket tema</strong> med patches, ingen huskede hvorfor var der.</li>
Et admin-login-endpoint</strong>, der blev prøvet flere tusind gange i døgnet af bots.</li>
Gentagne cache-kvaler</strong>, hver gang CDN og plugins var uenige.</li> </ul>
Konkret betød det at droppe WordPress:</p>

Ingen admin-panel at holde patchet.</strong> WordPress-core, plugin-opdateringer, tema-opdateringer — væk.</li>
Ingen database.</strong> Indholdet ligger som Markdown i repoet.</li>
Ingen login-flade, bots kan prøve.</strong> Der findes ikke en `/wp-admin/</code> længere.</li>`
`~10× hurtigere sideindlæsning</strong> uden cache-lag.</li>`
`~70 % mindre samlet build-størrelse</strong> — vi skiftede håndeksporterede JPEG’er ud med AVIF med fornuftige srcset</code>-breakpoints.</li> </ul> Til gengæld mister du den ikke-tekniske redigering. I praksis betød det ingenting: ejeren var gladere for at redigere Markdown end for at kæmpe med WordPress’ blok-editor.</p>`
Hvorfor Astro</h2>
Jeg overvejede Hugo, 11ty, Next.js static export og SvelteKit. Astro vandt på tre konkrete punkter:</p>

Content collections.</strong> En typet, skema-kontrolleret måde at beskrive et portfolio-projekt som en mappe med fotos plus lidt front-matter. Buildet fejler højlydt, hvis noget ikke overholder skemaet. Intet CMS nødvendigt.</li>
`<Image></code>-komponenten.</strong> Astros indbyggede billedpipeline håndterer AVIF + JPEG-fallback + srcset</code> + width</code>/height</code> med en one-liner. Sharp er motoren under.</li>`
`Islands-arkitektur — ikke relevant her.</strong> Siden har ingen interaktive komponenter, så den sender stort set ingen JavaScript.</li> </ol>`Content collections, ikke et CMS</h2>
Hvert portfolio-projekt er en mappe under `src/content/portfolio/</code> med et front-matter-skema:</p>`
src/content/portfolio/ ├── 2024-kogebogs-editorial/ │ ├── index.mdx │ ├── cover.jpg │ ├── 01.jpg, 02.jpg, … └── 2023-forarets-katalog/ ├── index.mdx ├── cover.jpg └── 01.jpg … </code></pre> index.mdx</code>’s front-matter deklarerer titel, kategori, år og forsidebillede. Astro håndhæver skemaet ved build-tid via defineCollection</code></a> med et Zod-skema. Hvis et projekt mangler et forsidebillede eller har en dårlig kategori, fejler buildet.</p> Kategorier: madfotografi, opskriftsudvikling, interiør- og haveproduktion, editorial, kogebøger og mode</strong>. At tilføje et nyt projekt er mkdir</code> + cp *.jpg</code> + en kort YAML-front-matter-blok. Ingen admin-UI, ingen database-migration, ingen cache at invalidere.</p> Billedpipeline: Sharp + AVIF</h2> Madfotografi står og falder med billedkvalitet. Astros <Image></code>-komponent — drevet af Sharp</a> — genererer:</p> AVIF</strong> som primært format. Stort set alle moderne browsere understøtter det nu (se caniuse</a>).</li> JPEG</strong>-fallback med matchende srcset</code>-breakpoints (320, 640, 960, 1280, 1920 px).</li> Eksplicitte width</code>- og height</code>-attributter, så der er nul layout shift, mens billederne loader.</li> loading="lazy"</code> til billeder under folden og fetchpriority="high"</code> til heroet.</li> </ul> Tal</strong>: en typisk portfolio-side gik fra ~4,8 MB håndeksporterede JPEG’er til ~1,4 MB AVIF — omkring 70 % reduktion — uden synligt kvalitetstab i de viste størrelser.</p> i18n — dansk som standard, engelsk på /en/</h2> Astros i18n-routing sidder i astro.config.mjs</code>:</p> export default defineConfig({ i18n: { defaultLocale: "da", locales: ["da", "en"], routing: { prefixDefaultLocale: false }, }, }); </code></pre> Det giver:</p> /</code> for dansk (standard, uden præfiks).</li> /en/</code> for engelsk.</li> Hvert indholds-entry deklarerer sit sprog via sin collection og filnavn.</li> <link rel="alternate" hreflang></code> og sitemap genereres fra samme kilde.</li> </ul> Indlæg og portfolio-entries uden oversættelse dukker simpelthen ikke op i det andet sprogs routing — der er ingen forkert-sprog-404.</p> Deployment og build</h2> Output</strong>: fuldt statisk, udgivet som almindelige filer bag Cloudflare.</li> Build-tid</strong>: ~30 sekunder fra koldt cache, ~6 sekunder inkrementelt.</li> Ingen server, ingen database, ingen løbende kørselstid.</strong></li> </ul> Målbare forbedringer</h2> Mål</th> WordPress (før)</th> Astro (efter)</th></tr></thead> Build / deploy-tid</td> ikke relevant</td> ~30 s koldt, ~6 s varmt</td></tr> Typisk sidestørrelse (portfolio-side)</td> ~4,8 MB</td> ~1,4 MB</td></tr> Largest Contentful Paint</td> ~2,8 s</td> ~0,9 s</td></tr> Time to Interactive</td> ~3,5 s</td> ~1,1 s</td></tr> JS sendt til klienten</td> ~220 KB</td> ~0 KB</td></tr> Plugins at holde patchet</td> 14</td> 0</td></tr> </tbody></table> Ofte stillede spørgsmål</h2> Kan en ikke-teknisk ejer stadig redigere siden?</h3> Ja, til tekstændringer. At redigere Markdown i GitHubs web-editor er i praksis lettere end WordPress’ blok-editor. For nye portfolio-projekter er workflowet: træk billeder ind i en mappe, skriv en lille front-matter-blok, commit. Er det for teknisk, kan man bolte en minimal admin på (Decap CMS, Sveltia CMS eller Keystatic).</p> Hvad med SEO efter flytningen?</h3> URL’er blev bevaret, hvor det var muligt. Manglende gamle stier omdirigeres via Cloudflare-regler. Sitemap genereres ved hvert build, og strukturerede data (Person</code>, ImageGallery</code>, Article</code>) udsendes pr. side.</p> Hvorfor Astro og ikke Hugo?</h3> Hugo er hurtigere og simplere til ren blogging, men Astros typede content collections og førsteklasses <Image></code>-komponent vandt i det her tilfælde. Til x2q.net</a> selv endte jeg senere med Zola — men til en portfolio med tung billedpipeline var Astro det rigtige valg.</p> Hvordan holdes billederne organiseret?</h3> Hvert portfolio-projekt har sin egen mappe. Git-repoet er CMS’et. git log</code> fortæller, hvornår et billede blev tilføjet, og hvorfor.</p> Er buildet deterministisk?</h3> Ja. Samme input giver bit-for-bit identisk output. Sharp er pinned i package.json</code>; det samme er Astro. CI kører på Node LTS.</p> Hvis du sidder med et WordPress-site, der laver langt mindre, end dets infrastruktur antyder, er Astro en eftermiddag værd.</p> apextowww.com — gratis apex-til-www-omdirigering 2026-04-18T00:00:00+00:00 TL;DR —</strong> DNS tillader ikke CNAME</code>-records på zoneapex (RFC 1034 §3.6.2</a>). Det er derfor hostingplatforme som Netlify, Vercel, Cloudflare Pages, Firebase og Heroku beder dig om at sætte www.eksempel.dk</code> op med en CNAME</code> og lader eksempel.dk</code> (selve apex) være et problem, du selv løser. apextowww.com</a> løser det: peg to A</code>-records og to AAAA</code>-records mod tjenesten, og den udsteder et Let’s Encrypt-certifikat til dit apex og 301</code>-omdirigerer hver forespørgsel til https://www.ditdomæne.tld/</code> — med sti og querystring bevaret. Gratis, ingen oprettelse, ingen konto.</p> Hvorfor du ikke kan sætte en CNAME på apex</h2> DNS-specifikationen er entydig: en zoneapex (det “nøgne” domæne som eksempel.dk</code>) skal have en SOA</code>-record og som regel NS</code>-records. CNAME</code> er defineret som et alias, der skal stå alene — den må ikke sameksistere med de SOA</code>- og NS</code>-records, som apex er forpligtet til at have. Derfor kan du godt CNAME www.eksempel.dk → mitsite.netlify.app</code>, men du kan ikke</strong> CNAME eksempel.dk → mitsite.netlify.app</code>.</p> Der findes workarounds, og alle er en smule akavede:</p> ALIAS- / ANAME-records.</strong> Leverandørspecifikke hos Cloudflare, Route 53, DNSimple, NS1 og andre. De virker ved at slå målet op bag kulisserne og returnere en A</code>/AAAA</code>. Fint, hvis din DNS-udbyder understøtter det; ubrugeligt, hvis ikke.</li> Fladning på udbyderniveau.</strong> Cloudflares “CNAME flattening” er præcis det, gjort automatisk.</li> Din egen altid-tændte VPS med 301 → www</code>.</strong> Det var det, jeg gjorde for flere domæner — både overkill og en lille vedligeholdelsesskat.</li> </ul> apextowww er den fjerde mulighed: en andens altid-tændte omdirigerer, driftet for dig.</p> Hvad apextowww gør</h2> Nøjagtig én ting: en 301 Moved Permanently</code> fra https://ditdomæne.tld/noget?x=y</code> til https://www.ditdomæne.tld/noget?x=y</code>.</p> TLS</strong> udstedes automatisk ved første forespørgsel via Let’s Encrypts HTTP-01-challenge. Ingen ACME-klient at køre selv.</li> IPv4 + IPv6</strong> som dual-stack fra starten. Begge record-typer er påkrævet.</li> HTTP/1.1, HTTP/2 og HTTP/3</strong> serveres. Selve omdirigeringen er lille, så protokolversion betyder mindre, men det hjælper first-paint, når omdirigeringen ligger i den kritiske sti.</li> Sti og querystring</strong> bevares, så deep links stadig virker.</li> Ingen oprettelse, intet login, ingen konto.</strong> Hvis DNS er peget korrekt, virker det bare.</li> </ul> Sådan sætter du det op</h2> Gå til apextowww.com</a> og kopiér de aktuelle IP-adresser (to IPv4, to IPv6).</li> I din DNS-udbyder: sæt A</code>-records på dit apex, der peger på de to IPv4-adresser. Fjern eventuelle eksisterende A</code>-records på apex.</li> Sæt AAAA</code>-records på dit apex, der peger på de to IPv6-adresser.</li> Sørg for, at www.ditdomæne.tld</code> stadig peger på din rigtige host (CNAME til Netlify / Vercel / Pages / osv.).</li> Vent på DNS-propagering. Besøg http://ditdomæne.tld/</code> — den skal nu 301-omdirigere til https://www.ditdomæne.tld/</code>.</li> </ol> apextowww-siden har platform-specifikke guides under /netlify-apex-domain-redirect/</code>, /vercel-apex-domain-redirect/</code>, /cloudflare-pages-apex-redirect/</code>, /firebase-hosting-apex-redirect/</code> og /heroku-apex-domain-redirect/</code>.</p> Stak</h2> Hetzner ARM64</strong>-servere for billig, strømbesparende compute. ARM64 er ~30 % billigere pr. vCPU hos Hetzner end x86 og kører omdirigereren uden at ryste på hånden.</li> Caddy-agtig automatisk TLS</strong> med Let’s Encrypt</strong> HTTP-01-challenges.</li> Dual-stack IPv4 + IPv6</strong>.</li> HTTP/1.1, HTTP/2, HTTP/3</strong>.</li> Offentligt statisk marketing-site</strong> på Cloudflare Pages, med platform-guides i hver sin URL-sti, så de rangerer uafhængigt på Google for “netlify apex redirect”, “vercel apex domain” osv.</li> </ul> Ofte stillede spørgsmål</h2> Kan jeg bruge apextowww sammen med Cloudflare DNS?</h3> Ja — men du skal have Cloudflares proxy (den orange sky) slået fra</strong> på apex’ens A</code>/AAAA</code>-records. Hvis proxien er slået til, opfanger Cloudflare forespørgslen, og Let’s Encrypts HTTP-01-challenge når aldrig frem til apextowww. Når certifikatet er udstedt og fornyes, skal du ikke bøvle videre — bare lad det være slukket.</p> Understøtter apextowww wildcards eller andre subdomæner end www?</h3> Nej. Tjenesten omdirigerer kun apex til www.</code>. Alt andet bliver liggende hos din rigtige host.</p> Hvad sker der, hvis apextowww-IP’erne skifter?</h3> Så skal du opdatere dine DNS A</code>/AAAA</code>-records. Operatøren offentliggør aktuelle IP’er på forsiden og giver varsel før ændringer. Det er fint for et privat domæne; for noget missionkritisk bør du køre din egen omdirigerer.</p> Er der rate-limit?</h3> Der er ingen publiceret hård grænse, men det er en gratis community-tjeneste. Hvis du serverer millioner af apex-omdirigeringer i døgnet, er det tid til at selv-hoste.</p> Hvorfor ikke bare bruge Cloudflares gratis plan?</h3> Cloudflares CNAME-flattening på apex er et fint alternativ, hvis hele din DNS er hos Cloudflare. apextowww er nyttig, når din DNS ikke er hos Cloudflare, eller når du vil have en host-agnostisk omdirigerer, der virker identisk på tværs af domæner.</p> Er den virkelig gratis?</h3> Ja. Marginalomkostningen pr. omdirigering på ARM64 er minimal. Ingen reklamer, ingen tracking ud over grundlæggende logs, ingen upsell.</p> Hvorfor den findes</h2> Hostingplatforme optimerer efter deres egen onboarding, ikke efter de DNS-selvfølgeligheder, der snubler enhver ny bruger. Det føltes værre at sende folk videre til en fremmeds VPS end selv at drifte én. Nu peger mine egne apex-domæner (inklusive x2q.net</a>) på apextowww, og jeg har kunnet slukke for den sidste lille omdirigerer-VPS, jeg stadig kørte af historiske grunde.</p> Det er den slags projekt, der ikke virker interessant, før du har brug for det — og så er det lige præcis det, du skal bruge.</p>

Ofte stillede spørgsmål</h2>

apextowww.com — gratis apex-til-www-omdirigering

Ofte stillede spørgsmål</h2>

x2q

elpriser.org — danske elpriser time for time

Ofte stillede spørgsmål</h2>

winniemethmann.com — fra WordPress til Astro

x2q

elpriser.org — danske elpriser time for time

Ofte stillede spørgsmål</h2>

winniemethmann.com — fra WordPress til Astro

Ofte stillede spørgsmål</h2>

apextowww.com — gratis apex-til-www-omdirigering

Ofte stillede spørgsmål</h2>