SSR & SSG Basics — Series 2

Preview — 3 of 10 questions

A page uses a markdown-to-HTML library. Why does keeping that logic in a Server Component shrink the JavaScript sent to the browser?

javascript

import { marked } from 'marked'; // ~35KB
export default async function BlogPost({ content }: { content: string }) {
  return <div dangerouslySetInnerHTML={{ __html: marked(content) }} />;
}

AThe parsing code and its dependencies run and stay entirely on the server — only the resulting HTML is sent to the browser, so the library is never in the client bundle

BServer Components use a more efficient minifier

CMarkdown parsing is faster on the server

DServer Components automatically lazy-load all their imports

Can a Client Component receive searchParams as a prop the way a page.tsx Server Component can?

AYes — searchParams is injected into every component

BNo — a Client Component reads the query string via the useSearchParams() hook from next/navigation; the searchParams prop is only passed to Server Component pages

CNo — query strings are unreadable in the App Router except in middleware

DYes, but only if wrapped in getServerSideProps

How does streaming (via loading.tsx or <Suspense>) change perceived load time compared to buffering all data first?

AIt does not change anything — total time to see all content is identical

BThe browser receives and can paint the static shell and layout almost immediately, while slower parts fill in progressively — perceived performance improves even though the total data-fetch time is unchanged

CIt makes total fetch time faster because requests run in parallel on the client

DIt only affects images, not text

Answer all 10 questions (7 more), see explanations for every answer, and track your score.