DEV Community: Pratik Goswami

Part I: Don't Wait for Data. Render What You Know.

Pratik Goswami — Tue, 19 May 2026 02:30:00 +0000

Part I of the series "Don't Let the User Wait - Render Quickly to Keep Their Attention."

The problem hiding inside SSR

Server-Side Rendering promises the world: fast first paint, SEO-friendly markup, no content flash. For simple pages, it delivers. But real product pages are rarely simple. They need authentication checks, user details and live data to name a few - a cascade of API calls that all have to resolve before the server can respond.

If the page only renders after all data are fetched, the server is just the new bottleneck and the user experience is hurt.

Lets consider the case of a chat based application. The page needs to check user authentication before calling for the user details and user chats. All three API calls - auth, user details, chats - must complete before a single pixel is painted. Meanwhile, the user only sees a white screen and their experience is indistinguishable from a slow client-side app, regardless of whether the work is happening on the server.

"We moved to SSR and our Lighthouse score went up, but users still complain it feels slow." - every other engineering team.

The fix: Render the shell, let components own their data

The key insight is that not all data is equally critical for the initial render. In the case depicted by the image above, auth is critical to determine what the user is shown - you need a valid session before you send anything. But userDetails and chats? Those are content. The page can exist without them, and they can load in after the shell is already painted.

This article explores this using React and Next.js. If you're working with a different stack, the same principle applies at the BFF layer - framework-agnostic and without any dependency on Server Components. That's covered in Part II - coming 27 May.

React Server Components and Suspense make this the natural way to build. The idea splits into two clear phases:

Phase 1 - Render the shell immediately.
The page render is only blocked for auth. Once the session is confirmed, the HTML shell - with navigation, layout and skeleton placeholders - is sent to the browser and rendered. The user sees something real and fast.

Phase 2 - Each component fetches its own data.
UserDetails and Chats are asynchronous Server Components wrapped in Suspense boundaries. They each independently fetch their own data on the server and render their resolved HTML into the page as they complete - no waiting for each other, no coordinating through a parent.

The user lands on a page that is already painted - navigation is visible, layout is in place, skeleton loaders hold the space where content will appear. Then UserDetails and Chats swap in, each one independently, as soon as its data is ready.

Suspense as the rendering contract

React Suspense is the mechanism that wires this process together. Each data-dependent section of the page is wrapped in a <Suspense> boundary with a skeleton fallback. React renders the skeleton immediately and replaces it with the resolved content the moment the component is ready to render.

// app/home/page.tsx (Next.js App Router)
import { Suspense } from 'react'
import { UserDetailsSkeleton, ChatsSkeleton } from './skeletons'

export default async function HomePage() {
  // Only auth blocks here — this is the only awaited call
  const session = await getSession()
  if (!session) return redirect('/login')

  return (
    <main>
      {/* Renders immediately — no data dependency */}
      <Header user={session} />

      {/* Skeleton shown instantly, swapped when data arrives */}
      <Suspense fallback={<UserDetailsSkeleton />}>
        <UserDetails userId={session.id} />
      </Suspense>

      {/* Resolves independently — doesn't wait for UserDetails */}
      <Suspense fallback={<ChatsSkeleton />}>
        <ChatList userId={session.id} />
      </Suspense>
    </main>
  )
}

Each Suspense boundary is independently resolvable. UserDetails can swap in before ChatList is ready and vice versa. The user sees a progressively enriched page rather than a binary flip from white screen to full content.

Each component owns its own fetch

The other half of the pattern is that each async Server Component fetches only what it needs, independently. There's no parent component collecting all the data and passing it down:

// components/UserDetails.tsx
async function UserDetails({ userId }: { userId: string }) {
  const details = await fetch(`/api/users/${userId}/details`)
    .then(r => r.json())

  return <ProfileCard {...details} />
}

// components/ChatList.tsx
async function ChatList({ userId }: { userId: string }) {
  const chats = await fetch(`/api/users/${userId}/chats`)
    .then(r => r.json())

  return <ChatFeed chats={chats} />
}

What React does under the hood:
renderToPipeableStream sends the HTML shell to the browser first. As each Suspense boundary resolves, React emits an inline script chunk over the same open connection. The browser swaps the skeleton for the real content without a full page reload or a separate network request.

Don't forget the error boundary

While Suspense handles the loading state, pair it with an ErrorBoundary to handle failure. This ensures that a broken API call degrades at the component level rather than crashing the whole page:

<ErrorBoundary fallback={<ChatsErrorCard />}>
  <Suspense fallback={<ChatsSkeleton />}>
    <ChatList userId={session.id} />
  </Suspense>
</ErrorBoundary>

