docs: add route rules to concepts > rendering (#8292)

Co-authored-by: Daniel Roe <daniel@roe.dev>

docs/content/2.guide/1.concepts/3.rendering.md

@@ -69,14 +69,46 @@ In most cases, universal rendering as performed in Nuxt 2 offers a good user and
 
 ### Hybrid Rendering
 
-Hybrid rendering allows different caching rules per route and decides how the Server should respond to a new request on a given URL.
-
-At the moment, every page (or **route**) of a Nuxt application must use the same rendering mode, client-side or universal. But in various cases, some pages could be generated at build time, while others should be client-side rendered. For example, think of a content website with an admin section. Every content page should be primarily static and generated once, but the admin section requires registration and behaves more like a dynamic application.
-
-[Read the open RFC discussing implementation and gathering community feedback.](https://github.com/nuxt/framework/discussions/560)
+Hybrid rendering allows different caching rules per route using **Route Rules** and decides how the Server should respond to a new request on a given URL.
 
 ### Rendering on CDN Edge Workers
 
 Traditionally, server-side and universal rendering was only possible using Node.js. Nuxt 3 takes it to another level by directly rendering code in CDN edge workers, reducing latency and costs.
 
 Nitro is the new [server engine](/guide/concepts/server-engine) that powers Nuxt 3. It offers cross-platform support for Node.js, Deno, Workers, and more. Nitro's design is platform-agnostic and allows rendering a Nuxt application at the edge, closer to your users, allowing replication and further optimizations.
+
+### Route Rules
+
+> 🧪 Route rules are still under active development, and subject to change.
+
+Previously every route/page of a Nuxt application and server must use the same rendering mode, client-side or universal. But in various cases, some pages could be generated at build time, while others should be client-side rendered. For example, think of a content website with an admin section. Every content page should be primarily static and generated once, but the admin section requires registration and behaves more like a dynamic application.
+
+Nuxt 3 starting from rc.12 comes with the public beta for route rules and hybrid rendering support. Using route rules you can define rules for a group of nuxt routes, change rendering mode or assign a cache strategy based on route! Nuxt server will automatically register corresponding middleware and wrap routes with cache handlers using [nitro caching layer](https://nitro.unjs.io/guide/introduction/cache). Whenever possible, route rules will be automatically applied to the deployment platform's native rules (currently Netlify and Vercel are supported).
+
+- `redirect` - Define server-side redirects.
+- `ssr` - Disables server-side rendering for sections of your app and make them SPA-only with `ssr: false`
+- `cors` - Automatically adds cors headers with `cors: true` - you can customize the output by overriding with `headers`
+- `headers` - Add specific headers to sections of your site - for example, your assets
+- `static` and `swr` - `static` enables a single (on-demand) build; `swr` enables a static build, that lasts for a configurable TTL. (currently enables full incremental static generation on Netlify, with Vercel coming soon)
+
+**Examples:**
+
+```ts
+export default defineNuxtConfig({
+  routeRules: {
+    // Static page generated on-demand, revalidates in background
+    '/blog/**': { swr: true },
+    // Static page generated on-demand once
+    '/articles/**': { static: true },
+    // Set custom headers matching paths
+    '/_nuxt/**': { headers: { 'cache-control': 's-maxage=0' } },
+    // Render these routes with SPA
+    '/admin/**': { ssr: false },
+    // Add cors headers
+    '/api/v1/**': { cors: true },
+    // Add redirect headers
+    '/old-page': { redirect: '/new-page' },
+    '/old-page2': { redirect: { to: '/new-page', statusCode: 302 } }
+  }
+})
+```