How I Rebuilt IvyyDev.se: Faster, Better SEO, Easier to Maintain

I recently rebuilt ivyydev.se from the ground up. The goal was simple: a faster site, SEO done right from the start, and a workflow where I can ship blog and portfolio updates without fighting the tooling. I focused on what actually moves the needle – speed, search visibility and maintainable code. Below is how the architecture and the fixes I made in the code work in practice.

TL;DR: I rebuilt ivyydev.se on React, Vite, TypeScript, and Tailwind with one SEOHead component, cleaner publishing in Git, and concrete fixes for CLS, FCP, and TBT. Result: faster pages, stronger SEO, and easier maintenance on Vercel.

Why rebuild?

The old setup worked for static pages, but every new article or portfolio piece took too long and SEO was scattered. I wanted a small, modern stack with no extra friction: React + Vite + TypeScript, Tailwind for styling and a consistent UI kit. No team – just me and the codebase.

Architecture in code

• React + Vite + TypeScript – fast dev loop and clear types. Vite manualChunks splits react, router, query and radix into separate chunks so the main bundle stays smaller and TBT (Total Blocking Time) goes down.
• Tailwind – consistent design; CSS variables for theme and shared utilities like section-blend-after-hero and content-visibility-auto.
• A single SEOHead component – each page passes title, description, canonical, hreflang, schema. The component sets document title, meta description/keywords, canonical link, hreflang links (including x-default), Open Graph, Twitter Cards and injects JSON-LD (e.g. BlogPosting and BreadcrumbList via generateArticleSchema / generateBreadcrumbSchema). All SEO in one place.
• Blog and portfolio – same page layout: breadcrumb, h1, meta, article. Content lives in TSX files, versioned in Git.
• PageHero – inner pages (web development, locations, privacy, etc.) use the same hero as the home page: same background image (avif/webp), gradient, grid, orbs and hero-fade-bottom for a smooth transition into the next section.

More on the project in the portfolio entry.

Problems I solved (and how)

During the rebuild I hit a few concrete performance and UX issues and fixed them in the code:

• CLS (Cumulative Layout Shift): The home page sections Services, About and Testimonials are lazy-loaded after requestIdleCallback so first paint stays fast. When they mounted, they pushed the next section down and caused a big layout shift. Fix: a wrapper with min-h-[1400px] sm:min-h-[1600px] around the lazy sections so space is reserved from first paint. The next section stays put and CLS drops.
• FCP/LCP: The main stylesheet was blocking render. I added a Vite plugin (cssAsyncLoad) that at build time switches the stylesheet link to media="print" onload="this.media='all'" plus a noscript fallback, so CSS doesn’t block first paint.
• Main thread / TBT: Analytics and CookieBanner don’t mount immediately. In App.tsx I wait for requestIdleCallback (with a 2000 ms timeout, else 500 ms) before setting deferredReady and rendering them. Below-the-fold sections use content-visibility: auto so the browser can skip layout for off-screen content.
• Consistent hero: Inner pages had their own gradient-hero blocks and looked different. I introduced PageHero with the same background, grid and glow as the home Hero, and added section-blend-after-hero in CSS so the first content section gets a smooth gradient transition instead of a hard edge.

SEO and performance in practice

SEO is handled entirely in SEOHead: canonical, hreflang (EN/SV + x-default), Open Graph, Twitter Cards and a single script type="application/ld+json" that updates on navigation. Blog posts use generateArticleSchema and generateBreadcrumbSchema so both the article and breadcrumbs get structured data. A clean sitemap and redirects for old URLs keep indexing straight. Builds are fast and Core Web Vitals (LCP, CLS, INP) stay in good shape – important for both users and ranking.

More technical depth: load balancing with Nginx and my services for web and automation.

Publishing flow

Articles and portfolio items are TypeScript files with the same component layout. Content sits next to code, versioned in Git, and I can iterate quickly. No CMS – just code and content in the same repo.

Hosting

The site runs on Vercel: previews per branch and straightforward production deploys. Builds are fast and I don’t have to manage a server myself.

What’s next

I’m considering a lightweight CMS bridge for drafts and scheduled posts, but I’m keeping the code-first approach. If you want to build something similar, with a fast site, good SEO, and clear structure, you can get in touch or request a free prototype. If you proceed, normal prices apply by scope.

Frequently asked questions

What stack does ivyydev.se use?

React, Vite, TypeScript, and Tailwind, hosted on Vercel. SEO is centralized in one SEOHead component with canonical, hreflang, Open Graph, and JSON-LD.

Why rebuild instead of patching the old site?

The old setup made new articles and portfolio updates slow, and SEO was scattered. A small modern stack cut friction and made Core Web Vitals easier to keep healthy.

How is SEO handled on the site?

Each page passes title, description, canonical, hreflang, and schema into SEOHead. Blog posts use article and breadcrumb schemas so structured data stays consistent.

What performance fixes mattered most?

Reserving height for lazy sections to cut CLS, async CSS loading for faster first paint, deferred analytics and cookie UI for lower TBT, and content-visibility for below-the-fold sections.

Can you build a similar site for a small business?

Yes. The same code-first approach works for small business sites that need speed, clear SEO, and a maintainable publishing flow. Start with a free prototype; if you proceed, normal prices apply by scope.