Now if ChatList fails - network timeout, downstream 500, or anything else - the rest of the page is completely unaffected. Failed components can be retried either manually or automatically using exponential backoff strategy. Now the page has a significant improvement over the old SSR model where a single API failure would crash the entire render.

What this does to your metrics

Metric	Classic SSR — wait for all	Server Components + Suspense
TTFB	Auth + all API calls combined	Auth only — often 80–90% faster
FCP	After all data resolves	Shell arrives immediately
LCP	Tied to the slowest API call	Each section loads as ready
Error scope	One failure crashes the page	Per-section Error Boundaries
Data ownership	Centralised in page component	Each component owns its fetch

When to apply this pattern

Your page has a mix of critical and non-critical data. The pattern shines when there's a clear hierarchy - shell first, primary content second, secondary content third.

Backend calls have variable latency. If auth is fast but recommendations or chat APIs are slow, don't hold up the whole page. Let the slow sections render independently.

You're on Next.js App Router. Pages Router with getServerSideProps doesn't support this model - all data fetching is centralised and blocking. App Router's async Server Components and loading.tsx files are designed precisely for this pattern.

Summary

The old SSR model treats the page as a single blocking unit - nothing goes to the browser until everything is ready. Server Components and Suspense treat the page as a composition of independently resolvable sections, each with its own data timeline.

Block render only on auth, and render the shell immediately. Let each component own its data and render its content when ready. Pair every Suspense with an ErrorBoundary so failures stay local and can be retried.

The result is a page that feels genuinely fast - not because you moved computation around, but because you changed when the user sees something.

Not on React or Next.js?
The same principle applies - but the fix lives in the BFF, not the frontend framework. Part II covers the framework-agnostic approach using HTTP streaming. Works with Vue, Svelte, Angular, or anything else.

Part II - Don't Wait for APIs. Send What You Have. → Coming 27 May.

Your Portfolio Is Invisible. Here's How I Fixed Mine.

Pratik Goswami — Tue, 12 May 2026 02:30:00 +0000

Everyone is building. AI tools have made it trivially easy to spin up a beautiful portfolio or product site in an afternoon and deploy it to Vercel or Netlify before dinner. But here is the thing nobody talks about: Vercel gives you a URL. It does not give you an audience.

I learned this firsthand. I have had a personal website at pratikgoswami.dev for years. It looked great - it had my projects, experience, contact details - but the only people who ever visited it were recruiters who already had my resume or connections who clicked through from my LinkedIn. The site was essentially a private document with a public URL.

Then, in late April 2026, I spent two days fixing that. Here is exactly what I did and what happened after.

First, Understand Who You Are Actually Building For

Most developers optimize their site for one audience: humans. But your site has two types of readers: humans and machines. And increasingly, it is the machines that decide whether the humans ever find you.

SEO (Search Engine Optimization) is about helping Search Engines (like Google) crawl, understand, and rank your content so people find you through search.
AEO (Answer Engine Optimization) is newer, and arguably more important today. It is about helping AI assistants like ChatGPT, Gemini, and Claude form a confident, accurate understanding of who you are, so they can mention you when someone asks "who are good full-stack developers with fintech experience?"

Think of it this way: SEO gets you on the map. AEO makes you a landmark.

With LLMs becoming the next search interface, both matter. I decided to tackle them together.

The Honest Baseline

Before I made any changes, my Google Search Console data tells an honest story. The site had a tiny trickle of impressions starting in early April, the result of some rudimentary metadata I had set up previously. But it was flat, sparse, and averaging a position of 36+ in search results, effectively invisible.

I deployed my SEO and AEO changes on April 28th, 2026. By April 30th, impressions spiked sharply. In the 12 days since, the site has accumulated 52 impressions, with 2 actual clicks and a 1.8% CTR. Small numbers, but the trajectory is the story. The spike is real and it came immediately after the changes.

Now let me walk you through exactly what I changed.

Part 1: Traditional SEO - Making It Readable for Google

My site is built with Next.js (App Router), TypeScript, and Sanity CMS. It looked clean to any human visitor. To a crawler, it was a meaningless soup of <div> tags.

1. Semantic HTML Refactoring

The simplest change with the highest impact. I replaced generic container divs with meaningful HTML elements.

Before:

<section id="skills-section">
  <div className="skills-section-title">Skills</div>
  <div>
    {skillList.map(({title, skills}) => (
      <div className="skill-container" key="{title}">
        <div className="skill-title">{title}</div>
        <div className="skill-item-container">
          {skills && skills.map((skill, index) => (
            <div className="skill-item" key="{`${title}-${index}`}">{skill}</div>
          ))}
        </div>
      </div>
    ))}
  </div>
</section>

After:

