` en las tablas para evitar errores de hidratación.
-### Preserve Whitespaces Configuration
+### Configuración de Preservación de Espacios en Blanco
-When using the hydration feature, we recommend using the default setting of `false` for `preserveWhitespaces`. If this setting is not in your tsconfig, the value will be `false` and no changes are required. If you choose to enable preserving whitespaces by adding `preserveWhitespaces: true` to your tsconfig, it is possible you may encounter issues with hydration. This is not yet a fully supported configuration.
+Cuando se usa la característica de hidratación, recomendamos usar la configuración predeterminada de `false` para `preserveWhitespaces`. Si esta configuración no está en tu tsconfig, el valor será `false` y no se requieren cambios. Si eliges habilitar la preservación de espacios en blanco agregando `preserveWhitespaces: true` a tu tsconfig, es posible que encuentres problemas con la hidratación. Esta no es todavía una configuración completamente soportada.
-HELPFUL: Make sure that this setting is set **consistently** in `tsconfig.server.json` for your server and `tsconfig.app.json` for your browser builds. A mismatched value will cause hydration to break.
+ÚTIL: Asegúrate de que esta configuración esté establecida **de forma consistente** en `tsconfig.server.json` para tu servidor y en `tsconfig.app.json` para tus compilaciones del navegador. Un valor inconsistente causará que la hidratación falle.
-If you choose to set this setting in your tsconfig, we recommend to set it only in `tsconfig.app.json` which by default the `tsconfig.server.json` will inherit it from.
+Si eliges establecer esta configuración en tu tsconfig, recomendamos establecerla solo en `tsconfig.app.json`, de la cual `tsconfig.server.json` la heredará de forma predeterminada.
-### Custom or Noop Zone.js are not yet supported
+### Zone.js personalizado o Noop aún no son compatibles
-Hydration relies on a signal from Zone.js when it becomes stable inside an application, so that Angular can start the serialization process on the server or post-hydration cleanup on the client to remove DOM nodes that remained unclaimed.
+La hidratación depende de una señal de Zone.js cuando se vuelve estable dentro de una aplicación, para que Angular pueda iniciar el proceso de serialización en el servidor o la limpieza post-hidratación en el cliente para eliminar los nodos del DOM que permanecieron sin reclamar.
-Providing a custom or a "noop" Zone.js implementation may lead to a different timing of the "stable" event, thus triggering the serialization or the cleanup too early or too late. This is not yet a fully supported configuration and you may need to adjust the timing of the `onStable` event in the custom Zone.js implementation.
+Proporcionar una implementación personalizada o "noop" de Zone.js puede llevar a un tiempo diferente para el evento "stable", activando así la serialización o la limpieza demasiado pronto o demasiado tarde. Esta no es todavía una configuración completamente soportada y puede que necesites ajustar el tiempo del evento `onStable` en la implementación personalizada de Zone.js.
-## Errors
+## Errores
-There are several hydration related errors you may encounter ranging from node mismatches to cases when the `ngSkipHydration` was used on an invalid host node. The most common error case that may occur is due to direct DOM manipulation using native APIs that results in hydration being unable to find or match the expected DOM tree structure on the client that was rendered by the server. The other case you may encounter this type of error was mentioned in the [Valid HTML structure](#valid-html-structure) section earlier. So, make sure the HTML in your templates are using valid structure, and you'll avoid that error case.
+Hay varios errores relacionados con la hidratación que puedes encontrar, desde discrepancias de nodos hasta casos donde `ngSkipHydration` fue usado en un nodo host inválido. El caso de error más común que puede ocurrir se debe a la manipulación directa del DOM usando APIs nativas, lo que resulta en que la hidratación no puede encontrar o hacer coincidir la estructura del árbol del DOM esperada en el cliente que fue renderizada por el servidor. El otro caso donde puedes encontrar este tipo de error fue mencionado en la sección [Estructura HTML válida](#estructura-html-válida) anterior. Por lo tanto, asegúrate de que el HTML en tus plantillas use estructura válida y evitarás ese caso de error.
-For a full reference on hydration related errors, visit the [Errors Reference Guide](/errors).
+Para una referencia completa de los errores relacionados con la hidratación, visita la [Guía de Referencia de Errores](/errors).
-## How to skip hydration for particular components
+## Cómo omitir la hidratación para componentes específicos
-Some components may not work properly with hydration enabled due to some of the aforementioned issues, like [Direct DOM Manipulation](#direct-dom-manipulation). As a workaround, you can add the `ngSkipHydration` attribute to a component's tag in order to skip hydrating the entire component.
+Algunos componentes pueden no funcionar correctamente con la hidratación habilitada debido a algunos de los problemas mencionados anteriormente, como la [Manipulación Directa del DOM](#manipulación-directa-del-dom). Como solución alternativa, puedes agregar el atributo `ngSkipHydration` a la etiqueta de un componente para omitir la hidratación del componente completo.
```angular-html
Large component placeholder
+}
+```
+
+#### `hydrate on viewport`
+
+The `hydrate on viewport` trigger loads the deferrable view's dependencies and hydrates the corresponding page of the app when the specified content enters the viewport using the
+[Intersection Observer API](https://developer.mozilla.org/docs/Web/API/Intersection_Observer_API).
+
+```angular-html
+@defer (hydrate on viewport) {
+ Large component placeholder
+}
+```
+
+#### `hydrate on interaction`
+
+The `hydrate on interaction` trigger loads the deferrable view's dependencies and hydrates the content when the user interacts with the specified element through
+`click` or `keydown` events.
+
+```angular-html
+@defer (hydrate on interaction) {
+ Large component placeholder
+}
+```
+
+#### `hydrate on hover`
+
+The `hydrate on hover` trigger loads the deferrable view's dependencies and hydrates the content when the mouse has hovered over the triggered area through the
+`mouseover` and `focusin` events.
+
+```angular-html
+@defer (hydrate on hover) {
+ Large component placeholder
+}
+```
+
+#### `hydrate on immediate`
+
+The `hydrate on immediate` trigger loads the deferrable view's dependencies and hydrates the content immediately. This means that the deferred block loads as soon
+as all other non-deferred content has finished rendering.
+
+```angular-html
+@defer (hydrate on immediate) {
+ Large component placeholder
+}
+```
+
+#### `hydrate on timer`
+
+The `hydrate on timer` trigger loads the deferrable view's dependencies and hydrates the content after a specified duration.
+
+```angular-html
+@defer (hydrate on timer(500ms)) {
+ Large component placeholder
+}
+```
+
+The duration parameter must be specified in milliseconds (`ms`) or seconds (`s`).
+
+### `hydrate when`
+
+The `hydrate when` trigger accepts a custom conditional expression and loads the deferrable view's dependencies and hydrates the content when the
+condition becomes truthy.
+
+```angular-html
+@defer (hydrate when condition) {
+ Large component placeholder
+}
+```
+
+NOTE: `hydrate when` conditions only trigger when they are the top-most dehydrated `@defer` block. The condition provided for the trigger is
+specified in the parent component, which needs to exist before it can be triggered. If the parent block is dehydrated, that expression will not yet
+be resolvable by Angular.
+
+### `hydrate never`
+
+The `hydrate never` allows users to specify that the content in the defer block should remain dehydrated indefinitely, effectively becoming static
+content. Note that this applies to the initial render only. During a subsequent client-side render, a `@defer` block with `hydrate never` would
+still fetch dependencies, as hydration only applies to initial load of server-side rendered content. In the example below, subsequent client-side
+renders would load the `@defer` block dependencies on viewport.
+
+```angular-html
+@defer (on viewport; hydrate never) {
+ Large component placeholder
+}
+```
+
+NOTE: Using `hydrate never` prevents hydration of the entire nested subtree of a given `@defer` block. No other `hydrate` triggers fire for content nested underneath that block.
+
+## Hydrate triggers alongside regular triggers
+
+Hydrate triggers are additional triggers that are used alongside regular triggers on a `@defer` block. Hydration is an initial load optimization, and that means hydrate triggers only apply to that initial load. Any subsequent client side render will still use the regular trigger.
+
+```angular-html
+@defer (on idle; hydrate on interaction) {
+ Example Placeholder
+}
+```
+
+In this example, on the initial load, the `hydrate on interaction` applies. Hydration will be triggered on interaction with the `Child placeholder
+ }
+} @placeholder{
+ Parent Placeholder
+}
+```
+
+In the above example, hovering over the nested `@defer` block triggers hydration. The parent `@defer` block with the `
+
+ng add @angular/ssr
+
+
+
+
+
+To create an application with prerendering capabilities from the beginning use the [`ng new --ssr`](tools/cli/setup-local) command.
+
+
+
+Once SSR is added, you can generate the static pages by running the build command:
+
+
+
+ng build
+
+
+
+### Build options for prerender
+
+The application builder `prerender` option can be either a Boolean or an Object for more fine-tuned configuration.
+When the option is `false`, no prerendering is done. When it is `true`, all options use the default value. When it is an Object, each option can be individually configured.
+
+| Options | Details | Default Value |
+| :--------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------ |
+| `discoverRoutes` | Whether the builder should process the Angular Router configuration to find all unparameterized routes and prerender them. | `true` |
+| `routesFile` | The path to a file that contains a list of all routes to prerender, separated by newlines. This option is useful if you want to prerender routes with parameterized URLs. | |
+
+
+
+{
+ "projects": {
+ "my-app": {
+ "architect": {
+ "build": {
+ "builder": "@angular-devkit/build-angular:application",
+ "options": {
+ "prerender": {
+ "discoverRoutes": false
+ }
+ }
+ }
+ }
+ }
+ }
+}
+
+
+
+### Prerendering parameterized routes
+
+You can prerender parameterized routes using the `routesFile` option. An example of a parameterized route is `product/:id`, where `id` is dynamically provided. To specify these routes, they should be listed in a text file, with each route on a separate line.
+
+For an app with a large number of parameterized routes, consider generating this file using a script before running `ng build`.
+
+
+
+/products/1
+/products/555
+
+
+
+With routes specified in the `routes.txt` file, use the `routesFile` option to configure the builder to prerender the product routes.
+
+
+
+{
+ "projects": {
+ "my-app": {
+ "architect": {
+ "build": {
+ "builder": "@angular-devkit/build-angular:application",
+ "options": {
+ "prerender": {
+ "routesFile": "routes.txt"
+ }
+ }
+ }
+ }
+ }
+ }
+}
+
+
+
+This configures `ng build` to prerender `/products/1` and `/products/555` at build time.
diff --git a/adev-es/src/content/guide/prerendering.md b/adev-es/src/content/guide/prerendering.md
index e9b14c1..6fdf76e 100644
--- a/adev-es/src/content/guide/prerendering.md
+++ b/adev-es/src/content/guide/prerendering.md
@@ -1,14 +1,14 @@
-# Prerendering (SSG)
+# Prerenderización (SSG)
-Prerendering, commonly referred to as Static Site Generation (SSG), represents the method by which pages are rendered to static HTML files during the build process.
+La prerenderización, comúnmente conocida como Generación de Sitios Estáticos (SSG), representa el método por el cual las páginas se renderizan como archivos HTML estáticos durante el proceso de compilación.
-Prerendering maintains the same performance benefits of [server-side rendering (SSR)](guide/ssr#why-use-server-side-rendering) but achieves a reduced Time to First Byte (TTFB), ultimately enhancing user experience. The key distinction lies in its approach that pages are served as static content, and there is no request-based rendering.
+La prerenderización mantiene los mismos beneficios de rendimiento del [renderizado del lado del servidor (SSR)](guide/ssr#why-use-server-side-rendering), pero logra un menor Time to First Byte (TTFB), mejorando en última instancia la experiencia del usuario. La distinción clave radica en su enfoque: las páginas se sirven como contenido estático y no hay renderización basada en peticiones.
-When the data necessary for server-side rendering remains consistent across all users, the strategy of prerendering emerges as a valuable alternative. Rather than dynamically rendering pages for each user request, prerendering takes a proactive approach by rendering them in advance.
+Cuando los datos necesarios para la renderización del lado del servidor son consistentes para todos los usuarios, la estrategia de prerenderización surge como una alternativa valiosa. En lugar de renderizar páginas dinámicamente para cada petición del usuario, la prerenderización adopta un enfoque proactivo al renderizarlas de antemano.
-## How to prerender a page
+## Cómo prerenderizar una página
-To prerender a static page, add SSR capabilities to your application with the following Angular CLI command:
+Para prerenderizar una página estática, añade las capacidades de SSR a tu aplicación con el siguiente comando del CLI de Angular:
@@ -18,11 +18,11 @@ ng add @angular/ssr
-To create an application with prerendering capabilities from the beginning use the [`ng new --ssr`](tools/cli/setup-local) command.
+Para crear una aplicación con capacidades de prerenderización desde el principio, usa el comando [`ng new --ssr`](tools/cli/setup-local).
-Once SSR is added, you can generate the static pages by running the build command:
+Una vez que SSR esté añadido, puedes generar las páginas estáticas ejecutando el comando de compilación:
@@ -30,15 +30,14 @@ ng build
-### Build options for prerender
+### Opciones de compilación para prerenderizar
-The application builder `prerender` option can be either a Boolean or an Object for more fine-tuned configuration.
-When the option is `false`, no prerendering is done. When it is `true`, all options use the default value. When it is an Object, each option can be individually configured.
+La opción `prerender` del builder de la aplicación puede ser un booleano o un objeto para una configuración más detallada. Cuando la opción es `false`, no se realiza ninguna prerenderización. Cuando es `true`, todas las opciones usan el valor predeterminado. Cuando es un objeto, cada opción puede configurarse individualmente.
-| Options | Details | Default Value |
-| :--------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------ |
-| `discoverRoutes` | Whether the builder should process the Angular Router configuration to find all unparameterized routes and prerender them. | `true` |
-| `routesFile` | The path to a file that contains a list of all routes to prerender, separated by newlines. This option is useful if you want to prerender routes with parameterized URLs. | |
+| Opciones | Detalles | Valor predeterminado |
+| :--------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------- |
+| `discoverRoutes` | Si el builder debe procesar la configuración del Router de Angular para encontrar todas las rutas sin parámetros y prerenderizarlas. | `true` |
+| `routesFile` | La ruta a un archivo que contiene una lista de todas las rutas a prerenderizar, separadas por saltos de línea. Esta opción es útil si deseas prerenderizar rutas con URLs parametrizadas. | |
@@ -61,11 +60,11 @@ When the option is `false`, no prerendering is done. When it is `true`, all opti
-### Prerendering parameterized routes
+### Prerenderización de rutas parametrizadas
-You can prerender parameterized routes using the `routesFile` option. An example of a parameterized route is `product/:id`, where `id` is dynamically provided. To specify these routes, they should be listed in a text file, with each route on a separate line.
+Puedes prerenderizar rutas parametrizadas usando la opción `routesFile`. Un ejemplo de una ruta parametrizada es `product/:id`, donde `id` se proporciona de forma dinámica. Para especificar estas rutas, deben listarse en un archivo de texto, con cada ruta en una línea separada.
-For an app with a large number of parameterized routes, consider generating this file using a script before running `ng build`.
+Para una aplicación con un gran número de rutas parametrizadas, considera generar este archivo usando un script antes de ejecutar `ng build`.
@@ -74,7 +73,7 @@ For an app with a large number of parameterized routes, consider generating this
-With routes specified in the `routes.txt` file, use the `routesFile` option to configure the builder to prerender the product routes.
+Con las rutas especificadas en el archivo `routes.txt`, usa la opción `routesFile` para configurar el builder y prerenderizar las rutas de productos.
@@ -97,4 +96,4 @@ With routes specified in the `routes.txt` file, use the `routesFile` option to c
-This configures `ng build` to prerender `/products/1` and `/products/555` at build time.
+Esto configura `ng build` para prerenderizar `/products/1` y `/products/555` en tiempo de compilación.
diff --git a/adev-es/src/content/guide/ssr.en.md b/adev-es/src/content/guide/ssr.en.md
new file mode 100644
index 0000000..bd88fbd
--- /dev/null
+++ b/adev-es/src/content/guide/ssr.en.md
@@ -0,0 +1,534 @@
+# Server and hybrid rendering
+
+Angular ships all applications as client-side rendered (CSR) by default. While this approach delivers an initial payload that's lightweight, it introduces trade-offs including slower load times, degraded performance metrics, and higher resource demands since the user's device performs most of the computations. As a result, many applications achieve significant performance improvements by integrating server-side rendering (SSR) into a hybrid rendering strategy.
+
+## What is hybrid rendering?
+
+Hybrid rendering allows developers to leverage the benefits of server-side rendering (SSR), pre-rendering (also known as "static site generation" or SSG) and client-side rendering (CSR) to optimize your Angular application. It gives you fine-grained control over how the different parts of your app are rendered to give your users the best experience possible.
+
+## Setting up hybrid rendering
+
+You can create a **new** project with hybrid rendering by using the server-side rendering flag (i.e., `--ssr`) with the Angular CLI `ng new` command:
+
+```shell
+ng new --ssr
+```
+
+You can also enable hybrid rendering by adding server-side rendering to an existing project with the `ng add` command:
+
+```shell
+ng add @angular/ssr
+```
+
+NOTE: By default, Angular prerenders your entire application and generates a server file. To disable this and create a fully static app, set `outputMode` to `static`. To enable SSR, update the server routes to use `RenderMode.Server`. For more details, see [`Server routing`](#server-routing) and [`Generate a fully static application`](#generate-a-fully-static-application).
+
+## Server routing
+
+### Configuring server routes
+
+You can create a server route config by declaring an array of [`ServerRoute`](api/ssr/ServerRoute 'API reference') objects. This configuration typically lives in a file named `app.routes.server.ts`.
+
+```typescript
+// app.routes.server.ts
+import { RenderMode, ServerRoute } from '@angular/ssr';
+
+export const serverRoutes: ServerRoute[] = [
+ {
+ path: '', // This renders the "/" route on the client (CSR)
+ renderMode: RenderMode.Client,
+ },
+ {
+ path: 'about', // This page is static, so we prerender it (SSG)
+ renderMode: RenderMode.Prerender,
+ },
+ {
+ path: 'profile', // This page requires user-specific data, so we use SSR
+ renderMode: RenderMode.Server,
+ },
+ {
+ path: '**', // All other routes will be rendered on the server (SSR)
+ renderMode: RenderMode.Server,
+ },
+];
+```
+
+You can add this config to your application with [`provideServerRendering`](api/ssr/provideServerRendering 'API reference') using the [`withRoutes`](api/ssr/withRoutes 'API reference') function:
+
+```typescript
+import { provideServerRendering, withRoutes } from '@angular/ssr';
+import { serverRoutes } from './app.routes.server';
+
+// app.config.server.ts
+const serverConfig: ApplicationConfig = {
+ providers: [
+ provideServerRendering(withRoutes(serverRoutes)),
+ // ... other providers ...
+ ]
+};
+```
+
+When using the [App shell pattern](ecosystem/service-workers/app-shell), you must specify the component to be used as the app shell for client-side rendered routes. To do this, use the [`withAppShell`](api/ssr/withAppShell 'API reference') feature:
+
+```typescript
+import { provideServerRendering, withRoutes, withAppShell } from '@angular/ssr';
+import { AppShellComponent } from './app-shell/app-shell.component';
+
+const serverConfig: ApplicationConfig = {
+ providers: [
+ provideServerRendering(
+ withRoutes(serverRoutes),
+ withAppShell(AppShellComponent),
+ ),
+ // ... other providers ...
+ ]
+};
+```
+
+### Rendering modes
+
+The server routing configuration lets you specify how each route in your application should render by setting a [`RenderMode`](api/ssr/RenderMode 'API reference'):
+
+| Rendering mode | Description |
+| ------------------- | ----------------------------------------------------------------------------------------------------------- |
+| **Server (SSR)** | Renders the application on the server for each request, sending a fully populated HTML page to the browser. |
+| **Client (CSR)** | Renders the application in the browser. This is the default Angular behavior. |
+| **Prerender (SSG)** | Prerenders the application at build time, generating static HTML files for each route. |
+
+#### Choosing a rendering mode
+
+Each rendering mode has different benefits and drawbacks. You can choose rendering modes based on the specific needs of your application.
+
+##### Client-side rendering (CSR)
+
+Client-side rendering has the simplest development model, as you can write code that assumes it always runs in a web browser. This lets you use a wide range of client-side libraries that also assume they run in a browser.
+
+Client-side rendering generally has worse performance than other rendering modes, as it must download, parse, and execute your page's JavaScript before the user can see any rendered content. If your page fetches more data from the server as it renders, users also have to wait for those additional requests before they can view the complete content.
+
+If your page is indexed by search crawlers, client-side rendering may negatively affect search engine optimization (SEO), as search crawlers have limits to how much JavaScript they execute when indexing a page.
+
+When client-side rendering, the server does not need to do any work to render a page beyond serving static JavaScript assets. You may consider this factor if server cost is a concern.
+
+Applications that support installable, offline experiences with [service workers](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) can rely on client-side rendering without needing to communicate with a server.
+
+##### Server-side rendering (SSR)
+
+Server-side rendering offers faster page loads than client-side rendering. Instead of waiting for JavaScript to download and run, the server directly renders an HTML document upon receiving a request from the browser. The user experiences only the latency necessary for the server to fetch data and render the requested page. This mode also eliminates the need for additional network requests from the browser, as your code can fetch data during rendering on the server.
+
+Server-side rendering generally has excellent search engine optimization (SEO), as search crawlers receive a fully rendered HTML document.
+
+Server-side rendering requires you to author code that does not strictly depend on browser APIs and limits your selection of JavaScript libraries that assume they run in a browser.
+
+When server-side rendering, your server runs Angular to produce an HTML response for every request which may increase server hosting costs.
+
+##### Build-time prerendering
+
+Prerendering offers faster page loads than both client-side rendering and server-side rendering. Because prerendering creates HTML documents at _build-time_, the server can directly respond to requests with the static HTML document without any additional work.
+
+Prerendering requires that all information necessary to render a page is available at _build-time_. This means that prerendered pages cannot include any data to the specific user loading the page. Prerendering is primarily useful for pages that are the same for all users of your application.
+
+Because prerendering occurs at build-time, it may add significant time to your production builds. Using [`getPrerenderParams`](api/ssr/ServerRoutePrerenderWithParams#getPrerenderParams 'API reference') to produce a large number of HTML documents may affect the total file size of your deployments, and thus lead to slower deployments.
+
+Prerendering generally has excellent search engine optimization (SEO), as search crawlers receive a fully rendered HTML document.
+
+Prerendering requires you to author code that does not strictly depend on browser APIs and limits your selection of JavaScript libraries that assume they run in a browser.
+
+Prerendering incurs extremely little overhead per server request, as your server responds with static HTML documents. Static files are also easily cached by Content Delivery Networks (CDNs), browsers, and intermediate caching layers for even faster subsequent page loads. Fully static sites can also be deployed solely through a CDN or static file server, eliminating the need to maintain a custom server runtime for your application. This enhances scalability by offloading work from an application web server, making it particularly beneficial for high-traffic applications.
+
+NOTE: When using Angular service worker, the first request is server-rendered, but all subsequent requests are handled by the service worker and rendered client-side.
+
+### Setting headers and status codes
+
+You can set custom headers and status codes for individual server routes using the `headers` and `status` properties in the `ServerRoute` configuration.
+
+```typescript
+// app.routes.server.ts
+import { RenderMode, ServerRoute } from '@angular/ssr';
+
+export const serverRoutes: ServerRoute[] = [
+ {
+ path: 'profile',
+ renderMode: RenderMode.Server,
+ headers: {
+ 'X-My-Custom-Header': 'some-value',
+ },
+ status: 201,
+ },
+ // ... other routes
+];
+```
+
+### Redirects
+
+Angular handles redirects specified by the [`redirectTo`](api/router/Route#redirectTo 'API reference') property in route configurations, differently on the server-side.
+
+**Server-Side Rendering (SSR)**
+Redirects are performed using standard HTTP redirects (e.g., 301, 302) within the server-side rendering process.
+
+**Prerendering (SSG)**
+Redirects are implemented as "soft redirects" using [`{{ ... }} `,
+})
+export class MyComponent {
+ contentRef = viewChild.required('content');
+
+ constructor() {
+ afterNextRender(() => {
+ // Safe to check `scrollHeight` because this will only run in the browser, not the server.
+ console.log('content height: ' + this.contentRef().nativeElement.scrollHeight);
+ });
+ }
+}
+```
+
+## Setting providers on the server
+
+On the server side, top level provider values are set once when the application code is initially parsed and evaluated.
+This means that providers configured with `useValue` will keep their value across multiple requests, until the server application is restarted.
+
+If you want to generate a new value for each request, use a factory provider with `useFactory`. The factory function will run for every incoming request, ensuring that a new value is created and assigned to the token each time.
+
+## Accessing Document via DI
+
+When working with server-side rendering, you should avoid directly referencing browser-specific globals like `document`. Instead, use the [`DOCUMENT`](api/core/DOCUMENT) token to access the document object in a platform-agnostic way.
+
+```ts
+import { Injectable, inject, DOCUMENT } from '@angular/core';
+
+@Injectable({ providedIn: 'root' })
+export class CanonicalLinkService {
+ private readonly document = inject(DOCUMENT);
+
+ // During server rendering, inject a My Component `,
+})
+export class MyComponent {
+ constructor() {
+ const request = inject(REQUEST);
+ console.log(request?.url);
+ }
+}
+```
+
+IMPORTANT: The above tokens will be `null` in the following scenarios:
+
+- During the build processes.
+- When the application is rendered in the browser (CSR).
+- When performing static site generation (SSG).
+- During route extraction in development (at the time of the request).
+
+## Generate a fully static application
+
+By default, Angular prerenders your entire application and generates a server file for handling requests. This allows your app to serve pre-rendered content to users. However, if you prefer a fully static site without a server, you can opt out of this behavior by setting the `outputMode` to `static` in your `angular.json` configuration file.
+
+When `outputMode` is set to `static`, Angular generates pre-rendered HTML files for each route at build time, but it does not generate a server file or require a Node.js server to serve the app. This is useful for deploying to static hosting providers where a backend server is not needed.
+
+To configure this, update your `angular.json` file as follows:
+
+```json
+{
+ "projects": {
+ "your-app": {
+ "architect": {
+ "build": {
+ "options": {
+ "outputMode": "static"
+ }
+ }
+ }
+ }
+ }
+}
+```
+
+## Caching data when using HttpClient
+
+`HttpClient` caches outgoing network requests when running on the server. This information is serialized and transferred to the browser as part of the initial HTML sent from the server. In the browser, `HttpClient` checks whether it has data in the cache and if so, reuses it instead of making a new HTTP request during initial application rendering. `HttpClient` stops using the cache once an application becomes [stable](api/core/ApplicationRef#isStable) while running in a browser.
+
+### Configuring the caching options
+
+You can customize how Angular caches HTTP responses during server‑side rendering (SSR) and reuses them during hydration by configuring `HttpTransferCacheOptions`.
+This configuration is provided globally using `withHttpTransferCacheOptions` inside `provideClientHydration()`.
+
+By default, `HttpClient` caches all `HEAD` and `GET` requests which don't contain `Authorization` or `Proxy-Authorization` headers. You can override those settings by using `withHttpTransferCacheOptions` to the hydration configuration.
+
+```ts
+import { bootstrapApplication } from '@angular/platform-browser';
+import { provideClientHydration, withHttpTransferCacheOptions } from '@angular/platform-browser';
+
+bootstrapApplication(AppComponent, {
+ providers: [
+ provideClientHydration(
+ withHttpTransferCacheOptions({
+ includeHeaders: ['ETag', 'Cache-Control'],
+ filter: (req) => !req.url.includes('/api/profile'),
+ includePostRequests: true,
+ includeRequestsWithAuthHeaders: false,
+ }),
+ ),
+ ],
+});
+```
+
+---
+
+### `includeHeaders`
+
+Specifies which headers from the server response should be included in cached entries.
+No headers are included by default.
+
+```ts
+withHttpTransferCacheOptions({
+ includeHeaders: ['ETag', 'Cache-Control'],
+});
+```
+
+IMPORTANT: Avoid including sensitive headers like authentication tokens. These can leak user‑specific data between requests.
+
+---
+
+### `includePostRequests`
+
+By default, only `GET` and `HEAD` requests are cached.
+You can enable caching for `POST` requests when they are used as read operations such as GraphQL queries.
+
+```ts
+withHttpTransferCacheOptions({
+ includePostRequests: true,
+});
+```
+
+Use this only when `POST` requests are **idempotent** and safe to reuse between server and client renders.
+
+---
+
+### `includeRequestsWithAuthHeaders`
+
+Determines whether requests containing `Authorization` or `Proxy‑Authorization` headers are eligible for caching.
+By default, these are excluded to prevent caching user‑specific responses.
+
+```ts
+withHttpTransferCacheOptions({
+ includeRequestsWithAuthHeaders: true,
+});
+```
+
+Enable only when authentication headers do **not** affect the response content (for example, public tokens for analytics APIs).
+
+### Per‑request overrides
+
+You can override caching behavior for a specific request using the `transferCache` request option.
+
+```ts
+// Include specific headers for this request
+http.get('/api/profile', { transferCache: { includeHeaders: ['CustomHeader'] } });
+```
+
+### Disabling caching
+
+You can disable HTTP caching of requests sent from the server either globally or individually.
+
+#### Globally
+
+To disable caching for all requests in your application, use the `withNoHttpTransferCache` feature:
+
+```ts
+import { bootstrapApplication, provideClientHydration, withNoHttpTransferCache } from '@angular/platform-browser';
+
+bootstrapApplication(AppComponent, {
+ providers: [
+ provideClientHydration(withNoHttpTransferCache())
+ ]
+});
+```
+
+#### `filter`
+
+You can also selectively disable caching for certain requests using the [`filter`](api/common/http/HttpTransferCacheOptions) option in `withHttpTransferCacheOptions`. For example, you can disable caching for a specific API endpoint:
+
+```ts
+import { bootstrapApplication, provideClientHydration, withHttpTransferCacheOptions } from '@angular/platform-browser';
+
+bootstrapApplication(AppComponent, {
+ providers: [
+ provideClientHydration(withHttpTransferCacheOptions({
+ filter: (req) => !req.url.includes('/api/sensitive-data')
+ }))
+ ]
+});
+```
+
+Use this option to exclude endpoints with user‑specific or dynamic data (for example `/api/profile`).
+
+#### Individually
+
+To disable caching for an individual request, you can specify the [`transferCache`](api/common/http/HttpRequest#transferCache) option in an `HttpRequest`.
+
+```ts
+httpClient.get('/api/sensitive-data', { transferCache: false });
+```
+
+## Configuring a server
+
+### Node.js
+
+The `@angular/ssr/node` extends `@angular/ssr` specifically for Node.js environments. It provides APIs that make it easier to implement server-side rendering within your Node.js application. For a complete list of functions and usage examples, refer to the [`@angular/ssr/node` API reference](api/ssr/node/AngularNodeAppEngine) API reference.
+
+```ts
+// server.ts
+import { AngularNodeAppEngine, createNodeRequestHandler, writeResponseToNodeResponse } from '@angular/ssr/node';
+import express from 'express';
+
+const app = express();
+const angularApp = new AngularNodeAppEngine();
+
+app.use('*', (req, res, next) => {
+ angularApp
+ .handle(req)
+ .then(response => {
+ if (response) {
+ writeResponseToNodeResponse(response, res);
+ } else {
+ next(); // Pass control to the next middleware
+ }
+ })
+ .catch(next);
+});
+
+/**
+ * The request handler used by the Angular CLI (dev-server and during build).
+ */
+export const reqHandler = createNodeRequestHandler(app);
+```
+
+### Non-Node.js
+
+The `@angular/ssr` provides essential APIs for server-side rendering your Angular application on platforms other than Node.js. It leverages the standard [`Request`](https://developer.mozilla.org/en-US/docs/Web/API/Request) and [`Response`](https://developer.mozilla.org/en-US/docs/Web/API/Response) objects from the Web API, enabling you to integrate Angular SSR into various server environments. For detailed information and examples, refer to the [`@angular/ssr` API reference](api/ssr/AngularAppEngine).
+
+```ts
+// server.ts
+import { AngularAppEngine, createRequestHandler } from '@angular/ssr';
+
+const angularApp = new AngularAppEngine();
+
+/**
+ * This is a request handler used by the Angular CLI (dev-server and during build).
+ */
+export const reqHandler = createRequestHandler(async (req: Request) => {
+ const res: Response|null = await angularApp.render(req);
+
+ // ...
+});
+```
diff --git a/adev-es/src/content/guide/ssr.md b/adev-es/src/content/guide/ssr.md
index bd88fbd..34c444b 100644
--- a/adev-es/src/content/guide/ssr.md
+++ b/adev-es/src/content/guide/ssr.md
@@ -1,32 +1,32 @@
-# Server and hybrid rendering
+# Renderización en el servidor y renderización híbrida
-Angular ships all applications as client-side rendered (CSR) by default. While this approach delivers an initial payload that's lightweight, it introduces trade-offs including slower load times, degraded performance metrics, and higher resource demands since the user's device performs most of the computations. As a result, many applications achieve significant performance improvements by integrating server-side rendering (SSR) into a hybrid rendering strategy.
+Angular distribuye todas las aplicaciones con renderización del lado del cliente (CSR) de forma predeterminada. Si bien este enfoque proporciona una carga inicial liviana, introduce compromisos que incluyen tiempos de carga más lentos, métricas de rendimiento degradadas y mayores demandas de recursos, ya que el dispositivo del usuario realiza la mayor parte de los cálculos. Como resultado, muchas aplicaciones logran mejoras significativas de rendimiento al integrar la renderización del lado del servidor (SSR) en una estrategia de renderización híbrida.
-## What is hybrid rendering?
+## ¿Qué es la renderización híbrida?
-Hybrid rendering allows developers to leverage the benefits of server-side rendering (SSR), pre-rendering (also known as "static site generation" or SSG) and client-side rendering (CSR) to optimize your Angular application. It gives you fine-grained control over how the different parts of your app are rendered to give your users the best experience possible.
+La renderización híbrida permite a los desarrolladores aprovechar los beneficios de la renderización del lado del servidor (SSR), el pre-renderizado (también conocido como "generación de sitios estáticos" o SSG) y la renderización del lado del cliente (CSR) para optimizar tu aplicación Angular. Te brinda un control detallado sobre cómo se renderizan las diferentes partes de tu aplicación para ofrecer a tus usuarios la mejor experiencia posible.
-## Setting up hybrid rendering
+## Configurando la renderización híbrida
-You can create a **new** project with hybrid rendering by using the server-side rendering flag (i.e., `--ssr`) with the Angular CLI `ng new` command:
+Puedes crear un proyecto **nuevo** con renderización híbrida utilizando el flag de renderización del lado del servidor (es decir, `--ssr`) con el comando `ng new` de Angular CLI:
```shell
ng new --ssr
```
-You can also enable hybrid rendering by adding server-side rendering to an existing project with the `ng add` command:
+También puedes habilitar la renderización híbrida añadiendo la renderización del lado del servidor a un proyecto existente con el comando `ng add`:
```shell
ng add @angular/ssr
```
-NOTE: By default, Angular prerenders your entire application and generates a server file. To disable this and create a fully static app, set `outputMode` to `static`. To enable SSR, update the server routes to use `RenderMode.Server`. For more details, see [`Server routing`](#server-routing) and [`Generate a fully static application`](#generate-a-fully-static-application).
+NOTA: De forma predeterminada, Angular pre-renderiza toda tu aplicación y genera un archivo de servidor. Para deshabilitar esto y crear una aplicación completamente estática, establece `outputMode` en `static`. Para habilitar SSR, actualiza las rutas del servidor para usar `RenderMode.Server`. Para más detalles, consulta [`Enrutamiento en el servidor`](#enrutamiento-en-el-servidor) y [`Generar una aplicación completamente estática`](#generar-una-aplicación-completamente-estática).
-## Server routing
+## Enrutamiento en el servidor
-### Configuring server routes
+### Configurando rutas del servidor
-You can create a server route config by declaring an array of [`ServerRoute`](api/ssr/ServerRoute 'API reference') objects. This configuration typically lives in a file named `app.routes.server.ts`.
+Puedes crear una configuración de rutas del servidor declarando un array de objetos [`ServerRoute`](api/ssr/ServerRoute 'API reference'). Esta configuración generalmente se encuentra en un archivo llamado `app.routes.server.ts`.
```typescript
// app.routes.server.ts
@@ -34,25 +34,25 @@ import { RenderMode, ServerRoute } from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{
- path: '', // This renders the "/" route on the client (CSR)
+ path: '', // Esta ruta renderiza "/" en el cliente (CSR)
renderMode: RenderMode.Client,
},
{
- path: 'about', // This page is static, so we prerender it (SSG)
+ path: 'about', // Esta página es estática, por lo que la pre-renderizamos (SSG)
renderMode: RenderMode.Prerender,
},
{
- path: 'profile', // This page requires user-specific data, so we use SSR
+ path: 'profile', // Esta página requiere datos específicos del usuario, por lo que usamos SSR
renderMode: RenderMode.Server,
},
{
- path: '**', // All other routes will be rendered on the server (SSR)
+ path: '**', // Todas las demás rutas se renderizarán en el servidor (SSR)
renderMode: RenderMode.Server,
},
];
```
-You can add this config to your application with [`provideServerRendering`](api/ssr/provideServerRendering 'API reference') using the [`withRoutes`](api/ssr/withRoutes 'API reference') function:
+Puedes añadir esta configuración a tu aplicación con [`provideServerRendering`](api/ssr/provideServerRendering 'API reference') usando la función [`withRoutes`](api/ssr/withRoutes 'API reference'):
```typescript
import { provideServerRendering, withRoutes } from '@angular/ssr';
@@ -62,12 +62,12 @@ import { serverRoutes } from './app.routes.server';
const serverConfig: ApplicationConfig = {
providers: [
provideServerRendering(withRoutes(serverRoutes)),
- // ... other providers ...
+ // ... otros proveedores ...
]
};
```
-When using the [App shell pattern](ecosystem/service-workers/app-shell), you must specify the component to be used as the app shell for client-side rendered routes. To do this, use the [`withAppShell`](api/ssr/withAppShell 'API reference') feature:
+Cuando se usa el [patrón App shell](ecosystem/service-workers/app-shell), debes especificar el componente que se usará como app shell para las rutas renderizadas del lado del cliente. Para hacerlo, usa la característica [`withAppShell`](api/ssr/withAppShell 'API reference'):
```typescript
import { provideServerRendering, withRoutes, withAppShell } from '@angular/ssr';
@@ -79,66 +79,66 @@ const serverConfig: ApplicationConfig = {
withRoutes(serverRoutes),
withAppShell(AppShellComponent),
),
- // ... other providers ...
+ // ... otros proveedores ...
]
};
```
-### Rendering modes
+### Modos de renderización
-The server routing configuration lets you specify how each route in your application should render by setting a [`RenderMode`](api/ssr/RenderMode 'API reference'):
+La configuración de enrutamiento del servidor te permite especificar cómo debe renderizarse cada ruta en tu aplicación estableciendo un [`RenderMode`](api/ssr/RenderMode 'API reference'):
-| Rendering mode | Description |
-| ------------------- | ----------------------------------------------------------------------------------------------------------- |
-| **Server (SSR)** | Renders the application on the server for each request, sending a fully populated HTML page to the browser. |
-| **Client (CSR)** | Renders the application in the browser. This is the default Angular behavior. |
-| **Prerender (SSG)** | Prerenders the application at build time, generating static HTML files for each route. |
+| Modo de renderización | Descripción |
+| --------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+| **Server (SSR)** | Renderiza la aplicación en el servidor para cada petición, enviando una página HTML completamente poblada al navegador. |
+| **Client (CSR)** | Renderiza la aplicación en el navegador. Este es el comportamiento predeterminado en Angular. |
+| **Prerender (SSG)** | Pre-renderiza la aplicación en tiempo de compilación, generando archivos HTML estáticos para cada ruta. |
-#### Choosing a rendering mode
+#### Eligiendo un modo de renderización
-Each rendering mode has different benefits and drawbacks. You can choose rendering modes based on the specific needs of your application.
+Cada modo de renderización tiene diferentes beneficios e inconvenientes. Puedes elegir modos de renderización según las necesidades específicas de tu aplicación.
-##### Client-side rendering (CSR)
+##### Renderización del lado del cliente (CSR)
-Client-side rendering has the simplest development model, as you can write code that assumes it always runs in a web browser. This lets you use a wide range of client-side libraries that also assume they run in a browser.
+La renderización del lado del cliente tiene el modelo de desarrollo más sencillo, ya que puedes escribir código asumiendo que siempre se ejecuta en un navegador web. Esto te permite usar una amplia variedad de bibliotecas del lado del cliente que también asumen que se ejecutan en un navegador.
-Client-side rendering generally has worse performance than other rendering modes, as it must download, parse, and execute your page's JavaScript before the user can see any rendered content. If your page fetches more data from the server as it renders, users also have to wait for those additional requests before they can view the complete content.
+La renderización del lado del cliente generalmente tiene peor rendimiento que otros modos de renderización, ya que debe descargar, parsear y ejecutar el JavaScript de tu página antes de que el usuario pueda ver cualquier contenido renderizado. Si tu página obtiene más datos del servidor mientras se renderiza, los usuarios también deben esperar esas peticiones adicionales antes de poder ver el contenido completo.
-If your page is indexed by search crawlers, client-side rendering may negatively affect search engine optimization (SEO), as search crawlers have limits to how much JavaScript they execute when indexing a page.
+Si tu página es indexada por rastreadores de búsqueda, la renderización del lado del cliente puede afectar negativamente la optimización para motores de búsqueda (SEO), ya que los rastreadores tienen límites en la cantidad de JavaScript que ejecutan al indexar una página.
-When client-side rendering, the server does not need to do any work to render a page beyond serving static JavaScript assets. You may consider this factor if server cost is a concern.
+Cuando se usa renderización del lado del cliente, el servidor no necesita hacer ningún trabajo para renderizar una página más allá de servir recursos estáticos de JavaScript. Puedes considerar este factor si el costo del servidor es una preocupación.
-Applications that support installable, offline experiences with [service workers](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) can rely on client-side rendering without needing to communicate with a server.
+Las aplicaciones que admiten experiencias instalables y sin conexión con [service workers](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) pueden depender de la renderización del lado del cliente sin necesidad de comunicarse con un servidor.
-##### Server-side rendering (SSR)
+##### Renderización del lado del servidor (SSR)
-Server-side rendering offers faster page loads than client-side rendering. Instead of waiting for JavaScript to download and run, the server directly renders an HTML document upon receiving a request from the browser. The user experiences only the latency necessary for the server to fetch data and render the requested page. This mode also eliminates the need for additional network requests from the browser, as your code can fetch data during rendering on the server.
+La renderización del lado del servidor ofrece cargas de página más rápidas que la renderización del lado del cliente. En lugar de esperar a que JavaScript se descargue y ejecute, el servidor renderiza directamente un documento HTML al recibir una petición del navegador. El usuario experimenta únicamente la latencia necesaria para que el servidor obtenga datos y renderice la página solicitada. Este modo también elimina la necesidad de peticiones de red adicionales desde el navegador, ya que tu código puede obtener datos durante la renderización en el servidor.
-Server-side rendering generally has excellent search engine optimization (SEO), as search crawlers receive a fully rendered HTML document.
+La renderización del lado del servidor generalmente tiene una excelente optimización para motores de búsqueda (SEO), ya que los rastreadores de búsqueda reciben un documento HTML completamente renderizado.
-Server-side rendering requires you to author code that does not strictly depend on browser APIs and limits your selection of JavaScript libraries that assume they run in a browser.
+La renderización del lado del servidor requiere que escribas código que no dependa estrictamente de las APIs del navegador y limita tu selección de bibliotecas JavaScript que asumen que se ejecutan en un navegador.
-When server-side rendering, your server runs Angular to produce an HTML response for every request which may increase server hosting costs.
+Cuando se usa renderización del lado del servidor, tu servidor ejecuta Angular para producir una respuesta HTML por cada petición, lo que puede aumentar los costos de alojamiento del servidor.
-##### Build-time prerendering
+##### Pre-renderizado en tiempo de compilación
-Prerendering offers faster page loads than both client-side rendering and server-side rendering. Because prerendering creates HTML documents at _build-time_, the server can directly respond to requests with the static HTML document without any additional work.
+El pre-renderizado ofrece cargas de página más rápidas que tanto la renderización del lado del cliente como la renderización del lado del servidor. Debido a que el pre-renderizado crea documentos HTML en _tiempo de compilación_, el servidor puede responder directamente a las peticiones con el documento HTML estático sin ningún trabajo adicional.
-Prerendering requires that all information necessary to render a page is available at _build-time_. This means that prerendered pages cannot include any data to the specific user loading the page. Prerendering is primarily useful for pages that are the same for all users of your application.
+El pre-renderizado requiere que toda la información necesaria para renderizar una página esté disponible en _tiempo de compilación_. Esto significa que las páginas pre-renderizadas no pueden incluir datos específicos del usuario que está cargando la página. El pre-renderizado es principalmente útil para páginas que son iguales para todos los usuarios de tu aplicación.
-Because prerendering occurs at build-time, it may add significant time to your production builds. Using [`getPrerenderParams`](api/ssr/ServerRoutePrerenderWithParams#getPrerenderParams 'API reference') to produce a large number of HTML documents may affect the total file size of your deployments, and thus lead to slower deployments.
+Debido a que el pre-renderizado ocurre en tiempo de compilación, puede añadir un tiempo significativo a tus compilaciones de producción. Usar [`getPrerenderParams`](api/ssr/ServerRoutePrerenderWithParams#getPrerenderParams 'API reference') para producir una gran cantidad de documentos HTML puede afectar el tamaño total de archivos de tus despliegues y, por lo tanto, provocar despliegues más lentos.
-Prerendering generally has excellent search engine optimization (SEO), as search crawlers receive a fully rendered HTML document.
+El pre-renderizado generalmente tiene una excelente optimización para motores de búsqueda (SEO), ya que los rastreadores de búsqueda reciben un documento HTML completamente renderizado.
-Prerendering requires you to author code that does not strictly depend on browser APIs and limits your selection of JavaScript libraries that assume they run in a browser.
+El pre-renderizado requiere que escribas código que no dependa estrictamente de las APIs del navegador y limita tu selección de bibliotecas JavaScript que asumen que se ejecutan en un navegador.
-Prerendering incurs extremely little overhead per server request, as your server responds with static HTML documents. Static files are also easily cached by Content Delivery Networks (CDNs), browsers, and intermediate caching layers for even faster subsequent page loads. Fully static sites can also be deployed solely through a CDN or static file server, eliminating the need to maintain a custom server runtime for your application. This enhances scalability by offloading work from an application web server, making it particularly beneficial for high-traffic applications.
+El pre-renderizado incurre en una sobrecarga mínima por petición al servidor, ya que tu servidor responde con documentos HTML estáticos. Los archivos estáticos también se pueden almacenar en caché fácilmente mediante redes de distribución de contenido (CDN), navegadores y capas intermedias de caché para cargas de página subsiguientes aún más rápidas. Los sitios completamente estáticos también pueden desplegarse únicamente a través de una CDN o un servidor de archivos estáticos, eliminando la necesidad de mantener un tiempo de ejecución de servidor personalizado para tu aplicación. Esto mejora la escalabilidad al descargar trabajo de un servidor web de aplicaciones, lo que lo hace especialmente beneficioso para aplicaciones de alto tráfico.
-NOTE: When using Angular service worker, the first request is server-rendered, but all subsequent requests are handled by the service worker and rendered client-side.
+NOTA: Cuando se usa el service worker de Angular, la primera petición se renderiza en el servidor, pero todas las peticiones subsiguientes son gestionadas por el service worker y renderizadas del lado del cliente.
-### Setting headers and status codes
+### Configurando encabezados y códigos de estado
-You can set custom headers and status codes for individual server routes using the `headers` and `status` properties in the `ServerRoute` configuration.
+Puedes establecer encabezados y códigos de estado personalizados para rutas individuales del servidor usando las propiedades `headers` y `status` en la configuración de `ServerRoute`.
```typescript
// app.routes.server.ts
@@ -153,33 +153,33 @@ export const serverRoutes: ServerRoute[] = [
},
status: 201,
},
- // ... other routes
+ // ... otras rutas
];
```
-### Redirects
+### Redirecciones
-Angular handles redirects specified by the [`redirectTo`](api/router/Route#redirectTo 'API reference') property in route configurations, differently on the server-side.
+Angular maneja las redirecciones especificadas por la propiedad [`redirectTo`](api/router/Route#redirectTo 'API reference') en las configuraciones de rutas de manera diferente en el lado del servidor.
-**Server-Side Rendering (SSR)**
-Redirects are performed using standard HTTP redirects (e.g., 301, 302) within the server-side rendering process.
+**Renderización del lado del servidor (SSR)**
+Las redirecciones se realizan mediante redirecciones HTTP estándar (por ejemplo, 301, 302) dentro del proceso de renderización del lado del servidor.
-**Prerendering (SSG)**
-Redirects are implemented as "soft redirects" using [`