DEV Community: suyog bhise

How I Built My Developer Portfolio with Next.js, GSAP, and a 100 SEO Score

suyog bhise — Sat, 14 Mar 2026 18:09:50 +0000

How I Built My Developer Portfolio with Next.js, GSAP, and a 100 SEO Score

Most developer portfolios look the same. A hero section with a name, some project cards, a contact form. They're functional but forgettable.

When I decided to rebuild my portfolio, I had one rule: it should feel like a product, not a template.

This is the full story of building suyogbhise.online — the architecture decisions, the GSAP animation system, the performance problems I created and then fixed, and the SEO work that got me to a 100 SEO score on PageSpeed Insights.

The Stack

Frontend:  Next.js 16 (App Router) + TypeScript
Styling:   Tailwind CSS + custom CSS
Animation: GSAP 3 + ScrollTrigger + SplitText + Flip
Fonts:     next/font (self-hosted Inter, Space Grotesk, JetBrains Mono)
Images:    AWS S3 + Next.js Image optimization
Email:     Nodemailer (contact form)
Analytics: Vercel Analytics
Deploy:    Vercel

Why Next.js for a Portfolio?

A portfolio could easily be a static HTML/CSS site. I chose Next.js for three reasons:

SEO control. The metadata API, structured data injection, and server-side rendering give me full control over what Google sees. A single-page React app with client-side rendering is harder to get right for SEO — Google can crawl it, but the timing is unreliable.

Image optimization. next/image with S3 remote patterns handles WebP/AVIF conversion, responsive srcsets, and lazy loading automatically. Project screenshots from S3 that were 275KB PNGs get served as 60KB WebP to modern browsers.

The blog. I wanted a blog section with individual pages, proper metadata per post, and URLs like /blog/building-saas-with-nextjs. Next.js App Router makes this natural.

The Design Direction