<section id="skills-section" aria-label="Skills">
  <h2 className="skills-section-title">Technical Skills</h2>
  <div className="skills-grid">
    {skillList.map(({ title, skills }) => (
      <article className="skill-container" key="{title}">
        <h3 className="skill-title">{title}</h3>
        <ul className="skill-item-container">
          {skills && skills.map((skill, index) => (
            <li className="skill-item" key="{`${title}-${index}`}">{skill}</li>
          ))}
        </ul>
      </article>
    ))}
  </div>
</section>

Why does this matter? A crawler reads your HTML like an outline. <h1> through <h3> tags are chapter headings. <section> and <article> are meaningful containers. Without them, Googlebot sees a flat document with no hierarchy and has to guess what is important.

2. Fixing Content Discoverability

This one surprised me. I had project details that rendered conditionally, after a user interaction: a click to expand, a tab switch, a state toggle. It looked fine in the browser, but Googlebot crawls the initial DOM, not the post-interaction state. If your content only renders after a click, it effectively does not exist to Google.

I refactored these components to render all content in the initial HTML, using CSS to control visibility rather than React state.

3. Adding Guides for Crawlers

I added robots.ts and sitemap.ts to my project - two small files that do an important job. robots.ts tells crawlers which pages they are allowed to visit. sitemap.ts hands them a complete map of every page on your site so nothing gets missed. Next.js App Router makes this clean.

// app/robots.ts
export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: "*",
      allow: "/",
      disallow: [""], // Routes that you dont want Crawler to see
    },
    sitemap: "https://www.pratikgoswami.dev/sitemap.xml",
  };
}

// app/sitemap.ts
export default function sitemap(): MetadataRoute.Sitemap {
  return [
    {
      url: "https://www.pratikgoswami.dev",
      lastModified: new Date(),
      changeFrequency: "monthly",
      priority: 1,
    },
  ];
}

The last step is submitting your sitemap in Google Search Console. That single action transforms your site from something Google might eventually find into something Google knows exists today.

4. Performance and Core Web Vitals

Google uses Core Web Vitals, specifically LCP (Largest Contentful Paint), as a ranking signal. LCP measures how long it takes for the largest visible element on your page to load - the lower the number, the faster your site feels to a visitor.

I had been importing FontAwesome icons as an external dependency, which added unnecessary weight to the bundle. I replaced the animated canvas background with a native Canvas API implementation, cutting the external dependency entirely and improving load performance.

Part 2: AEO - Making It Readable for AI

Most developers fix their SEO and think the job is done. It is not. Search behavior has fundamentally shifted. People are using ChatGPT, Gemini, and Claude as search engines now, asking them to recommend developers, tools, and products. If an AI model does not know who you are, you are invisible to an entirely new class of search. AEO is how you fix that.

1. JSON-LD Structured Data

Think of JSON-LD as your verified ID card for the internet - it tells search engines which queries you are relevant to, and gives AI models the structured facts they need to represent you accurately.

I added a <script type="application/ld+json"> block to my site's <head> using the Person and SoftwareApplication schemas from Schema.org. This gives AI models explicit, machine-readable facts rather than forcing them to infer who you are from your prose.

<Script
    id="schema-person"
    type="application/ld+json"
    dangerouslySetInnerHTML={{
      __html: JSON.stringify({
          "@context": "https://schema.org",
          "@type": "Person",
          name: "Pratik Goswami",
          jobTitle: "Frontend Software Engineer",
          url: "https://www.pratikgoswami.dev",
          sameAs: [
          "https://www.linkedin.com/in/prtkgoswami",
          "https://github.com/prtkgoswami",
          ],
          worksFor: {
          "@type": "Organization",
          name: "TikTok, IBM",
          },
          description:
          "Frontend Engineer specializing in React, TypeScript, and scalable UI systems.",
      }),
    }}
/>

Without this, an LLM has to guess who you are based on scattered text. With it, you are handing the model a verified fact sheet.

2. The Triangle of Trust - Entity Linking via sameAs

The sameAs property is subtle but powerful. By linking your personal domain to your LinkedIn and GitHub profiles, you are creating a web of verification across multiple authoritative sources.

LLMs build a confidence score around named entities. If "Pratik Goswami" appears on a personal website, a LinkedIn profile, and a GitHub account, and those sources all link to each other, the model develops a high-confidence entity. It knows who you are. Without these links, you are just an unnamed node in a vast graph.

This is the triangle of trust: your domain, LinkedIn, and GitHub. Each point of the triangle reinforces the others.

3. Writing for RAG - Declarative, Specific Descriptions

Retrieval-Augmented Generation (RAG) is how many LLMs fetch context before answering. They pull relevant chunks of text from indexed sources. That means how you write about your projects matters as much as the schema you add.

