DEV Community: Chandu Bobbili

🚀 Forget the Next Framework—The Real JavaScript Revolution Is Happening Under the Hood

Chandu Bobbili — Sat, 11 Jul 2026 16:47:20 +0000

We keep waiting for the next framework to change everything—React, Vue, Svelte, Solid. But the real revolution has been happening behind the scenes. The biggest improvements are coming from the tools we rarely think about: transpilers, bundlers, test runners, linters, and type checkers.

For years, these tools were built in JavaScript, making development slower and interrupting workflow. Now, that's changing—not because of smarter algorithms, but because these tools are moving away from JavaScript to native, compiled languages that dramatically improve the developer experience.

📚 Table of Contents

📌 Key Takeaways
⏳ The old stack's hidden tax
⚡ The new generation, tool by tool
💡 Why this matters more than any framework choice
🧩 It's not really about any single tool
🚀 Final Thoughts

📌 Key Takeaways

Modern JavaScript tooling is rapidly moving from JavaScript to native languages like Rust and Go.

OXC, Turbopack, Vitest, Oxlint, and the new TypeScript compiler deliver performance improvements ranging from 8× to 100×.

Faster tooling doesn't just save time—it fundamentally changes how developers work.

React, Next.js, Vite, and TypeScript aren't being replaced—they're becoming dramatically faster because of the tooling underneath them.

⏳ The old stack's hidden tax

The traditional JavaScript toolchain—Babel for transforms, Webpack for bundling, Jest for tests, ESLint for linting, and the JavaScript-based TypeScript compiler—was built for a much smaller web.

As applications evolved into massive monorepos with thousands of files, builds, linting, and type checking gradually became slower. What once took seconds began taking minutes.

The real cost wasn't just waiting.

Every build broke your focus.

Every lint run interrupted your train of thought.

Every type check tempted you to switch tabs and lose momentum.

❌ The Hidden Cost of the Old Stack

🐢 Slow builds

⏳ Long feedback loops

🔄 Constant context switching

😩 Developer frustration

⚡ The new generation, tool by tool

The common thread behind every modern replacement is simple:

They're rewritten in compiled, natively parallel languages—primarily Rust, with Microsoft's new TypeScript compiler choosing Go.

Let's see how they compare.

Babel → OXC

Slower Transforms → Blazing Fast Transforms

OXC is a Rust-based toolchain built by the VoidZero team (the creators of Vite and Vue).

Compared to Babel:

⚡ ~40× faster transforms
💾 ~70% less memory usage
📦 168 fewer npm packages
🚀 Parser roughly 3× faster than SWC

Webpack → Turbopack

Heavy Bundles → Incremental & Fast

Turbopack is Vercel's Rust-based successor to Webpack and is now the default bundler in Next.js.

Instead of rebuilding everything after every change, it memoizes work and rebuilds only what actually changed.

The result is dramatically faster builds and nearly instant Hot Module Reloading (HMR) on large projects.

Jest → Vitest

Slow Tests → Instant Tests

Vitest reuses Vite's module graph instead of crawling the filesystem like Jest.

Real-world benchmark (500-test suite):

⚡ 8.5× faster watch mode (340 ms vs 2,890 ms)
🚀 ~2× faster cold starts
💾 27% lower peak memory

On larger monorepos, the performance gap becomes even bigger.

ESLint → Oxlint

Slower Linting → Extremely Fast Linting

Oxlint is part of the OXC ecosystem.

Because it's written in Rust and designed for parallel execution, it's approximately:

⚡ 50×–100× faster than ESLint

This isn't an incremental improvement—it's an entirely different experience.

TypeScript (JavaScript) → TypeScript (Go)

Slower Type Checking → Up to 10× Faster

Perhaps the biggest announcement came from Microsoft itself.

Rather than creating an alternative compiler, the TypeScript team rewrote the actual compiler in Go.

Microsoft's benchmarks show:

VS Code: 77.8 s → 7.5 s (10.4× faster)
Playwright: 11.1 s → 1.1 s
VS Code editor load: 9.6 s → 1.2 s (8× faster)

Interestingly, the team chose Go over Rust because it allowed them to preserve the compiler's existing architecture almost line-by-line, ensuring identical type-checking behavior.

✅ What the Native Toolchain Gives Back

⚡ Faster builds

🚀 Instant feedback

🧠 Flow state

❤️ More time to build

💡 Why this matters more than any framework choice

None of these tools change what you build.

React is still React.

Next.js is still Next.js.

TypeScript is still TypeScript.

What changes is the feedback loop between writing code and seeing results.

That loop is what developers experience hundreds of times every day.

When feedback drops from seconds to milliseconds, something interesting happens:

You stop waiting.

You start experimenting.

You run tests more frequently.

You refactor with confidence.

You stay in flow.

"When your tests run in 200 milliseconds instead of 4 seconds, you stop batching test runs and start running them continuously. It changes your entire development workflow."

That's the real productivity gain.

Not just faster tools—but better developer behavior.

🧩 It's not really about any single tool

OXC.

Turbopack.

Vitest.

Oxlint.

The new TypeScript compiler.

They all arrived at the same conclusion:

Native, compiled tooling outperforms JavaScript tooling.

This isn't replacing React.

It isn't replacing Next.js.

It isn't replacing Vite.

Instead, it's accelerating the entire JavaScript ecosystem by shrinking the gap between writing code and getting feedback.

The frameworks may grab the headlines.

The tooling is quietly transforming how we build software.

🚀 Final Thoughts

Frameworks come and go.

But every JavaScript application is still:

Bundled
Tested
Linted
Transpiled
Type checked

Making those layers dramatically faster benefits every framework built on top of them.

The next revolution isn't another JavaScript framework.

It's the infrastructure beneath it.

💬 What do you think?

Which tool has been the biggest bottleneck in your workflow?

Webpack?
ESLint?
TypeScript?
Jest?

Or have you already switched to the new native toolchain?

I'd love to hear your experience in the comments.

Sources

OXC official benchmark documentation
Microsoft's TypeScript native compiler announcement and benchmarks
Independent Vitest vs Jest benchmark studies (2026)
Independent Turbopack vs Webpack comparison studies

How Web Push Notifications Work Internally: Implementing with React + Golang

Chandu Bobbili — Wed, 24 Jun 2026 17:11:39 +0000

I understand how browser push infrastructure works and designed it properly.
Push notifications have become a core part of modern applications.
Whenever you receive:

a new message alert
an order status update
a deployment notification
a payment reminder there is usually a notification system working behind the scenes.

At first glance, sending a notification looks simple:

Backend sends message → User receives notification

But internally, it involves multiple systems working together:

Browser APIs
Service Workers
Push Services
Encryption
Authentication
Backend workers

In this blog, we will understand how Web Push Notifications work internally and implement a complete push notification system using React.js and Golang.

What are Web Push Notifications?

Web Push allows servers to send messages to browsers even when the website is not open.

The browser displays notifications using a background process called a Service Worker.

Backend → Push Service → Browser → Service Worker → Notification

The important idea: Your backend never directly communicates with the browser.

Instead, every browser provides a Push Service that acts as a delivery system. for example; Chrome: Google Firebase Cloud Messaging, Firefox: Mozilla Push Service

High Level Architecture

Our system contains five major components.

Subscription Flow:

React Application → Service Worker Registration → Push Subscription → Golang Backend → Database

Notification Delivery Flow:

Golang Backend → Browser Push Service → Service Worker → User Notification

Generating VAPID Keys

Before creating subscriptions, our application needs public/private keys.

Generate them using:

package main

import (
    "fmt"
    webpush "github.com/SherClockHolmes/webpush-go"
)

func main(){
    privateKey, publicKey, _ := webpush.GenerateVAPIDKeys()
    fmt.Println("Public:",publicKey)
    fmt.Println("Private:",privateKey)
}

The generated keys:

Public Key:

sent to React application
used while subscribing

Private Key:

stored securely in backend environment variables
used while sending notifications

React Application

The frontend handles:

requesting notification permission
registering service worker
generating push subscription
sending subscription details to backend

Service Worker

A Service Worker is a JavaScript file that runs separately from your React application.
It works even when:

tab is closed
application is inactive
browser is running in background

Responsibilities:

listen for push events
display notifications
handle notification clicks

Browser Push Service

This is managed by browsers.

maintain device connections
receive push messages
wake service workers

Golang Backend

Backend responsibilities:

store subscriptions
authenticate push requests
encrypt notification payloads
send notifications

Subscription Flow

Before sending notifications, the browser needs to register itself.

User Opens Website → Allow Notification Permission → Register Service Worker → Generate Push Subscription → Send Subscription To Backend → Store In Database

React Implementation

First, check browser support.

if ( "serviceWorker" in navigator && "PushManager" in window ) { console.log("Push supported"); }

Request Notification Permission

Browsers require user approval.

async function requestPermission() {
   const permission = await Notification.requestPermission();
   if(permission !== "granted"){
      return;
   }
   console.log( "Notifications enabled" );
}

Register Service Worker

React cannot listen for background events. We register a worker:

const registration = await navigator.serviceWorker.register("/worker.js" );
console.log( "Worker registered", registration );

Creating Push Subscription

Now we create a browser subscription.

