Build a Fast, SEO-Friendly Portfolio Website From Scratch

Why your portfolio site is your highest-leverage page

Of every page I've ever shipped, my own portfolio gets the least "creative freedom" and the most scrutiny. A client's landing page has to convert; my portfolio has to prove I can be trusted to build that landing page in the first place. Recruiters, founders and other developers all check the same three things in the first ten seconds: does it load instantly, does it feel considered, and does it show up when someone searches your name. Get those right and the rest of the site can do the talking.

That's really what this post is about. Not the fun animation ideas, but the unglamorous groundwork underneath them: markup, performance, metadata. Everything else is decoration on top of that.

Start with semantic, accessible HTML

Before I touch a single line of CSS, I sketch the page as plain HTML: headings, landmarks, lists, buttons that are actual <button> elements instead of a div with an onclick stuck on it. Div soup is an accessibility problem and an SEO problem at the same time, because search engines (and increasingly, AI answer engines) lean heavily on document structure to work out what a page is actually about.

A few rules I try not to break:

• Exactly one <h1> per page that says, in plain language, what the page is actually for. Not a decorative headline, the real one, even if it's visually hidden.
• Headings nest in order (h1 → h2 → h3) instead of jumping levels for a font-size shortcut.
• <nav>, <main>, <header> and <footer> mark the actual regions of the page, not just styled divs.
• Every interactive element gets a real, descriptive aria-label or visible text. "Click here" tells a screen reader (and a search crawler) nothing useful.

Search engines can't see your design. They read your markup and infer everything else.

Performance is a design decision

I don't treat speed as a checklist to run at the end. It's a series of small choices made while you're building, and there are three places I pay attention to on every project:

Images

Ship .webp, set explicit width/height so the browser can reserve space before the image loads (no layout shift), use loading="lazy" on anything below the fold, and fetchpriority="high" on the one hero image that actually needs to appear first.

Fonts

Google Fonts is convenient, but every extra weight you request is extra render-blocking time. I preconnect to fonts.googleapis.com and fonts.gstatic.com, then load only the specific weights I'll actually use, not the whole family.

JavaScript

A single scroll-triggered animation doesn't need a heavyweight framework. I reach for something like anime.js or GSAP only when the interaction earns it, and I load third-party scripts (chat widgets, analytics) after the page is interactive, not before.

On-page SEO that actually moves the needle

Structured data and clever tricks get a lot of attention, but most of the ranking work happens in five boring tags that people forget to customize per page:

• Unique title and description on every page. Copy-pasting your homepage's meta description onto your contact page tells Google the two pages are interchangeable. They aren't.
• A canonical URL on every page, even ones that don't need it yet, so you never accidentally get penalized for duplicate content later.
• Open Graph and Twitter card tags so links shared on WhatsApp, LinkedIn or X render an image and description instead of a bare URL.
• Descriptive, human-readable URLs. Something like /blog/build-fast-seo-friendly-portfolio-website.html tells a reader (and a crawler) what the page's about before they even click.
• Internal links between related pages. This post links back to my blog and my contact page, which helps readers and crawlers both understand how the site fits together.

Structured data: teach Google (and AI) who you are

JSON-LD structured data doesn't change how a page looks, but it removes the guesswork for machines reading it. It's how I tell a crawler, explicitly, "this is a Person, this is their job title, this is the Organization they work for" instead of hoping it infers that correctly from prose. A minimal example for a personal site:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Your Name",
  "url": "https://yoursite.com/",
  "jobTitle": "Web Developer",
  "sameAs": [
    "https://www.linkedin.com/in/yourprofile/",
    "https://github.com/yourhandle"
  ]
}

Add a BreadcrumbList on every non-home page, and, if your site answers common questions, an FAQPage block that mirrors what's actually on the page. Never mark up content that isn't shown to visitors. It's against Google's structured data guidelines, and it can get your rich result pulled entirely.

A Core Web Vitals checklist before you ship

• Largest Contentful Paint under about 2.5s. It's usually your hero image or heading, so preload it.
• Cumulative Layout Shift near zero. Reserve space for images, ads and web fonts before they load in.
• Interaction to Next Paint under 200ms. Keep your main thread free of long-running scripts.
• Mobile-first: test on an actual mid-range phone, not just Chrome DevTools' emulator.
• Run PageSpeed Insights and Search Console's URL Inspection tool after every major change, not just once at launch.

Mistakes I see most often

Almost every slow or invisible portfolio site I've audited has the same handful of problems. A hero video or an unoptimized PNG loaded at full resolution. A title tag that's just the person's name and nothing else. No canonical tag at all. Animations that block the main thread on first load. None of it is hard to fix. It's just easy to forget when you're busy making the site look good.

Build the boring parts first. The fun parts are more fun when they're sitting on something fast.