02/11/2024
đđđĢđ'đŦ đđ§ đ¨đ¯đđĢđ¯đĸđđ° đ¨đ đđĄđ đđĸđđđđĢđđ§đ đĢđđ§đđđĢđĸđ§đ đĻđđđĄđ¨đđŦ đĸđ§ đđđąđ.đŖđŦ đđ§đ đđĄđ đŽđŦđ đđđŦđđŦ, đđđ¯đđ§đđđ đđŦ, đđ§đ đđĸđŦđđđ¯đđ§đđđ đđŦ đđ¨đĢ đđđđĄ, đĸđ§đđĨđŽđđĸđ§đ đđĨđĸđđ§đ đđ§đ đŦđđĢđ¯đđĢ đđ¨đĻđŠđ¨đ§đđ§đđŦ:
đ. đđđĢđ¯đđĢ-đđĸđđ đđđ§đđđĢđĸđ§đ (đđđ)
đđŦđ đđđŦđ:
SSR is ideal for applications that need dynamic content on each request. This is common in e-commerce sites, user dashboards, and content-driven platforms where data frequently changes based on user input or other interactions.
đđ¨đ° đĸđ đđ¨đĢđ¤đŦ:
With SSR, Next.js generates the HTML on the server for each request, sending a fully rendered page to the client.
đđđ¯đđ§đđđ đđŦ:
- đđđ-đ
đĢđĸđđ§đđĨđ˛: Pages are generated with all content server-side, making them highly accessible to search engines.
- đ
đđŦđđđĢ đđ§đĸđđĸđđĨ đđ¨đđ đđ¨đĢ đđ˛đ§đđĻđĸđ đđ¨đ§đđđ§đ:Users receive a pre-rendered page on the first load, reducing the time to interactive.
đđĸđŦđđđ¯đđ§đđđ đđŦ:
- đđĸđ đĄđđĢ đđđĢđ¯đđĢ đđ¨đđ: Every request generates a page, increasing server processing time and cost.
- đđĨđ¨đ°đđĢ đđ¨đĢ đđđđđĸđ đđ¨đ§đđđ§đ: If content doesnât change often, SSR can be inefficient compared to Static Site Generation (SSG).
đ. đđĨđĸđđ§đ-đđĸđđ đđđ§đđđĢđĸđ§đ (đđđ)
đđŦđ đđđŦđ:
Best for single-page applications (SPAs) where SEO is not a priority and fast interactivity is more important. Ideal for dashboards, user profiles, and other user-driven applications where content changes based on client interactions.
đđ¨đ° đĸđ đđ¨đĢđ¤đŦ:
With CSR, the client downloads a minimal HTML shell and JavaScript. The page content is rendered on the client side, which fetches data as needed.
đđđ¯đđ§đđđ đđŦ:
- đđđđŽđđđ đđđĢđ¯đđĢ đđ¨đđ: CSR reduces server demands as pages are generated on the client.
- đđ§đĄđđ§đđđ đđ§đđđĢđđđđĸđ¯đĸđđ˛: Ideal for applications where interactivity is more important than initial load time.
đđĸđŦđđđ¯đđ§đđđ đđŦ:
- đđđ đđĸđĻđĸđđđđĸđ¨đ§đŦ: CSR is not SEO-friendly by default since content is loaded after the initial page load.
- đđĨđ¨đ°đđĢ đ
đĸđĢđŦđ đđ¨đđ đđĸđĻđ: Users wait for JavaScript to load before seeing content, which can affect perceived load times.
đ. đđđđđĸđ đđĸđđ đđđ§đđĢđđđĸđ¨đ§ (đđđ)
đđŦđ đđđŦđ:
Ideal for pages with content that does not change frequently, such as blogs, marketing pages, and documentation sites.
đđ¨đ° đĸđ đđ¨đĢđ¤đŦ:
With SSG, pages are pre-rendered at build time. The HTML is generated once and served on each request, making it efficient for static content.
đđđ¯đđ§đđđ đđŦ:
- đ
đđŦđ đđ¨đđ đđĸđĻđđŦ: Pre-rendered HTML results in quick load times, ideal for performance and user experience.
- đđđđĨđđđĨđ đđ§đ đđ¨đŦđ-đđđđđđđĸđ¯đ: Since the content is static, it can be cached and served from a CDN with minimal server requirements.
- đđđ-đ
đĢđĸđđ§đđĨđ˛: Pages are already rendered, which is beneficial for search engines.
đđĸđŦđđđ¯đđ§đđđ đđŦ:
- đđĸđĻđĸđđđ đđ¨ đđđđđĸđ đđ¨đ§đđđ§đ: Not suitable for frequently changing or user-specific content.
- đđđđŽđĸđĨđđŦ đđ¨đĢ đđŠđđđđđŦ: For content changes, a new build is required, though Next.js offers incremental static regeneration (ISR) to help with this.
đ. đđđĢđ¯đđĢ đđ¨đĻđŠđ¨đ§đđ§đđŦ (đĸđ§đđĢđ¨đđŽđđđ đĸđ§ đđđąđ.đŖđŦ đđ+)
đđŦđ đđđŦđ:
Best for components that need server-only data or processing without needing to run on the client, such as secure data fetching, heavy computations, or logic that should stay on the server for security.
đđ¨đ° đĸđ đđ¨đĢđ¤đŦ:
Server components fetch data and handle logic entirely on the server, only sending the necessary HTML to the client. They do not bundle JavaScript for the client, reducing bundle sizes.
đđđ¯đđ§đđđ đđŦ:
- đđđđĸđđĸđđ§đ đđđđ đ
đđđđĄđĸđ§đ : Fetches data securely on the server, improving client-side security and reducing client load.
- đđđđŽđđđ đđŽđ§đđĨđ đđĸđŗđ: Since JavaScript isnât sent to the client, page load times and interactivity are faster.
- đđ§đĄđđ§đđđ đđđĢđđ¨đĢđĻđđ§đđ: Less data is sent to the client, optimizing both client and server resource use.
đđĸđŦđđđ¯đđ§đđđ đđŦ:
- đđĸđĻđĸđđđ đđ§đđđĢđđđđĸđ¯đĸđđ˛: Server components donât have access to browser APIs, making them less suitable for interactive UI.
- Complexity in Data Flow: Combining server and client components can complicate data management and understanding rendering logic.
đ. đđĨđĸđđ§đ đđ¨đĻđŠđ¨đ§đđ§đđŦ
đđŦđ đđđŦđ:
Client components are used for UI elements that need to interact directly with the user, such as forms, buttons, or components that rely on browser APIs (e.g., local storage, cookies).
đđ¨đ° đĸđ đđ¨đĢđ¤đŦ:
Client components run entirely on the client side. They have full access to browser APIs and can handle interactivity smoothly.
đđđ¯đđ§đđđ đđŦ:
- đ
đŽđĨđĨ đđ§đđđĢđđđđĸđ¯đĸđđ˛: Best suited for elements that need immediate client-side interaction.
- đđđđđŦđŦ đđ¨ đđĢđ¨đ°đŦđđĢ đđđđŦ: Can handle complex interactions using JavaScript features available only on the client side.
đđĸđŦđđđ¯đđ§đđđ đđŦ:
- đđ§đđĢđđđŦđđ đđŽđ§đđĨđ đđĸđŗđ: More JavaScript is sent to the client, which can affect page load and interaction times.
- đđ¨đđđ§đđĸđđĨ đđđ đđĸđĻđĸđđđđĸđ¨đ§đŦ: Since client components are rendered client-side, they may limit SEO depending on how they are used in the page structure.