const subscription = await registration.pushManager.subscribe({ userVisibleOnly:true, applicationServerKey: VAPID_PUBLIC_KEY });
await fetch( "/api/subscriptions", { method:"POST", body: JSON.stringify(subscription) });

The generated subscription contains:

{ "endpoint":"https://push-service.com/xxx", "keys":{ "p256dh":"public-key", "auth":"secret-key" } }

This is the browser address where notifications will be delivered.

Understanding Service Worker

Create: public/worker.js
A Service Worker listens for push events.

self.addEventListener( "push", event => { 
    const data = event.data.json();
    event.waitUntil(self.registration.showNotification(data.title, 
    { body:data.message, icon:"/icon.png" }));
});

Important: The notification is created outside React. React does not even need to be running.

Sending Notifications Using Go

For implementing Web Push Protocol in Golang, we use:

go get github.com/SherClockHolmes/webpush-go

Import the package:

import (
    webpush "github.com/SherClockHolmes/webpush-go"
)

This package handles:

payload encryption
VAPID authentication
communication with browser push services

Example implementation:

func SendNotification(subscription Subscription, message string) error { 
    _,err := webpush.SendNotification([]byte(message), 
        &webpush.Subscription{Endpoint: subscription.Endpoint,
            Keys:webpush.Keys{Auth: subscription.AuthKey, P256dh: subscription.P256dhKey}},
        &webpush.Options{VAPIDPublicKey: PUBLIC_KEY, VAPIDPrivateKey: PRIVATE_KEY}) 
    return err
}

The Go server:

Reads subscription from database
Encrypts the payload
Signs request using VAPID
Sends message to browser push service

Understanding VAPID Authentication

VAPID stands for: Voluntary Application Server Identification
It proves that:

This notification came from an authorized backend.

It uses two keys:
Public Key : Shared with Browser
Private Key : Stored only on Backend
Never expose VAPID_PRIVATE_KEY in frontend code.

Production Challenges

A demo notification system is easy. A production notification system requires handling edge cases.

Multiple Devices

A single user may have: Chrome Desktop, Android Device, Firefox
Each browser creates a different subscription.

Bad design: One user = One subscription

Better: One user = Many subscriptions

Expired Subscriptions

Push subscriptions can expire.
Reasons:

browser reset
permission removed
device change Push services return: 404 or 410

Remove invalid subscriptions.

Scaling Notification Delivery

Sending notifications directly from APIs works for small systems.
But imagine: 1 Million users
Better architecture:

Application Event → Kafka → Notification Workers → Browser Push Services → Users

Benefits:

asynchronous processing
retries
better reliability
horizontal scaling

Retry Handling

Failures happen because of:

network errors
push service issues
temporary outages

A production system should have:

retry queues
exponential backoff
dead letter queues

Example:

Notification Failed → Retry Queue → Try Again → Dead Letter Queue

Why not WebSockets?

WebSockets are great when users are actively using the application.

Examples:

live chats
multiplayer games
collaborative editing

But WebSockets require an active connection.

When:

the browser tab is closed
device is locked
application process stops

your React application cannot receive messages.
Web Push solves this using Service Workers that can wake up independently from the application.

Security Notes

A few things to remember:

Always use HTTPS in production
Never expose VAPID private keys
Validate users before storing subscriptions
Remove expired subscriptions
Avoid sending sensitive information directly inside notification payloads

Say Goodbye to Changelog Chaos: Introducing changesetgoo

Chandu Bobbili — Mon, 23 Feb 2026 18:43:22 +0000

If you ship libraries or APIs, you’ve undoubtedly felt the release day pain: “What actually changed in this release?” “Did we bump major, minor, or patch correctly?” “Wait, who was supposed to update the changelog?”

Tracking these changes manually is tedious and error-prone, which is exactly why the Changesets workflow was created. By letting you record each change (along with its semver impact and a description) as you work, these entries are automatically merged into a single changelog at release time. This guarantees that users and tools know exactly what changed and how "breaking" a release actually is.

Having spent time in the JS ecosystem working heavily with frameworks like React and Next.js, I've come to rely on the standard JS Changesets workflow. It provides a fantastic developer experience. But when stepping outside of that ecosystem, I hit a snag: I wanted that exact same workflow, but I didn't want to drag Node.js and npm into non-JavaScript projects.

So, I built a solution.

Enter changesetgoo

I built changesetgoo -- a lightweight, standalone Go CLI for managing changesets and changelogs. It brings the excellent JS Changesets workflow to Go projects (and any other repository, really) without the heavy frontend tooling dependencies.

Why you might want to use it:

