DEV Community

Cover image for Modernizing my Portfolio: From Vanilla PHP to Next.js (and why my server thought I was DDOSing it)
Hendrik Haustein
Hendrik Haustein

Posted on • Originally published at haustein.in

Modernizing my Portfolio: From Vanilla PHP to Next.js (and why my server thought I was DDOSing it)

A deep dive into migrating my portfolio to Next.js, optimizing for SEO 2026, and the pitfalls of prefetching on shared hosting.

Modernizing my Portfolio Website

In web engineering, standing still is not an option. My portfolio is more than just a digital business card; it's my sandbox for testing modern web architectures. To meet the performance, scalability, and SEO requirements of 2026, I've completely rethought the entire infrastructure.

Before: PHP & Tailwind CSS

Design before with PHP and Tailwind CSS. Intro.

Design before with PHP and Tailwind CSS. About.

Design before with PHP and Tailwind CSS. Portfolio.

What a sh... bad design, or?

After: Next.js and Tailwind CSS

Design with NextJS and Tailwind CSS.

Design with NextJS and Tailwind CSS: New About

Design with NextJS and Tailwind CSS: New Section

Design with NextJS and Tailwind CSS: New Portfolio

Design with NextJS and Tailwind CSS: New contact me

New, clean, fast, and smooth. I love this new design. While I know there are countless incredibly creative designers out there—whose work I truly admire—this transition is a milestone for me. It’s more than just a fresh look; it’s a reflection of my evolution as a (Spring Boot) developer.

Tech Change: From Vanilla PHP to React/Next.js

While vanilla PHP served me well for years, the desire for a seamless user experience and optimized rendering required a technology pivot. Switching to Next.js allows me to utilize Static Site Generation (SSG).

  • Before: Server-side rendering on every request, wasting precious milliseconds.

  • Now: Pre-rendered HTML pages served instantly. The result is an "instant-on" experience. If I ever need dynamic data, I can easily fetch it via client-side APIs.

SEO Optimizations: The Technical Foundation

Good SEO isn't an add-on; it's rooted deep in the architecture. Inspired by my own SEO strategies for Devs (german) , I've implemented the following:

Schema.org (JSON-LD)

I use structured data to make my identity machine-readable. Via a central Person schema, I link my portfolio to my tools on Blogkurs (a Blog of mine). By using sameAs and rel="me", I validate my identity across different domains.

Semantic HTML5

Code quality means information architecture. By using <main>, <section>, <article>, and correct header hierarchies (h1-h6), I help crawlers understand content relevance without guesswork.

Meta-Management

Thanks to the Next.js Metadata API, every subpage is supplied with dynamic, highly optimized meta tags and OpenGraph images. This ensures better rankings and a professional look when shared on social media.

Speed & Core Web Vitals

Speed is a ranking factor. Through image optimization (WebP/AVIF), font preloading, and eliminating render-blocking scripts, I've achieved top scores in Core Web Vitals.

Old Core Web Vitals stats:

New Core Web Vitals stats:

A real next level. Of course, Accessibility needs more work!

Challenges & Pitfalls: The "Self-DDOS"

Switching to a JS framework increases complexity. Configuring .htaccess for static exports and handling hydration errors requires deep technical knowledge to avoid SEO losses.

A warning on Next.js default behavior:

Features like automatic pre-fetching of the <Link> component should be disabled when using classic shared hosting (Apache).

By default, Next.js prefetches all linked pages as soon as they appear in the viewport. On an Apache server, this can trigger a massive number of requests in a very short time. Security modules like mod_evasive or fail2ban often interpret this as a DDOS attack.

This happened to me during a static export: my server automatically blocked my IP. The fix? Setting prefetch={false} to maintain control over the request volume.

I recommend using a wrapper:

import Link, { LinkProps } from 'next/link';
import { ReactNode } from 'react';

interface SafeLinkProps extends LinkProps { 
  children: ReactNode; 
  className?: string; 
}

export default function SafeLink({ children, ...props }: SafeLinkProps) {
  return (
    <Link {...props} prefetch={false}>
      {children}
    </Link>
  );
}
Enter fullscreen mode Exit fullscreen mode

Why CMS like WordPress slow me down

Classic CMS like WordPress limit my workflow. I become unproductive when forced to use bulky WYSIWYG editors and cluttered menus. A CMS often feels like a foreign body in a developer's workflow. It forces a structure on me that blocks my creativity and speed.

My New Workflow: Markdown & Full Control

Instead, I chose an architecture that fits seamlessly into my dev environment:

  • Markdown (MDX) as Standard: I write content where I write code – in my IDE. It's fast, clean, and versionable.

  • No compromises on design: Customizing every page with React and Tailwind CSS makes me faster and more relaxed.

  • Version Control via Git: Every content update is a commit. Full history, branches, and clean deployments.

MDX in IDE: Dev UX!
This is Dev UX!

Conclusion

The switch to Next.js wasn't for its own sake. It’s the foundation for positioning my projects as a Trusted Entity on the web. If you build software today, you must speak the language of search engines fluently. For developers who feel uncomfortable in CMS environments, the path via Static Site Generators is the ultimate liberation.

This article was originally published in German on my portfolio: Hendrik Haustein Portfolio.

Top comments (0)