Three generations of my personal site: Gatsby, Next, and Next again

I did not migrate once — I shipped three public generations of the same product. Each URL is a time capsule: Gatsby particles, an intermediate Next deploy on the v2 subdomain, and the current editorial stack on the apex domain.

#TL;DR

I did not migrate once — I shipped three public generations of the same product (my portfolio + writing surface):

Gen 2 and Gen 3 share a repo name (personal-site-v2) but different deploy targets and feature depth. Treating “v2” as only the subdomain and “v3” as the apex domain matches how the URLs actually behave today.

#Generation 1 — Gatsby and GraphQL

When: portfolio-focused years, last refreshed May 2025 on the Gatsby starter lineage.

What it optimized for:

Pain that motivated Gen 2:

• Every new MDX field wanted a GraphQL query or plugin touchpoint.
• gatsby develop rebuild feel when iterating on essays.
• Blog as “occasional posts” not a primary surface.

Gen 1 is not embarrassing — it is a measurable baseline for LCP, bundle, and build time.

#Generation 2 — first Next.js (v2 subdomain)

When: roughly May 2025 → early 2026 on v2.danielastudillo.io (still live; Vercel x-nextjs-prerender headers).

Timeline in personal-site-v2:

What Gen 2 looked like vs Gen 1:

I kept v1 on its subdomain so “before / after” is a real diff. Gen 2 proved Next could own production DNS before I invested in the editorial site on the apex domain.

#Generation 3 — editorial Next (apex domain)

When: June 2026 — the apex domain danielastudillo.io picked up the full editorial revamp plus ongoing MDX expansion (20 posts, reading guide, case-study links).

DNS: Nothing “broke” in the migration so far — it is too early to claim SEO or CWV wins. The operational work was adding CNAME records in Namecheap for v1, v2, and the apex, each pointing at the Vercel DNS targets so all three hostnames stay live for comparison. Gen 2-specific UI on the subdomain is gone from main (overwritten); only the URL snapshot remains.

Stack highlights (current repo):

Visual / UX shift from Gen 1:

• v1: portfolio classic — particles, Bootstrap grid, GraphQL project cards.
• v3: editorial — topic filters, series navigation (BlogReadingGuide), restrained motion, long-form depth for senior loops.

Gen 3 is not “Gen 2 with more CSS.” It is a content product decision: essays are first-class, projects point to narratives, and performance budgets are explicit (image formats, font cache headers, bundle splitting).

#Transition map (engineering view)

Gen 1  Gatsby 5 + GraphQL + particles
         │  pain: essay velocity, GraphQL tax, build feel
         ▼
Gen 2  Next.js @ v2.danielastudillo.io
         │  pain: (fill in) — likely design system + blog scale + CWV targets
         ▼
Gen 3  Next 16 @ danielastudillo.io + MDX + standalone + 20 posts

#Chrome UX Report — field data (June 2026)

PageSpeed Insights surfaces 28-day CrUX p75 metrics under “Discover what your real users are experiencing.” That is not the same as Lighthouse lab scores — it needs enough real Chrome traffic on the exact origin.

That is expected for a personal portfolio: CrUX omits origins below the privacy threshold. Until field data appears, treat Lighthouse lab and RUM you own (Vercel Web Analytics, optional web-vitals beacon) as the honest signals. Re-check PSI after the apex migration has had a full CrUX collection window.

#Lighthouse performance (June 2026, mobile, lab)

Headless Chrome, Lighthouse 12.6 — homepage / (same day, three sequential runs):

Cold curl on the same day showed Gen 1 HTML at ~237 KB vs ~88 KB for both Next URLs — particles and Gatsby payload explain that gap more than the Performance score spread.

Read: Lab scores cluster high-80s/low-90s with near-zero CLS. Gen 1’s Speed Index (4.7 s) and FCP (2.8 s) lag Gen 2 — consistent with tsparticles + heavier first paint. Gen 2’s LCP (3.6 s) is the slowest LCP despite the best FCP/TBT — hero image weight on that deploy. The apex home’s Speed Index (3.8 s) reflects a denser editorial layout, not a failed migration.

#Gen 3 performance budget (repo defaults)

The current next.config.ts encodes choices that did not exist on Gatsby v1:

Gen 2 on the subdomain inherited an earlier slice of this file; Gen 3 is where blog scale (20 MDX posts, reading guide, project ↔ essay links) met explicit bundle and font-cache policy.

#Closing thought

Three URLs beat three README bullets: Gatsby proved static images and GraphQL pipelines; the v2 subdomain proved Next could own DNS; the apex site proved long-form MDX and case-study linking are the product. Name generations by URL + stack, not by repo folder names alone.

#Reader field guide

When to keep prior deploys alive: You are comparing stack generations; recruiters ask for before/after; SEO and CWV need separate origins measured honestly.

Operational checklist

• Map each generation to URL + stack, not folder name alone (v2 subdomain ≠ current apex deploy)
• Replicate routes and slug redirects when moving MDX between frameworks
• Replace gatsby-plugin-image with next/image + explicit sizes during Gatsby → Next moves
• Export metadata / generateMetadata, sitemap.ts, and structured data as code in Gen 3
• Lab Lighthouse on / after each major visual change — CrUX may stay “No Data” on low-traffic personal domains
• Track wall-clock publish cost (gatsby build vs next build) and JS weight on hero, not vibes
• Wire data/projects.ts → blogSlug so projects point at case-study essays

Lab scores to compare (June 2026 mobile homepage): v1 87, v2 91, apex 92 — see Lighthouse table above for LCP/FCP/CLS detail.

#Related reading

#On this site

#References (curated)

Three live URLs are the migration proof; Next and Gatsby docs are for readers planning their own cutover.