Zero Node.js Dependency: It's a single compiled binary. You can install it with go install and run it anywhere. No extra runtimes, no node_modules.
Centralized Semver: Add your changesets as you code (major, minor, or patch + description). When you're ready, let the tool compute the exact next version and update your CHANGELOG.md automatically.
Streamlined Release Workflow: You can execute a full release cycle with a single command. It will apply your changesets, bump the version, update the changelog, commit the changes, and tag the release. It's built to be equally at home in a CI pipeline or run locally.
Git-Friendly by Design: It creates semantic tags locally, leaving you in complete control of when to push to your remote.

Quick Usage
Getting started is as simple as running a few commands:

changesetgoo add          # Add a changeset (prompts for type + description)
changesetgoo version      # Merge changesets into CHANGELOG, bump version
changesetgoo publish --push   # Full release: apply, bump, commit, tag, push

If you care about keeping your versioning predictable and your changelogs pristine in Go—or any other repository where you want a lightweight CLI—give it a try.

Feedback, issues, and contributions are always welcome!

🔗 GitHub: github.com/ChanduBobbili/changesetgoo
📦 pkg.go.dev: pkg.go.dev/github.com/ChanduBobbili/changesetgoo

🚀 Biome Has Entered the Chat: A New Tool to Replace ESLint and Prettier

Chandu Bobbili — Mon, 07 Apr 2025 05:16:15 +0000

If you’ve ever set up a JavaScript or TypeScript project, chances are you've spent way too much time configuring ESLint, Prettier, and their dozens of plugins. We’ve all been there — fiddling with .eslintrc, fighting with formatting conflicts, and installing what feels like half the npm registry just to get decent code quality tooling.

But what if you could replace all of that with a single, fast, zero-dependency tool?

Meet Biome — the new kid on the block that’s here to clean up the JavaScript tooling mess.

🧠 What is Biome?

Biome is an all-in-one toolchain for JavaScript and TypeScript projects that combines:

A blazing-fast formatter : Supports JS, TS, JSX, TSX, JSON, CSS and GraphQL.
A powerful linter : Has 293 linting rules to perform detailed diagnostics.
And an extensible parser : 15x faster linting compared to the ESLint and 35x faster formatting compared to the Prettier.

The best part? It’s written in Rust, which means it’s not just fast — it’s ridiculously fast.

🔯 Quick Benchmark

To give you an idea of how fast Biome really is:

# ESLint + Prettier (cold start)
Time: ~4.2s

# Biome (cold start)
Time: ~0.6s

Note: Performance may vary depending on project size and system specs.

🧰 Why Biome is a Game-Changer

Let’s be real: the JS tooling ecosystem has gotten bloated. ESLint + Prettier + TypeScript support + plugin configuration = a mess.

Biome offers:

Unified Toolchain
Better Performance
Simplified Configuration

Feature	Biome	ESLint + Prettier
🔧 Formatting	✅ Built-in	✅ Prettier (separate)
🧺 Linting	✅ Built-in rules	✅ ESLint + plugins
⚡ Speed	🚀 Super fast (Rust)	🐢 Slower (Node.js)
🧰 Setup	🟢 Minimal config	🔴 Plugin jungle
🔀 Dependencies	❌ Zero	⛓️ Lots of dev deps
🧪 TypeScript	✅ First-class support	✅ With `@typescript-eslint`
🛠️ Extensible?	🔒 Not yet (planned)	✅ Fully extensible

🧩 What About Plugins?

While Biome isn’t extensible yet, plugin support is on the roadmap. The team is actively working toward allowing custom rules and framework-specific integrations. If you rely on advanced linting or want to build custom rules, now’s a great time to get involved and contribute.

⚙️ Getting Started with Biome

Getting up and running with Biome is incredibly simple:

1. Installation

Biome instructs the package manager to pin an exact version:

npm install --save-dev --save-exact @biomejs/biome

2. Initialization

npx @biomejs/biome init

3. Usage

Formatting:

npx @biomejs/biome format --write <files>

Linting:

npx @biomejs/biome lint --write <files>

Combined Check:

npx @biomejs/biome check --write <files>

4. Migration from ESLint and Prettier

Biome offers dedicated commands to ease the migration:

npx @biomejs/biome migrate eslint --write
npx @biomejs/biome migrate prettier --write

💬 My Experience Migrating to Biome

I migrated one of my TypeScript projects (~5k LOC) from ESLint + Prettier to Biome and saw:

4x faster linting & formatting.
Removed 10+ npm packages.
No more config conflicts between ESLint and Prettier.
Built-in type-aware linting just worked.

Before:

"devDependencies": {
  "eslint": "...",
  "eslint-plugin-react": "...",
  "eslint-config-prettier": "...",
  "prettier": "...",
  ...
}

After:

