winniemethmann.com — from WordPress to Astro

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

`Why move off WordPress</h2> For a portfolio that changes a few times a month, WordPress was doing too much work:</p>`

PHP runtime and MySQL</strong> for a site that is functionally static.</li>
Dozens of plugins</strong> for image galleries, contact forms, SEO, caching — each with its own update cadence and security disclosures.</li>
A half-forked theme</strong> that had accumulated patches nobody remembered why.</li>
An admin login endpoint</strong> that was probed several thousand times a day by bots.</li>
Regular caching headaches</strong> every time the CDN and the plugins disagreed.</li> </ul>
Concretely, dropping WordPress meant:</p>

No admin panel to keep patched.</strong> WordPress core releases, plugin updates, theme updates — gone.</li>
No database.</strong> Content lives as Markdown in the repo.</li>
No login surface for bots to probe.</strong> There’s no `/wp-admin/</code> anymore.</li>`
`~10× faster page loads</strong> with no caching layer required.</li>`
`~70% smaller total build size</strong>, swapping hand-exported JPEGs for AVIF at sensible srcset</code> breakpoints.</li> </ul> The tradeoff is that non-technical editing goes away. In practice that did not matter: the site owner was happier editing Markdown than fighting the WordPress block editor.</p>`
Why Astro</h2>
I considered Hugo, 11ty, Next.js static export, and SvelteKit. Astro won on three specific points:</p>

