From d864c4fa589174ddd906bb679576d2265a20fad1 Mon Sep 17 00:00:00 2001 From: Joshua Chen Date: Mon, 6 Jan 2025 11:55:49 -0500 Subject: [PATCH] New glossary pages for CSR/SSR (#37491) * New glossary pages for CSR/SSR * Update files/en-us/glossary/csr/index.md Co-authored-by: Brian Smith --------- Co-authored-by: Chris Mills Co-authored-by: Brian Smith --- files/en-us/glossary/csr/index.md | 46 +++++++++++++++++++++++++++++++ files/en-us/glossary/ssr/index.md | 29 +++++++++++++++++++ 2 files changed, 75 insertions(+) create mode 100644 files/en-us/glossary/csr/index.md create mode 100644 files/en-us/glossary/ssr/index.md diff --git a/files/en-us/glossary/csr/index.md b/files/en-us/glossary/csr/index.md new file mode 100644 index 000000000000000..3a4900c3847a6e9 --- /dev/null +++ b/files/en-us/glossary/csr/index.md @@ -0,0 +1,46 @@ +--- +title: Client-side rendering (CSR) +slug: Glossary/CSR +page-type: glossary-definition +--- + +{{GlossarySidebar}} + +**Client-side rendering** (CSR) refers to the practice of generating HTML content using JavaScript in the browser. CSR is opposed to {{glossary("SSR", "server-side rendering")}}, where the server generates the HTML content. Both techniques are not mutually exclusive and can be used together in the same application. + +A pure CSR app may return the following HTML content: + +```html + + + + My App + + + +
+ + + +``` + +Then, the actual page content is generated by JavaScript in `bundle.js`, using [DOM manipulation](/en-US/docs/Web/API/Document_Object_Model). + +Benefits of CSR include: + +- Interactivity: any page update, including route transitions, do not require a full page reload. This makes the app feel faster and more responsive. +- Performance: the server only needs to send the initial HTML content and JavaScript assets. Subsequent page updates can be fetched from an API, which can be faster than fetching a full HTML page, and causes less load on the server. + +Both SSR and CSR have their performance tradeoffs, and a mix of SSR and CSR can be used to combine the benefits of both techniques. For example, the server can generate a page skeleton with empty placeholders, and the client can fetch additional data and update the page as needed. + +Note that {{glossary("SPA", "single-page applications")}} do not require the site to be CSR. Modern frameworks, such as [React](/en-US/docs/Learn_web_development/Core/Frameworks_libraries/React_getting_started), [Vue](/en-US/docs/Learn_web_development/Core/Frameworks_libraries/Vue_getting_started), and [Svelte](/en-US/docs/Learn_web_development/Core/Frameworks_libraries/Svelte_getting_started), can be used to build SPAs with SSR capabilities. + +## See also + +- [Introduction to client-side frameworks > server-side rendering](/en-US/docs/Learn_web_development/Core/Frameworks_libraries/Introduction#server-side_rendering) +- [Client-side rendering](https://en.wikipedia.org/wiki/Client-side_rendering) on Wikipedia +- {{glossary("SSR", "Server-side rendering")}} +- {{glossary("SSG", "Static site generator")}} +- {{glossary("SPA", "Single-page application")}} diff --git a/files/en-us/glossary/ssr/index.md b/files/en-us/glossary/ssr/index.md new file mode 100644 index 000000000000000..ca01a8dc5a79d93 --- /dev/null +++ b/files/en-us/glossary/ssr/index.md @@ -0,0 +1,29 @@ +--- +title: Server-side rendering (SSR) +slug: Glossary/SSR +page-type: glossary-definition +--- + +{{GlossarySidebar}} + +**Server-side rendering** (SSR) refers to the practice of generating HTML content on the server and sending it to the client. SSR is opposed to {{glossary("CSR", "client-side rendering")}}, where the client generates the HTML content using JavaScript. Both techniques are not mutually exclusive and can be used together in the same application. + +A {{glossary("SSG", "static site")}} can be considered as SSR (and can be generated using SSR infrastructure), but there are nuanced differences. Content of a static site is generated at build time, not at request time. Static sites often do not need to be deployed on a server at all, and can be served from a {{glossary("CDN")}}. + +The SSR/CSR distinction is more meaningful for sites with dynamic content, for example live-updating or user-specific content. In these cases, for every request, the server generates the HTML content on-the-fly because it is unrealistic to pregenerate every possible page. The HTML file contains near-complete page content, and any JavaScript asset is only to enable interactivity. + +Benefits of SSR include: + +- Accessibility: the page is (somewhat) usable without JavaScript, for example if Internet is slow, the user has disabled JavaScript, or the browser is old and JavaScript fails to run. However, any interactivity or client-side logic will not work. +- Crawler-friendliness: search engines, social media crawlers, and other bots can easily read the content without needing to execute JavaScript. Note that major search engines are capable of executing JavaScript so pure CSR sites can still be indexed, but social media crawlers usually cannot. +- Performance: the server can know ahead-of-time what content is needed and can fetch all necessary data at once, compared to CSR where the client is often only aware of further dependencies when it renders the initial page, causing a waterfall of requests. + +Both SSR and CSR have their performance tradeoffs, and a mix of SSR and CSR can be used to combine the benefits of both techniques. For example, the server can generate a page skeleton with empty placeholders, and the client can fetch additional data and update the page as needed. + +## See also + +- [Introduction to client-side frameworks > server-side rendering](/en-US/docs/Learn_web_development/Core/Frameworks_libraries/Introduction#server-side_rendering) +- [Server-side scripting](https://en.wikipedia.org/wiki/Server-side_scripting) on Wikipedia +- {{glossary("CSR", "Client-side rendering")}} +- {{glossary("SSG", "Static site generator")}} +- {{glossary("SPA", "Single-page application")}}