"devDependencies": {
  "biome": "^1.0.0"
}

🧪 Is Biome Ready for Production?

Short answer: Yes, especially for new projects.

Longer answer: Biome is still evolving. While it's stable and production-ready for many common setups, it doesn’t yet have the plugin ecosystem ESLint offers. If you rely on complex linting rules, custom plugins, or framework-specific tools — you might want to wait or contribute.

But for 80% of use cases? Biome is already a better experience.

🌞 The Future of JavaScript Tooling?

Biome is more than just fast. It’s simpler, cleaner, and more developer-friendly than anything else out there. It’s taking the best parts of ESLint and Prettier, cutting the bloat, and delivering a smoother developer experience.

And it’s just getting started.

Mastering SEO for Next.js: A Practical Optimization Checklist

Chandu Bobbili — Thu, 13 Mar 2025 04:22:27 +0000

SEO (Search Engine Optimization) is one of the key factors to rank your website higher on Google and receive more traffic.

I've been on a deep dive into Next.js SEO, and I'm excited to share what I've learned. This tutorial provides a clear, actionable checklist to help you optimize your blog and see real results in search engine rankings. Let's make your content shine!

1. Meta Tags

Ensure your website's SEO and social media presence are strong by implementing this meta tag checklist:

Standard Meta Tags : title, description, keywords, robots, viewport, charSet
Open Graph Meta Tags : og:site_name, og:local, og:title, og:description, og:type, og:url, og:image, og:image:alt, og:image:type, og:image:width, og:image:height
Article Meta Tags (Open Graph): article:published_time, article:modified_time, article:author
Twitter Meta Tags: twitter:card, twitter:site, twitter:creator, twitter:title, twitter:description, twitter:image

For optimal compatibility with social media platforms, utilize PNG or JPG image formats in the og:image and twitter:image meta tags, as WebP support is inconsistent.

Meta Tags for Next.js App Router

The App Router provides export const metadata for static metadata and generateMetadata for dynamic metadata generation, simplifying meta tag implementation in Next.js.

Want to know how? The metadata docs have all the info.

Static Metadata

You can define static metadata by adding the export const metadata argument inside page.tsx or layout.tsx:

import type { Viewport, Metadata } from "next";

export const viewport: Viewport = {
  width: "device-width",
  initialScale: 1,
  themeColor: "#ffffff"
};

export const metadata: Metadata = {
  title: "This is meta title",
  description: "This is meta description.",
  metadataBase: new URL("https://example.com"),
  keywords: [
    "example",
    "seo",
    "javascript",
    "nextjs",
  ],
  robots: {
    index: true,
    follow: true,
    "max-image-preview": "large",
    "max-snippet": -1,
    "max-video-preview": -1,
    googleBot: "index, follow"
  },
  alternates: {
    canonical: "https://example.com",
    types: {
      "application/rss+xml": "https://example.com/rss.xml"
    }
  },
  applicationName: "Example | Chandu Bobbili",
  appleWebApp: {
    title: "Example | Chandu Bobbili",
    statusBarStyle: "default",
    capable: true
  },
  verification: {
    google: "YOUR_DATA",
    yandex: ["YOUR_DATA"],
    other: {
      "msvalidate.01": ["YOUR_DATA"],
      "facebook-domain-verification": ["YOUR_DATA"]
    }
  },
  icons: {
    icon: [
      {
        url: "/favicon.ico",
        type: "image/x-icon"
      },
      {
        url: "/favicon-16x16.png",
        sizes: "16x16",
        type: "image/png"
      }
      // add favicon-32x32.png, favicon-96x96.png, android-chrome-192x192.png
    ],
    shortcut: [
      {
        url: "/favicon.ico",
        type: "image/x-icon"
      }
    ],
    apple: [
      {
        url: "/apple-icon-57x57.png",
        sizes: "57x57",
        type: "image/png"
      },
      {
        url: "/apple-icon-60x60.png",
        sizes: "60x60",
        type: "image/png"
      }
      // add apple-icon-72x72.png, apple-icon-76x76.png, apple-icon-114x114.png, apple-icon-120x120.png, apple-icon-144x144.png, apple-icon-152x152.png, apple-icon-180x180.png
    ]
  },
  openGraph: {
    url: "https://example.com",
    type: "website",
    title: "This is title",
    description: "This is the description",
    images: [
      {
        url: "https://example.com/images/home/thumbnail.png",
        width: 1200,
        height: 630,
        alt: "image"
      }
    ]
  },
  twitter: {
    card: "summary_large_image",
    title: "This is title",
    description: "This is the description",
    creator: "@ChanduBobbili",
    site: "@ChanduBobbili",
    images: [
      {
        url: "https://example.com/images/home/thumbnail.png",
        width: 1200,
        height: 630,
        alt: "dminhvu"
      }
    ]
  },
};