Content collections.</strong> A typed, schema-checked way to describe a portfolio project as a directory of photos plus some front-matter. Build fails loudly if anything is malformed. No CMS required.</li>
The `<Image></code> component.</strong> Astro’s built-in image pipeline handles AVIF + JPEG fallback + srcset</code> + width</code>/height</code> attributes with a one-liner. Sharp is the engine under the hood.</li>`
`Islands architecture, not relevant here.</strong> The site has no interactive components, so it ships basically zero JavaScript.</li> </ol>`Content collections, not a CMS</h2>
Each portfolio project is a directory under `src/content/portfolio/</code> with a front-matter schema:</p>`
src/content/portfolio/ ├── 2024-cookbook-editorial/ │ ├── index.mdx │ ├── cover.jpg │ ├── 01.jpg, 02.jpg, … └── 2023-spring-catalogue/ ├── index.mdx ├── cover.jpg └── 01.jpg … </code></pre> index.mdx</code> front-matter declares the project title, category, year, and cover image. Astro enforces the schema at build time via defineCollection</code></a> with a Zod schema. If a project is missing a cover image or has a bad category, the build fails.</p> Categories used: food photography, recipe development, interior & garden styling, editorial, cookbooks, and fashion</strong>. Adding a new project is mkdir</code> + cp *.jpg</code> + a short YAML front-matter block. No admin UI, no database migration, no cache to invalidate.</p> Image pipeline: Sharp + AVIF</h2> Food photography lives or dies on image quality. Astro’s <Image></code> component, powered by Sharp</a>, generates:</p> AVIF</strong> as the primary format. Roughly all modern browsers support it now (see caniuse</a>).</li> JPEG</strong> fallback with matching srcset</code> breakpoints (320, 640, 960, 1280, 1920 px).</li> Explicit width</code> and height</code> attributes, so there is zero cumulative layout shift while images load.</li> loading="lazy"</code> for below-the-fold images and fetchpriority="high"</code> for the hero.</li> </ul> Numbers</strong>: a typical portfolio page went from ~4.8 MB of hand-exported JPEGs to ~1.4 MB of AVIF — about a 70% reduction — with no visible quality loss at typical display sizes.</p> i18n — Danish default, English at /en/</h2> Astro’s i18n routing sits in astro.config.mjs</code>:</p> export default defineConfig({ i18n: { defaultLocale: "da", locales: ["da", "en"], routing: { prefixDefaultLocale: false }, }, }); </code></pre> That gives:</p> /</code> for Danish (the default, no prefix).</li> /en/</code> for English.</li> Each content entry declares its language via its collection and filename.</li> <link rel="alternate" hreflang></code> and the sitemap are generated from the same source.</li> </ul> Posts and portfolio entries that lack a translation simply don’t appear in the other locale’s routing — they don’t 404 to a wrong-language page.</p> Deployment and build</h2> Output</strong>: fully static, deployed as plain files behind Cloudflare.</li> Build time</strong>: ~30 seconds on a cold cache, ~6 seconds incrementally.</li> No server, no database, no runtime cost.</strong></li> </ul> Measurable outcomes</h2> Metric</th> WordPress (before)</th> Astro (after)</th></tr></thead> Build / deploy time</td> n/a (instant publish)</td> ~30s cold, ~6s warm</td></tr> Typical page size (portfolio page)</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 shipped</td> ~220 KB</td> ~0 KB</td></tr> Plugins to keep patched</td> 14</td> 0</td></tr> </tbody></table> FAQ</h2> Can a non-technical owner still edit the site?</h3> Yes, for copy. Editing Markdown in a GitHub web editor is, in practice, easier than the WordPress block editor. For new portfolio projects, the workflow is: drag images into a folder, write a short front-matter block, commit. If that’s too technical, a one-page admin (Decap CMS / Sveltia CMS / Keystatic) can be bolted on.</p> What about SEO after the migration?</h3> URLs were kept as-is wherever possible. Missing old paths redirect via Cloudflare rules. The sitemap is regenerated on every build, and structured data (Person</code>, ImageGallery</code>, Article</code>) is emitted per page.</p> Why Astro and not Hugo?</h3> Hugo is faster and simpler for pure blogging, but Astro’s typed content collections and first-class <Image></code> component won this case. For x2q.net</a> itself, I later went with Zola — for a portfolio with a heavy image pipeline, Astro remained the better fit.</p> How do images stay organised?</h3> Each portfolio project owns its own folder. The Git repo is the CMS. git log</code> tells you when an image was added and why.</p> Is the build deterministic?</h3> Yes. Given the same inputs, the output is byte-for-byte identical. Sharp is pinned in package.json</code>; so is Astro. CI runs on Node LTS.</p> If you’re on a WordPress site that’s doing far less than its infrastructure suggests, Astro is worth the afternoon it takes to try.</p> apextowww.com — a free apex-to-www redirect service 2026-04-18T00:00:00+00:00 TL;DR —</strong> DNS does not allow CNAME</code> records at the zone apex (RFC 1034 §3.6.2</a>). That’s why hosts like Netlify, Vercel, Cloudflare Pages, Firebase, and Heroku ask you to configure www.example.com</code> with a CNAME</code> and leave example.com</code> (the apex) as a problem. apextowww.com</a> solves it: point two A</code> records and two AAAA</code> records at the service, and it issues a Let’s Encrypt certificate for your apex and 301</code>-redirects every request to https://www.yourdomain.tld/</code>, preserving path and query string. Free, no signup, no account.</p> Why you can’t put a CNAME on the apex</h2> The DNS spec is unambiguous: a zone apex (the “bare” domain like example.com</code>) must carry an SOA</code> record and usually NS</code> records. CNAME</code> is defined as an alias that must be the only record at a name, and it is forbidden to coexist with the SOA</code> and NS</code> records that the apex is required to have. That’s why you can CNAME www.example.com → mysite.netlify.app</code> but you cannot</strong> CNAME example.com → mysite.netlify.app</code>.</p> Workarounds exist, and all of them are a little awkward:</p> ALIAS / ANAME records.</strong> Proprietary to each DNS provider (Cloudflare, Route 53, DNSimple, NS1). They work by resolving the target behind the scenes and returning an A</code>/AAAA</code>. Fine if your DNS provider supports it; useless if it doesn’t.</li> Flattening at the provider level.</strong> Cloudflare’s “CNAME flattening” is this, done automatically for you.</li> Your own always-on VPS doing 301 → www</code>.</strong> This is what I was doing for multiple domains, and it’s both over-engineered and a small maintenance tax.</li> </ul> apextowww is the fourth option: somebody else’s always-on redirector, managed for you.</p> What apextowww does</h2> Exactly one thing: a 301 Moved Permanently</code> from https://yourdomain.tld/anything?x=y</code> to https://www.yourdomain.tld/anything?x=y</code>.</p> TLS</strong> is issued automatically on first request via the Let’s Encrypt HTTP-01 challenge. No ACME client to run yourself.</li> IPv4 + IPv6</strong> on dual-stack by design. Both apex records are required.</li> HTTP/1.1, HTTP/2, and HTTP/3</strong> are all served. The redirect itself is trivially small, so protocol version matters less, but it helps the first-paint story when the redirect is on the critical path.</li> Path and query string</strong> are preserved, so deep links keep working.</li> No signup, no login, no account.</strong> If your DNS is pointed correctly, it just works.</li> </ul> How to set it up</h2> Go to apextowww.com</a> and copy the current IP addresses (two IPv4, two IPv6).</li> In your DNS provider, set A</code> records on your apex pointing at the two IPv4 addresses. Remove any existing A</code> record at the apex.</li> Set AAAA</code> records on your apex pointing at the two IPv6 addresses.</li> Make sure www.yourdomain.tld</code> still points at your real host (CNAME to Netlify/Vercel/Pages/etc).</li> Wait for DNS to propagate. Visit http://yourdomain.tld/</code> — it should 301 to https://www.yourdomain.tld/</code>.</li> </ol> The apextowww site has per-platform walkthroughs at /netlify-apex-domain-redirect/</code>, /vercel-apex-domain-redirect/</code>, /cloudflare-pages-apex-redirect/</code>, /firebase-hosting-apex-redirect/</code>, and /heroku-apex-domain-redirect/</code>.</p> Stack</h2> Hetzner ARM64</strong> servers, for cheap, low-power compute. ARM64 is ~30% cheaper per vCPU at Hetzner than x86 and runs the redirector fine.</li> Caddy-style automatic TLS</strong> with Let’s Encrypt</strong> HTTP-01 challenges.</li> Dual-stack IPv4 + IPv6</strong>.</li> HTTP/1.1, HTTP/2, HTTP/3</strong>.</li> Public static marketing site</strong> on Cloudflare Pages, with per-platform guides in separate URL paths so they each rank independently on Google for “netlify apex redirect”, “vercel apex domain”, etc.</li> </ul> FAQ</h2> Can I use apextowww with Cloudflare DNS?</h3> Yes, but you’ll want Cloudflare’s proxy (orange cloud) off</strong> for the apex A</code>/AAAA</code> records. If the proxy is on, Cloudflare intercepts the request and Let’s Encrypt’s HTTP-01 challenge won’t reach apextowww. Once the certificate is issued and renewed, you don’t need to toggle anything manually; just keep it off.</p> Does apextowww support wildcards or redirecting subdomains other than www?</h3> No. The service only redirects the apex to www.</code>. Everything else stays on your real host.</p> What happens if the apextowww IPs change?</h3> You’ll need to update your DNS A</code>/AAAA</code> records. The operator publishes current IPs on the homepage and gives advance notice for changes. For a personal domain this is fine; for anything mission-critical, run your own redirector.</p> Is there a rate limit?</h3> There’s no published hard limit, but this is a free community service. If you’re serving millions of apex redirects a day, self-host.</p> Why not just use Cloudflare’s free plan?</h3> Cloudflare’s CNAME flattening at the apex is a perfectly reasonable alternative if your whole DNS is on Cloudflare. apextowww is useful when your DNS isn’t on Cloudflare, or when you want a host-agnostic redirector that works identically across domains.</p> Is it really free?</h3> Yes. The marginal cost per redirect on ARM64 is negligible. No ads, no tracking beyond basic logs, no upsell.</p> Why it exists</h2> Hosting platforms optimise for their own onboarding, not for the DNS truisms that trip up every new user. Sending people to a stranger’s VPS felt worse than running one myself. Now my own apex domains (including x2q.net</a>) point at apextowww, which means I could tear down the last little redirector VPS I still had running for historical reasons.</p> It’s the kind of project that isn’t interesting until you need it, and then it’s the only thing you need.</p>

FAQ</h2>

apextowww.com — a free apex-to-www redirect service

FAQ</h2>

x2q

elpriser.org — Danish hourly electricity prices

FAQ</h2>

winniemethmann.com — from WordPress to Astro

x2q

elpriser.org — Danish hourly electricity prices

FAQ</h2>

winniemethmann.com — from WordPress to Astro

FAQ</h2>

apextowww.com — a free apex-to-www redirect service

FAQ</h2>