I went with a dark theme with a yellow-green accent (#e8ff59) for the blog and a blue accent (#3b82f6) for the main portfolio. The aesthetic is developer-minimal — monospace fonts for labels and metadata, clean sans-serif for body text, zero gradients.

Color palette:

:root {
  --bg-primary:   #0a0a0b;  /* near-black background */
  --bg-secondary: #111113;  /* card surfaces */
  --fg-primary:   #fafafa;  /* main text */
  --fg-secondary: #a1a1aa;  /* secondary text */
  --fg-muted:     #71717a;  /* metadata, labels */
  --accent:       #3b82f6;  /* blue — interactive elements */
  --success:      #22c55e;  /* availability badge */
}

Typography:

Space Grotesk — display headings (name, section titles)
Inter — body text (descriptions, paragraphs)
JetBrains Mono — labels, metadata, code snippets

The monospace-for-metadata pattern creates a visual hierarchy without needing different font sizes — the font style itself communicates "this is supporting information."

The Hero Section: Loading Animation

The hero has a multi-stage loading sequence:

A loading counter animates (00 → 100) using GSAP
Project images scale in from the corner with staggered timing
The background slides up
Nav, sidebar, and content fade in
Text lines reveal from bottom using SplitText

// Hero loading sequence
const tl = gsap.timeline({ delay: 4 });

// Background slides up
tl.to(".hero-bg", {
  scaleY: "100%",
  duration: 1.2,
  ease: "power4.inOut",
});

// Images animate to final positions using GSAP Flip
tl.add(() => { animateImages(); }, "-=0.8");

// Counter fades out
tl.to(".counter", { autoAlpha: 0, duration: 0.3 }, "<");

// Nav and sidebar animate in
tl.to(["nav", ".navbar"], {
  y: 0,
  autoAlpha: 1,
  duration: 1,
  ease: "power3.out"
});

// Text lines reveal
tl.to([".name-title span", ".tagline span", ".role-text span"], {
  y: "0%",
  duration: 1,
  stagger: 0.05,
  ease: "power4.out",
}, "<+=0.2");

The SplitText pattern for text reveals:

const setupTextSplitting = () => {
  const elements = document.querySelectorAll(
    ".hero-content h1, .tagline, .role-text"
  );

  elements.forEach((element) => {
    const split = new SplitText(element, {
      type: "lines",
      linesClass: "line",
    });

    // Wrap each line in a span for overflow:hidden clipping
    element.querySelectorAll(".line").forEach((line) => {
      const text = line.textContent || "";
      line.innerHTML = `<span>${text}</span>`;
    });
  });
};

Each line gets wrapped in a parent with overflow: hidden, then the inner span starts at translateY(125%) and animates to 0%. This gives the "text slides up into view" effect without any JavaScript opacity — pure CSS transform animation.

The Project Gallery: GSAP Flip

The hero has a draggable project gallery that starts as stacked images in the corner, then expands horizontally when clicked. This uses GSAP Flip — one of the most underrated GSAP plugins.

Flip captures the current state of elements, changes their layout, then animates from the old state to the new state automatically:

const handleImageClick = () => {
  const images = document.querySelectorAll(".img");

  // Capture current state (stacked in corner)
  const state = Flip.getState(images);

  // Change layout (add class that spreads them horizontally)
  images.forEach((img) => img.classList.add("animate-out"));

  // Animate from old state to new state
  Flip.from(state, {
    duration: 1.5,
    stagger: 0.05,
    ease: "power3.inOut",
  });
};

Without Flip, animating between two completely different layout states requires manually calculating positions and animating each property. Flip does it in 3 lines.

The About Section: Scroll-Driven Text Reveal

The about section has a scroll-driven word-by-word blur reveal. Each word fades from opacity: 0.1, filter: blur(4px) to opacity: 1, filter: blur(0) as you scroll through the section.

// About.tsx
const words = gsap.utils.toArray('.reveal-word');

gsap.to(words, {
  opacity: 1,
  filter: "blur(0px)",
  duration: 1,
  stagger: 0.1,
  ease: "none",
  scrollTrigger: {
    trigger: textContainerRef.current,
    start: "top 85%",
    end: "bottom 55%",
    scrub: 1,      // ties animation to scroll position
  }
});

scrub: 1 smoothly ties the animation progress to scroll position. As you scroll down, more words reveal. Scroll back up, they blur again. The 1 is a lag value — a small delay before the animation catches up to scroll position, making it feel physical rather than mechanical.

Skills: Animated Beam Hierarchy Graph

The skills section uses AnimatedBeam from MagicUI to create a radial hierarchy — a central "SKILLS" node with category nodes in orbit, connected by animated gradient beams, with individual skill icons as leaf nodes.

// Radial positioning math
const getPos = (angleDeg: number, radius: number) => {
  const angleRad = (angleDeg * Math.PI) / 180;
  return {
    top: "50%",
    left: "50%",
    transform: `translate(
      calc(-50% + ${radius * Math.cos(angleRad)}px), 
      calc(-50% + ${radius * Math.sin(angleRad)}px)
    )`,
  };
};

// Each group has an angle, distance from center, and leaf spread
const desktopGroups = [
  { id: "frontend", angle: 220, dist: 220, leafSpread: 100 },
  { id: "backend",  angle: 180, dist: 380, leafSpread: 80  },
  { id: "cloud",    angle: 140, dist: 220, leafSpread: 80  },
  // ...
];

Hovering a skill icon shows a popup card with experience level, description, and tags. On mobile, the radial layout collapses to a vertical accordion — the useWindowWidth hook switches layouts at 768px.

Experience Section: GSAP Cards

The experience cards animate in with rotateX: 8 → rotateX: 0 as they enter the viewport — a subtle 3D tilt effect on reveal:

gsap.fromTo(
  ".exp-card-wrapper",
  { opacity: 0, y: 80, rotateX: 8 },
  {
    opacity: 1,
    y: 0,
    rotateX: 0,
    duration: 0.9,
    stagger: 0.25,
    ease: "power3.out",
    scrollTrigger: {
      trigger: ".exp-cards-container",
      start: "top 70%",
    },
  }
);

The large background year numbers (2018, 2024, 2025) use a parallax effect — they move upward at a slower rate than scroll, creating depth:

gsap.to(".exp-year-bg", {
  y: -80,
  ease: "none",
  scrollTrigger: {
    trigger: sectionRef.current,
    start: "top bottom",
    end: "bottom top",
    scrub: 1,        // tied to scroll
  },
});

The Contact Form: Nodemailer

The contact form sends emails via a Next.js API route using Nodemailer:

// app/api/contact/route.ts
import nodemailer from 'nodemailer';

export async function POST(req: Request) {
  const { name, email, message } = await req.json();

  const transporter = nodemailer.createTransport({
    service: 'gmail',
    auth: {
      user: process.env.GMAIL_USER,
      pass: process.env.GMAIL_APP_PASSWORD, // App Password, not account password
    },
  });

  await transporter.sendMail({
    from: process.env.GMAIL_USER,
    to: 'suyogb5300@gmail.com',
    replyTo: email,
    subject: `Portfolio contact from ${name}`,
    html: `
      <h3>New message from your portfolio</h3>
      <p><strong>Name:</strong> ${name}</p>
      <p><strong>Email:</strong> ${email}</p>
      <p><strong>Message:</strong></p>
      <p>${message}</p>
    `,
  });

  return Response.json({ message: 'Sent successfully' });
}

Use Gmail App Passwords (not your account password) — generate one at myaccount.google.com/apppasswords.

The Performance Problem I Created

After building everything, I ran PageSpeed for the first time. Mobile: 47. Desktop: 71.

The two main culprits:

1. Google Fonts @import in CSS. I had @import url("https://fonts.googleapis.com/...") in both globals.css and the Hero component's styles.css. Even though I'd set up next/font correctly in layout.tsx, the CSS imports were firing separately and blocking render. The fix: delete every @import from CSS files — next/font handles everything.

2. CLS 0.83 from GSAP inline styles. My components had style={{ opacity: 0 }} as inline styles on animated elements. Inline styles have higher specificity than CSS, so the min-height fixes in my layout CSS were being overridden. Elements were collapsing to 0px before GSAP ran, causing massive layout shift.

The fix: move all initial animation states to gsap.set() inside useEffect, after mount. Let CSS handle reserving space, let GSAP handle animation state.

After both fixes: Performance 91, CLS 0.08.

SEO: Getting to 100

PageSpeed SEO was 100 from the start, but Seobility's audit found issues the Lighthouse SEO score misses:

The H1 problem. My hero <h1> was inside a component loaded with dynamic({ ssr: false }). Googlebot crawls static HTML first — no JavaScript executed. No H1 in static HTML = major SEO penalty.

Fix: add a visually-hidden h1 directly in page.tsx, outside the dynamic import:

// app/page.tsx
export default function Home() {
  return (
    <main>
      {/* Visible to Google, invisible to users */}
      <h1 style={{
        position: 'absolute',
        width: '1px', height: '1px',
        padding: 0, margin: '-1px',
        overflow: 'hidden',
        clip: 'rect(0,0,0,0)',
        whiteSpace: 'nowrap',
        border: 0,
      }}>
        Suyog Bhise — Full Stack Developer | React, Next.js, Node.js
      </h1>

      <Hero /> {/* dynamic, ssr: false */}
      {/* ... */}
    </main>
  );
}

Structured data. I added both Person and WebSite JSON-LD schemas in layout.tsx. The WebSite schema with a SearchAction enables the Google Sitelinks search box:

const websiteJsonLd = {
  "@context": "https://schema.org",
  "@type": "WebSite",
  url: "https://www.suyogbhise.online",
  name: "Suyog Bhise — Full Stack Developer",
  potentialAction: {
    "@type": "SearchAction",
    target: {
      "@type": "EntryPoint",
      urlTemplate: "https://www.suyogbhise.online/blog?q={search_term_string}",
    },
    "query-input": "required name=search_term_string",
  },
};

Meta description length. Mine was 302 characters — too long, getting truncated in search results. Trimmed to 155 characters.

Sitemap. Initially included /#about, /#contact etc. Hash URLs are scroll positions, not pages — Google ignores them and they waste crawl budget. Removed them, keeping only real page URLs.

The Blog System

The blog uses inline React components for content rather than MDX, keeping the dependency list small. Each post is a function component that returns JSX:

function DockerPost() {
  return (
    <>
      <h2>Why Docker for Node.js</h2>
      <p>Before Docker, deploying Node.js meant SSH-ing into...</p>
      <pre data-lang="dockerfile"><code>{`FROM node:20-alpine...`}</code></pre>
    </>
  );
}

Each blog post page uses generateMetadata and generateStaticParams for static generation and proper per-post SEO:

// app/blog/[slug]/page.tsx
export function generateStaticParams() {
  return blogPosts.map((post) => ({ slug: post.slug }));
}

export async function generateMetadata({ params }) {
  const { slug } = await params;
  const post = blogPosts.find((p) => p.slug === slug);

  return {
    title: post.title,
    description: post.excerpt,
    alternates: { canonical: `https://www.suyogbhise.online/blog/${slug}` },
    openGraph: {
      type: "article",
      publishedTime: new Date(post.date).toISOString(),
    },
  };
}

What I'd Do Differently

Start with performance in mind. I retrofitted all the performance optimizations after building. If I'd set up next/font correctly from day one and never used inline style={{ opacity: 0 }} for GSAP initial states, I'd have saved two full days of debugging.

Use gsap.set() for all initial animation states — never inline styles. This is the single most important GSAP lesson from this build. Inline styles cascade incorrectly with CSS, cause hydration warnings, and create CLS issues. gsap.set() in useEffect is always the right approach.

Write the generateMetadata functions at the same time as the pages. I added SEO metadata as a pass after building — it would have been much faster to do alongside each page.

Final Scores

PageSpeed Desktop:
  Performance:    91
  Accessibility:  92
  Best Practices: 96
  SEO:           100

PageSpeed Mobile:
  Performance:    75
  SEO:           100

The mobile performance score is still a work in progress — GSAP animation complexity has a cost on mobile CPUs. The next optimization is reducing the number of scroll-triggered animations on small screens.

The Stack Summary

If you're building a developer portfolio and want this level of polish:

Next.js App Router — for SEO control and the blog
GSAP — for animations that feel premium, not like CSS transitions
next/font — and delete every @import from your CSS files
Structured data — Person + WebSite schemas in layout.tsx
generateMetadata — on every page, including blog posts
Visually-hidden H1 — if your hero is loaded with ssr: false

The portfolio is open source — check the code at github.com/Suyog5300. Steal what's useful.

I'm Suyog Bhise, a Full Stack Developer based in Pune, India. This portfolio is live at suyogbhise.online.

Deploying Node.js with Docker + AWS EC2: A Complete Guide

suyog bhise — Sat, 14 Mar 2026 17:58:22 +0000

Deploying Node.js with Docker + AWS EC2: A Complete Guide

Before Docker, deploying Node.js at IVTREE meant SSH-ing into the server, pulling from git, running npm install, and hoping the Node version matched production.

It never fully matched. There was always something — a package that behaved differently, a native module that needed rebuilding, an environment variable that got missed. Docker eliminates all of that. What runs locally runs in production, every time.

This is the exact setup I use for production Node.js deployments.

What We're Building

By the end of this guide you'll have:

A multi-stage Docker build that produces a small, secure image
docker-compose for local development with MongoDB included
GitHub Actions CI/CD that deploys to EC2 on every push to main
Nginx as a reverse proxy with SSL via Let's Encrypt
Zero-downtime deployments

The Dockerfile

Most Node.js Dockerfiles I see online are single-stage and install devDependencies in production. Here's the correct multi-stage approach:

# Stage 1: Build
FROM node:20-alpine AS builder

WORKDIR /app

# Copy package files first — Docker caches this layer
# Only re-runs npm ci when package*.json changes
COPY package*.json ./
RUN npm ci --only=production

# Stage 2: Run
FROM node:20-alpine AS runner

WORKDIR /app

# Security: run as non-root user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# Copy only production dependencies from builder stage
COPY --from=builder /app/node_modules ./node_modules

# Copy application code
COPY . .

# Switch to non-root user before starting
USER appuser

EXPOSE 3000

CMD ["node", "server.js"]

Why multi-stage? The builder stage has devDependencies, build tools, and compilation artifacts. The runner stage gets only what's needed to run. A typical Express API image goes from ~800MB (single-stage) to ~150MB (multi-stage).

Why Alpine? node:20-alpine is 50MB vs node:20 at 400MB. For a Node.js API, you almost never need the full Debian image.

Why non-root? If your container is ever compromised, running as root means the attacker has root access to the host via container escape vulnerabilities. Non-root limits the blast radius.

.dockerignore

Always add this — without it, Docker copies node_modules from your local machine into the build context, which takes forever and may include platform-specific binaries:

node_modules
.git
.gitignore
*.md
.env
.env.*
dist
coverage
.nyc_output
logs
*.log

docker-compose for Local Development

# docker-compose.yml
version: '3.8'

services:
  api:
    build: .
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=development
      - MONGO_URI=mongodb://mongo:27017/appdb
      - JWT_SECRET=local_dev_secret
    volumes:
      # Hot reload: mount source code
      - .:/app
      # Prevent local node_modules from overriding container's
      - /app/node_modules
    depends_on:
      mongo:
        condition: service_healthy
    restart: unless-stopped

  mongo:
    image: mongo:7
    ports:
      - "27017:27017"
    volumes:
      - mongo_data:/data/db
    healthcheck:
      test: ["CMD", "mongosh", "--eval", "db.adminCommand('ping')"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  mongo_data:

The healthcheck on MongoDB ensures your API container only starts once MongoDB is actually ready to accept connections — not just running. Without this, you get race condition errors on startup.

Run with:

docker-compose up        # foreground
docker-compose up -d     # background
docker-compose down      # stop and remove containers
docker-compose down -v   # also remove volumes (wipes database)

AWS EC2 Setup

Instance Selection

t3.small (2GB RAM) — minimum for a real Node.js API
t3.medium (4GB RAM) — recommended for APIs with meaningful traffic
t2.micro — the free tier option, too slow for production under any real load

Security Group Rules

Inbound:
  Port 22   (SSH)    — Your IP only
  Port 80   (HTTP)   — 0.0.0.0/0
  Port 443  (HTTPS)  — 0.0.0.0/0

Outbound:
  All traffic — 0.0.0.0/0

Never expose port 3000 publicly. Traffic goes through Nginx on 80/443, which proxies to your Node container on 3000 internally.

EC2 Server Setup

SSH in and run:

# Update system
sudo apt update && sudo apt upgrade -y

# Install Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker ubuntu
newgrp docker

# Install Docker Compose
sudo apt install docker-compose-plugin -y

# Install Nginx
sudo apt install nginx -y

# Install Certbot for SSL
sudo apt install certbot python3-certbot-nginx -y

# Create app directory
mkdir -p /home/ubuntu/app

Nginx Configuration

# /etc/nginx/sites-available/api
server {
    listen 80;
    server_name api.yourdomain.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

# Enable the site
sudo ln -s /etc/nginx/sites-available/api /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

# Get SSL certificate (replace with your domain)
sudo certbot --nginx -d api.yourdomain.com

Certbot automatically modifies your Nginx config to add HTTPS and sets up auto-renewal via a cron job.

GitHub Actions CI/CD

Store these in GitHub repository secrets:

EC2_HOST — your EC2 public IP
EC2_SSH_KEY — your EC2 private key (the .pem file contents)

# .github/workflows/deploy.yml
name: Deploy to EC2

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Deploy to EC2
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ubuntu
          key: ${{ secrets.EC2_SSH_KEY }}
          script: |
            cd /home/ubuntu/app

            # Pull latest code
            git pull origin main

            # Build new image
            docker build -t myapp:latest .

            # Zero-downtime: start new container, stop old one
            docker compose up -d --build --no-deps api

            # Clean up old images
            docker image prune -f

The --no-deps flag rebuilds only the api service without touching the database container. This is important — you don't want to restart MongoDB during a code deployment.

Zero-Downtime Deployments

The approach above has a brief gap when the old container stops and the new one starts. For true zero-downtime, use a blue-green approach with Nginx upstream switching:

# docker-compose.yml — two app instances
services:
  api-blue:
    build: .
    ports:
      - "3001:3000"

  api-green:
    build: .
    ports:
      - "3002:3000"

# deploy.sh on EC2
#!/bin/bash

# Determine current active color
ACTIVE=$(cat /tmp/active_color 2>/dev/null || echo "blue")
NEXT=$([ "$ACTIVE" = "blue" ] && echo "green" || echo "blue")

# Start new version
docker compose up -d --build api-$NEXT

# Wait for health check
sleep 10

# Switch Nginx to new version
PORT=$([ "$NEXT" = "blue" ] && echo "3001" || echo "3002")
sed -i "s/proxy_pass http:\/\/localhost:[0-9]*/proxy_pass http:\/\/localhost:$PORT/" /etc/nginx/sites-available/api
nginx -s reload

# Stop old version
docker compose stop api-$ACTIVE

# Record active color
echo $NEXT > /tmp/active_color

Overkill for most projects, but worth knowing for high-traffic APIs.

Environment Variables

Never put secrets in your Docker image. Use a .env file on the server:

# /home/ubuntu/app/.env (on EC2, not in git)
NODE_ENV=production
MONGO_URI=mongodb://mongo:27017/appdb
JWT_SECRET=your_actual_secret_here
STRIPE_SECRET_KEY=sk_live_...

Reference it in docker-compose:

services:
  api:
    env_file:
      - .env

The .env file on EC2 is separate from anything in your repository. Add .env to .gitignore and never commit secrets.

Monitoring

Two simple things that catch most production issues:

# View live logs
docker compose logs -f api

# Container resource usage
docker stats

# Check if containers are running
docker compose ps

For production, set up log forwarding to CloudWatch or Datadog. But for early-stage products, docker compose logs piped to a file is often enough.

EC2 Checklist

Before going live:

[ ] Elastic IP assigned (so IP doesn't change on restart)
[ ] Domain pointing to Elastic IP
[ ] SSL certificate installed (Certbot)
[ ] Security group only exposes 80, 443, 22
[ ] .env file on server with production secrets
[ ] docker-compose restart: unless-stopped set on all services
[ ] GitHub Actions secrets set
[ ] First deployment tested manually

Containers don't solve bad architecture — they just make deployment consistent. Make sure your app is well-structured before you containerize it.

The most common mistake I see is treating Docker as a magic solution for messy code. It's not. A hard-coded port, an uncaught async error that crashes the process, a missing environment variable — all of these problems exist whether you're using Docker or not.

Containerization is about consistency and reproducibility. Get the code right first.

I'm Suyog Bhise, a Full Stack Developer at IVTREE where I manage Docker-based deployments to AWS EC2. suyogbhise.online