Dynamic Metadata

Implement the generateMetadata function to define dynamic metadata for pages with dynamic route segments, such as [slug]/page.tsx or [id]/page.tsx.

import type { Metadata, ResolvingMetadata } from "next";

type Params = {
  slug: string;
};

type Props = {
  params: Params;
  searchParams: { [key: string]: string | string[] | undefined };
};

export async function generateMetadata(
  { params, searchParams }: Props,
  parent: ResolvingMetadata
): Promise<Metadata> {
  const { slug } = params;

  const post: Post = await fetch(`YOUR_ENDPOINT`, {
    method: "GET",
    next: {
      revalidate: 60 * 60 * 24
    }
  }).then((res) => res.json());

  return {
    title: `${post.title} | Webpage`,
    authors: [
      {
        name: post.author || "Chandu"
      }
    ],
    description: post.description,
    keywords: post.keywords,
    openGraph: {
      title: `${post.title} | Webpage`,
      description: post.description,
      type: "article",
      url: `https://example.com/${post.slug}`,
      publishedTime: post.created_at,
      modifiedTime: post.modified_at,
      authors: ["https://example.com/about"],
      tags: post.categories,
      images: [
        {
          url: `https://example/assets/${post.slug}/thumbnail.png?tr=f-png`,
          width: 1024,
          height: 576,
          alt: post.title,
          type: "image/png"
        }
      ]
    },
    twitter: {
      card: "summary_large_image",
      site: "@ChanduBobbili",
      creator: "@ChanduBobbili",
      title: `${post.title} | webpage`,
      description: post.description,
      images: [
        {
          url: `https://example/assets/${post.slug}/thumbnail.png?tr=f-png`,
          width: 1024,
          height: 576,
          alt: post.title
        }
      ]
    },
    alternates: {
      canonical: `https://example.com/${post.slug}`
    }
  };
}

Next.js App Router automatically includes charSet and viewport, so you don't need to define them manually.

Meta Tags for Next.js Pages Router

You'll find these meta tags present on this page when using the Next.js Pages Router:

import Head from "next/head";

export default function Page() {
  return (
    <Head>
      <title>Example | Webpage</title>
      <meta
        name="description"
        content="Learn how to optimize your Next.js website for SEO by following this complete checklist."
      />
      <meta
        name="keywords"
        content="nextjs seo complete checklist, nextjs seo tutorial"
      />
      <meta name="robots" content="index, follow" />
      <meta name="googlebot" content="index, follow" />
      <meta name="viewport" content="width=device-width, initial-scale=1.0" />
      <meta charSet="utf-8" />
      <meta property="og:site_name" content="Blog | Webpage" />
      <meta property="og:locale" content="en_US" />
      <meta
        property="og:title"
        content="Enter your title here"
      />
      <meta
        property="og:description"
        content="Enter your description here"
      />
      <meta property="og:type" content="website" />
      <meta property="og:url" content="https://example.com/nextjs-seo" />
      <meta
        property="og:image"
        content="https://example/assets/nextjs-seo/thumbnail.png?tr=f-png"
      />
      <meta property="og:image:alt" content="Next.js SEO" />
      <meta property="og:image:type" content="image/png" />
      <meta property="og:image:width" content="1200" />
      <meta property="og:image:height" content="630" />
      <meta
        property="article:published_time"
        content="2024-01-11T11:35:00+07:00"
      />
      <meta
        property="article:modified_time"
        content="2024-01-11T11:35:00+07:00"
      />
      <meta
        property="article:author"
        content="https://www.linkedin.com/in/chandu-bobbili-15863319b"
      />
      <meta name="twitter:card" content="summary_large_image" />
      <meta name="twitter:site" content="@ChanduBobbili" />
      <meta name="twitter:creator" content="@ChanduBobbili" />
      <meta
        name="twitter:title"
        content="Enter your title here"
      />
      <meta
        name="twitter:description"
        content="Enter your description here"
      />
      <meta
        name="twitter:image"
        content="https://example/assets/nextjs-seo/thumbnail.png?tr=f-png"
      />
    </Head>
  );
}

2. Sitemap

A sitemap helps search engines find and index your website's content, which is crucial for SEO.

Sitemap for Next.js App Router

For Next.js App Router, you can define the sitemap.ts file at app/sitemap.ts:

import {
  getAllCategories,
  getAllPostSlugsWithModifyTime
} from "@/utils/getData";
import { MetadataRoute } from "next";

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const defaultPages = [
    {
      url: "https://example.com",
      lastModified: new Date(),
      changeFrequency: "daily",
      priority: 1
    },
    {
      url: "https://example.com/about",
      lastModified: new Date(),
      changeFrequency: "monthly",
      priority: 0.9
    },
    {
      url: "https://example.com/contact",
      lastModified: new Date(),
      changeFrequency: "monthly",
      priority: 0.9
    }
    // other pages
  ];

  const postSlugs = await getAllPostSlugsWithModifyTime();
  const categorySlugs = await getAllCategories();

  const sitemap = [
    ...defaultPages,
    ...postSlugs.map((e: any) => ({
      url: `https://example.com/${e.slug}`,
      lastModified: e.modified_at,
      changeFrequency: "daily",
      priority: 0.8
    })),
    ...categorySlugs.map((e: any) => ({
      url: `https://example.com/category/${e}`,
      lastModified: new Date(),
      changeFrequency: "daily",
      priority: 0.7
    }))
  ];

  return sitemap;
}

With this sitemap.ts file created, you can access the sitemap at https://example.com/sitemap.xml.

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com</loc>
    <lastmod>2024-01-11T02:03:09.613Z</lastmod>
    <changefreq>daily</changefreq>
    <priority>0.7</priority>
  </url>
  <!-- other pages -->
</urlset>

Visit Next.js App Router Sitemap to learn more.

Sitemap for Next.js Page Router

If you're using the Pages Router in Next.js, next-sitemap is a convenient tool for sitemap creation following your build.

For example, running the following command will install next-sitemap and generate a sitemap for your app:

npm install next-sitemap
npx next-sitemap

next-sitemap requires a basic config file (next-sitemap.config.js) under your project root, checkout

A sitemap will be generated at public/sitemap.xml:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:news="http://www.google.com/schemas/sitemap-news/0.9" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:mobile="http://www.google.com/schemas/sitemap-mobile/1.0" xmlns:image="http://www.google.com/schemas/sitemap-image/1.1" xmlns:video="http://www.google.com/schemas/sitemap-video/1.1">
<url>
  <loc>https://example.com</loc>
    <lastmod>2024-01-11T02:03:09.613Z</lastmod>
    <changefreq>daily</changefreq>
  <priority>0.7</priority>
</url>
<!-- other pages -->
</urlset>

3. robots.txt

A robots.txt file guides search engine crawlers by defining which pages they are allowed or disallowed to access.

robots.txt for Next.js App Router

For Next.js App Router, you don't need to manually define a robots.txt file. Instead, you can define the robots.ts file at app/robots.ts:

import { MetadataRoute } from "next";

export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: "*",
      allow: ["/"],
      disallow: ["/search?q=", "/admin/"]
    },
    sitemap: ["https://example.com/sitemap.xml"]
  };
}

With this robots.ts file created, you can access the robots.txt file at https://example.com/robots.txt.

robots.txt for Next.js Pages Router

For Next.js Pages Router, you can create a robots.txt file at public/robots.txt:

User-agent: *
Disallow:
Sitemap: https://example.com/sitemap.xml

For pages you don't want indexed, such as search results or those marked 'noindex', this line will block search engine crawlers:

User-agent: *
Disallow: /search?q=
Disallow: /admin

4. Link Tags

Beyond meta tags, your website requires the inclusion of several key link tags:

canonical
alternative
icon
apple-touch-icon
manifest

Link Tags for Next.js App Router

Link tags in Next.js App Router are handled in the same way as meta tags, via export const metadata or generateMetadata.

import type { Viewport, Metadata } from "next";

export const viewport: Viewport = {
  width: "device-width",
  initialScale: 1,
  themeColor: "#ffffff"
};

export const metadata: Metadata = {
  // other parts
  alternates: {
    canonical: "https://example.com",
    types: {
      "application/rss+xml": "https://example.com/rss.xml"
    }
  },
  icons: {
    icon: [
      {
        url: "/favicon.ico",
        type: "image/x-icon"
      },
      {
        url: "/favicon-16x16.png",
        sizes: "16x16",
        type: "image/png"
      }
      // add favicon-32x32.png, favicon-96x96.png, android-chrome-192x192.png
    ],
    shortcut: [
      {
        url: "/favicon.ico",
        type: "image/x-icon"
      }
    ],
    apple: [
      {
        url: "/apple-icon-57x57.png",
        sizes: "57x57",
        type: "image/png"
      },
      {
        url: "/apple-icon-60x60.png",
        sizes: "60x60",
        type: "image/png"
      }
      // add apple-icon-72x72.png, apple-icon-76x76.png, apple-icon-114x114.png, apple-icon-120x120.png, apple-icon-144x144.png, apple-icon-152x152.png, apple-icon-180x180.png
    ]
  },
};

