Server-side rendering (SSR)
- Next.js
- Any page in the
/page folder is pre-rendered (either SSR or static generation)
- actual html is generated on the server and sent to the browser
- good for SEO
- google or other bots can see ur content
- users see content faster
- shines for stuff that needs fast initial lods, like e-commerce sites, blogs, content-heavy pages, etc
Client-side rendering (CSR)
- html file is sent by the server, which contains bundles. browser parses the html, sees
<script> tags and starts downloading the bundles
- happens when react loads and takes over in the browser
- good for dynamic interactions & highly interactive apps where UI changes a lot based on user actions, like dashboards
React server side components
- client components
- That html file generated in server will still include the
<script> tag, since we still need React to run on the client, to handle any interactivity.
- hydration
- instead of conjuring all of the DOM nodes from scratch, it instead adopts the existing HTML
- “watering” the “dry” HTML with the “water” of interactivity and event handlers
- Server Components
- render exclusively on the server
- Their code isn’t included in the JS bundle, and so they never hydrate or re-render
- one way to use → next.js 13.4+, “app router”
with nextjs + react
- the page itself - SSR
- if pages are in
/pages the initial render is SSR
- react components inside - CSR
- once the SSR html loads, react “hydrates” the page (takes over in browser)
- from this point, any dynamic updates (ex. usestate, useeffect, api calls) are CSR
- RN WITH MY BLOG
- im fetching blog posts with
fetch on client side (useEffect), so search engine bots likely won’t see them
- SSR in nextjs
getServerSideProps
- docs
- Fetches data on the server before sending the page to the browser (or bot)
- Bots will see the full list of posts
getStaticProps
- Fetches posts at build time (great for blogs that don’t update every second)
- hybrid
- What it does: Render posts via SSR first, then add real-time updates with CSR.