Vague (bad for RAG):

"Passionate developer who loves building impactful things."

Specific (good for RAG):

"Built Gears Connect, a B2B automotive parts marketplace using Next.js, PostgreSQL, and Stripe, enabling real-time inventory management for 50+ vendors."

The second version is indexable. It is full of specific, searchable facts. An LLM retrieving context for a query like "full-stack developers who have built marketplace apps" can actually use it.

4. JSON-LD Over llms.txt

You may have seen chatter about llms.txt, a proposed standard for helping LLMs read your site, but it is a shortcut, not a foundation.

llms.txt is a plain-text file placed at the root of your domain that gives AI crawlers a human-readable summary of your site, similar to how robots.txt works for search crawlers. Low effort to set up, but also low density. It carries no schema, no entity relationships, and zero influence over search rankings.

JSON-LD does all of that and more. It is a W3C standard understood by Google, Bing, LinkedIn, Perplexity, and SearchGPT simultaneously. It defines explicit relationships - that "Pratik Goswami" is a Person, worksFor specific organizations, and is the author of specific projects. It also unlocks Google Rich Results, putting your job title and links directly in the search listing. llms.txt cannot do any of this.

Part 3: Monitoring - Closing the Loop

Shipping SEO and AEO changes without monitoring is like sending a message and never checking if it was delivered. Monitoring closes the feedback loop - it tells you what Google has indexed, which queries are surfacing your name, and which parts of your site are actually holding a visitor's attention. Without it, you are optimizing blind.

Google Search Console was the first thing I set up, before deploying any changes. Verifying your domain and submitting your sitemap establishes a direct line of communication with Google.

The LLM test is simple and satisfying: ask ChatGPT, Gemini, and Claude "Who is Pratik Goswami?" My site now surfaces accurate, confident responses across all three. That is the AEO working.

Custom Google Analytics tracking using IntersectionObserver lets me track which sections of my site recruiters actually read, not just that they visited. Knowing that the "Job Application Tracker" project card gets more dwell time than others is actionable data, not a vanity metric.

const observer = new IntersectionObserver(
    (entries) => {
        entries.forEach((entry) => {
            const sectionId = entry.target.id;

            if (entry.isIntersecting) {
                // User entered a section
                activeSection.current = sectionId;
                enterTime.current = Date.now();
                sendSectionView(sectionId);
            } else if (activeSection.current === sectionId && enterTime.current) {
                // User left the section → calculate time spent
                const duration = Date.now() - enterTime.current;
                sendTimeSpent(sectionId, duration);
                activeSection.current = null;
                enterTime.current = null;
            }
        });
    },
    { threshold: 0.5 } // Trigger when 50% of a section is visible
);

SECTIONS.forEach((id) => {
    const el = document.getElementById(id);
    if (el) observer.observe(el);
});

Was It Worth It?

In two days of work, the site went from effectively invisible to ranking on the first page of Google for my name, accumulating 52 impressions in 12 days, and being recognized by ChatGPT, Gemini, and Claude when asked who I am.

The numbers are early, but the direction is clear. The spike in the Google Search Console (GSC) chart is immediate and unambiguous.

Here is what I want you to take away:

A beautiful site and a discoverable site are not the same thing. Most portfolios are the former, not the latter.
AEO is not the future. It is right now. LLMs are already answering career questions. If you are not structured for them, you are invisible to them.
The implementation is smaller than you think. Two files, one schema block, and a few hours of refactoring later, my site went from invisible to indexed. The effort was minimal. The compounding visibility was not.
Treat your portfolio like a product. Ship, measure, iterate.

Your Quick-Start Checklist

Pick one item from this list and do it this weekend:

[ ] Replace <div> wrappers with <section>, <article>, and proper <h1>–<h3> hierarchy
[ ] Audit for content hidden behind React state and render it in the initial HTML
[ ] Add robots.ts and sitemap.ts in Next.js App Router
[ ] Submit your sitemap in Google Search Console
[ ] Run PageSpeed Insights and check your LCP score
[ ] Add a Person JSON-LD schema to your <head>
[ ] Add sameAs links to LinkedIn and GitHub in your schema
[ ] Rewrite your project descriptions to be specific, declarative, and technical
[ ] Ask ChatGPT or Gemini who you are and see what they say today

So… What Is Next?

This is just the starting point. The real value of setting up monitoring is that the data now tells me where to focus next - which projects are getting attention, which queries are surfacing my name, and where there is still room to improve. I will keep the structured data updated as my experience grows, revisit the content as AEO standards evolve, and let the analytics guide the next round of changes. The foundation is built. Now it gets to compound.