Link Tags for Next.js Pages Router

To demonstrate the link tags, this page would contain the following when using the Pages Router:

import Head from "next/head";

export default function Page() {
  return (
    <Head>
      {/* other parts */}
      <link
        rel="alternate"
        type="application/rss+xml"
        href="https://example.com/rss.xml"
      />
      <link rel="canonical" href="https://example.com/nextjs-seo" />
      <link rel="icon" href="/favicon.ico" type="image/x-icon" />
      <link rel="apple-touch-icon" sizes="57x57" href="/apple-icon-57x57.png" />
      <link rel="apple-touch-icon" sizes="60x60" href="/apple-icon-60x60.png" />
      {/* add apple-touch-icon-72x72.png, apple-touch-icon-76x76.png, apple-touch-icon-114x114.png, apple-touch-icon-120x120.png, apple-touch-icon-144x144.png, apple-touch-icon-152x152.png, apple-touch-icon-180x180.png */}
      <link
        rel="icon"
        type="image/png"
        href="/favicon-16x16.png"
        sizes="16x16"
      />
      {/* add favicon-32x32.png, favicon-96x96.png, android-chrome-192x192.png */}
    </Head>
  );
}

5. JSON-LD Schema

JSON-LD, a lightweight Linked Data format, facilitates machine parsing and generation, contributing to its widespread adoption.

This part can be applied to both Pages Router and App Router.

You can easily generate JSON-LD Schema for your website by using the Schema Markup Generator Tool.
And I can put it anywhere, whether inside the head tag or the body tag is fine:

import Head from "next/head";

export default function Page() {
  return (
    <div>
      {/* other parts */}
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
    </div>
  );
}

6. Script Optimization

Script Optimization for General Scripts

Next.js provides a built-in component called <Script> to add external scripts to your website.

For example, you can add Google Analytics to your website by adding the following script tag:

import Head from "next/head";
import Script from "next/script";

export default function Page() {
  return (
    <Head>
      {/* other parts */}
      {process.env.NODE_ENV === "production" && (
        <>
          <Script async strategy="afterInteractive" id="analytics">
            {`
              window.dataLayer = window.dataLayer || [];
              function gtag(){dataLayer.push(arguments);}
              gtag('js', new Date());
              gtag('config', 'G-XXXXXXXXXX');
            `}
          </Script>
        </>
      )}
    </Head>
  );
}

Script Optimization for Common Third-Party Integrations

Next.js App Router introduces a new library called @next/third-parties for:

Google Tag Manager
Google Analytics
Google Maps Embed
Youtube Embed To use the @next/third-parties library, you need to install it:

npm install @next/third-parties

import { GoogleTagManager } from "@next/third-parties/google";
import { GoogleAnalytics } from "@next/third-parties/google";
import Head from "next/head";

export default function Page() {
  return (
    <html lang="en" className="scroll-smooth" suppressHydrationWarning>
      {process.env.NODE_ENV === "production" && (
        <>
          <GoogleAnalytics gaId="G-XXXXXXXXXX" />
          {/* other scripts */}
        </>
      )}
      {/* other parts */}
    </html>
  );
}

7. Image Optimization

This part can be applied to both Pages Router and App Router.

Image optimization is also an important part of SEO as it helps your website load faster.

Faster image rendering directly influences your Google PageSpeed score, which in turn benefits user experience and SEO.

You can use next/image to optimize images in your Next.js website.

import Image from "next/image";

export default function Page() {
  return (
    <Image
      src="https://example/assets/nextjs-seo/thumbnail.png?tr=f-webp"
      alt="Next.js SEO"
      width={1200}
      height={630}
    />
  );
}

For the image format, I prefer to use WebP because it has a smaller size than PNG and JPEG.

Conclusion

Here's a conclusion summarizing the key areas for website performance and SEO optimization in Next.js:

Meta Tags: Implement comprehensive meta tags for improved search engine understanding and display.
JSON-LD Schema: Utilize JSON-LD to provide structured data, enhancing search engine comprehension and rich results.
Sitemap: Generate and submit a sitemap to ensure search engines can effectively crawl and index your website.
robots.txt: Use robots.txt to control search engine crawler access, specifying which pages to crawl or ignore.
Link Tags: Implement <link> tags for canonical URLs, icons, and other essential link-related information.
Script Optimization:
- Leverage Next.js's <Script> component for efficient script loading.
- Utilize @next/third-parties for optimized handling of common third-party scripts.
Image Optimization:
- Use Next.js's <Image> component for optimized image loading and performance.
- Implement a CDN to cache images, improving loading speeds.
- Adopt modern image formats like WebP for reduced file sizes and faster delivery.