1 
2I flera år har en av de mest irriterande frågorna i Next.js varit: "Är den här sidan statisk eller dynamisk?". Det verkar som en enkel fråga, tills du lägger till ett anrop till `cookies()`, en `fetch` med olika alternativ, en databasklient, ett CMS, en kundvagn eller ett stycke anpassat innehåll.
3 
4Next.js 16 är intressant eftersom det försöker göra den här konversationen mindre mystisk. Det eliminerar inte komplexitet, men det förändrar den mentala modellen: rutter är dynamiska som standard, cachen deklarerar sig själv där det behövs och `Suspense` blir det naturliga sättet att komponera snabba skal med delar som håller sig fräscha.
5 
6Funktionen att förstå är Cache-komponenter. Stabil Turbopack, React Compiler, `proxy.ts` och de nya invaliderings-API:erna är viktiga, men de kretsar kring samma problem: att bygga snabba appar utan att behöva gissa vad ramverket beslutade bakom kulisserna.
7 
8## För det här spelar roll
9 
10I en riktig app har du inte bara "statiska sidor" och "dynamiska sidor". Du har olika pjäser med olika behov.
11 
12Produktbladet kan ändras några gånger om dagen. Priset kan ändras oftare. Tillgänglighet måste vara nästan live. Användarnamnet är personligt. Recensioner kan streamas. Sidofältet kan vara stabilt. Det gör inte vagnen.
13 
14Om du behandlar allt som en enhet hamnar du alltid i en av två ytterligheter:
15 
16- aggressiv cachning och risk för att se gamla data;
17- dynamisk rendering överallt och prestanda sämre än nödvändigt.
18 
19Cache-komponenter tjänar just till att undvika detta felaktiga val.
20 
21## Modellen i praktiken
22 
23Med `cacheComponents: true` kan du deklarera vad som är cachebart med `"use cache"`. Sedan kan du associera varaktighet och taggar med `cacheLife()` och `cacheTag()`. Dynamiska delar förblir dynamiska och kan isoleras med `Suspense`.
24 
25```mermaid
26flowchart TD
27    Request[Användarförfrågan] --> Shell[Cachat skal]
28    Request --> Dynamic[Dynamiska sektioner]
29    Shell --> FirstPaint[Första snabba innehållet]
30    Dynamic --> Stream[Streamar inuti Suspense]
31    Stream --> Complete[Hela sidan]
32```
33 
34Inställningen är liten:
35 
36```typescript
37// next.config.ts
38import type { NextConfig } from 'next';
39 
40const nextConfig: NextConfig = {
41  cacheComponents: true,
42};
43 
44export default nextConfig;
45```
46 
47Den stora förändringen finns inte i konfigurationen. Det är hur du börjar skriva komponenterna.
48 
49```tsx
50// app/products/[slug]/page.tsx
51import { Suspense } from 'react';
52import { cacheLife, cacheTag } from 'next/cache';
53 
54async function getProduct(slug: string) {
55  'use cache';
56 
57  cacheLife('hours');
58  cacheTag(`product:${slug}`);
59 
60  return db.product.findUnique({ where: { slug } });
61}
62 
63async function ProductDetails({ slug }: { slug: string }) {
64  const product = await getProduct(slug);
65 
66  return (
67    <section>
68      <h1>{product.name}</h1>
69      <p>{product.description}</p>
70    </section>
71  );
72}
73 
74async function LiveInventory({ slug }: { slug: string }) {
75  const inventory = await db.inventory.findFirst({ where: { slug } });
76  return <p>{inventory.quantity} pezzi disponibili</p>;
77}
78 
79export default async function ProductPage({ params }: { params: Promise<{ slug: string }> }) {
80  const { slug } = await params;
81 
82  return (
83    <>
84      <ProductDetails slug={slug} />
85      <Suspense fallback={<p>Controllo disponibilità...</p>}>
86        <LiveInventory slug={slug} />
87      </Suspense>
88    </>
89  );
90}
91```
92 
93Sidan behöver inte vara helt cachad eller helt dynamisk. Produktbladet kan vara snabbt och återanvändbart. Inventeringen kan hålla sig fräsch. Användaren ser något direkt, utan att vänta på den långsammaste delen.
94 
95## `use cache` är körbar dokumentation
96 
97Det jag gillar med `"use cache"` är att det tvingar dig att uttrycka en avsikt. När man läser en funktion förstår man direkt att någon har bestämt sig: "denna data kan återanvändas".
98 
99Det är särskilt användbart när du inte använder `fetch`. Många appar läser data från Prisma, Drizzle, interna SDK:er, CMS-klienter eller servicefunktioner. I dessa fall räckte inte det gamla resonemanget baserat på `fetch`-alternativ.
100 
101En tumregel:
102 
103- cacheinnehåll relativt stabilt;
104- använd granulära taggar;
105- lämnar dynamiska behörigheter, sessioner, vagnar, meddelanden och transaktionstillstånd;
106- lägg långsamma delar inuti `Suspense`;
107- mäta innan du säger "vi förbättrade prestandan".
108 
109## Ogiltigförklara utan att kasta allt
110 
111Cachen är bara användbar om du kan uppdatera den korrekt. Här blir `cacheTag`, `revalidateTag` och `updateTag` viktiga.
112 
113Exempel:
114 
115```typescript
116'use server';
117 
118import { updateTag } from 'next/cache';
119 
120export async function updateProductName(productId: string, name: string) {
121  await db.product.update({
122    where: { id: productId },
123    data: { name },
124  });
125 
126  updateTag(`product:${productId}`);
127}
128```
129 
130Den viktiga detaljen är taggen. `product:${productId}` visar en exakt gräns. `products` säger en stor hink. Till en början är den enorma skopan bekväm; efter några månader blir det anledningen till att du ogiltigförklarar en halv app för att ändra en titel.
131 
132## Stabil Turbopack: delen du hör varje dag
133 
134Next.js 16 tar Turbopack till centrum för utveckling och konstruktion. Det är inte det mest poetiska inslaget, men det är den du känner medan du arbetar: server som startar tidigare, snabbare uppdatering, byggen som slutar kännas som en tvångsfika.
135 
136Som sagt, jag skulle inte migrera en kodbas full av anpassade plugins med slutna ögon. Jag skulle kolla:
137 
138- lokal byggnad;
139- icke-standard import;
140- MDX, SVG och CSS;
141- Webpack plugins kvar;
142- kritiska sidor;
143- skillnader i byggtider.
144 
145För nya projekt skulle jag börja från standard. För mogna skulle jag göra en uppmätt migration.
146 
147## React Compiler: ta bort brus, inte tänkt
148 
149React Compiler 1.0 är stabil och Next.js 16 stöder den med `reactCompiler`. Löftet är att minska mycket manuell memoisering: mindre `memo`, mindre `useMemo`, mindre `useCallback` används "för säkerhets skull".
150 
151```typescript
152// next.config.ts
153import type { NextConfig } from 'next';
154 
155const nextConfig: NextConfig = {
156  reactCompiler: true,
157};
158 
159export default nextConfig;
160```
161 
162Jag skulle inte behandla det som ett magiskt damm. Kompilatorn hjälper till när koden följer React-reglerna väl. Om komponenter har konstiga biverkningar, dolda mutationer eller dåligt använda krokar, måste det åtgärdas först.
163 
164Det hälsosamma sättet att prova det:
165 
1661. uppdatera `eslint-plugin-react-hooks`;
1672. fixa faktiska överträdelser;
1683. aktivera det på ett kontrollerat område;
1694. mäta byggtid och beteende;
1705. ta bort manuell memoisering endast när den inte längre behövs.
171 
172Målet är inte att radera varje `useMemo`. Målet är att sluta skriva förebyggande memoisering eftersom vi är rädda för rendering.
173 
174## `proxy.ts` och nätverksgränsen
175 
176Den gamla `middleware.ts` blir `proxy.ts`. Det är ett namnbyte, men det är vettigt: den filen ligger vid förfrågningsgränsen, det är inte traditionell mellanprogramvara i backend-stil.
177 
178```typescript
179// proxy.ts
180import { NextRequest, NextResponse } from 'next/server';
181 
182export default function proxy(request: NextRequest) {
183  const isLoggedIn = Boolean(request.cookies.get('session'));
184 
185  if (!isLoggedIn && request.nextUrl.pathname.startsWith('/dashboard')) {
186    return NextResponse.redirect(new URL('/login', request.url));
187  }
188 
189  return NextResponse.next();
190}
191```
192 
193Regeln här är enkel: håll den liten. Omdirigering, autentiseringsdirigering, rubriker, viktiga omskrivningar. Om det börjar kännas som en andra backend, gör det förmodligen för mycket.
194 
195## Hur jag verkligen skulle migrera
196 
197Jag skulle inte slå på alla funktioner på en gång. Jag skulle göra så här:
198 
1991. Jag uppdaterar Next, React och React DOM;
2002. Jag startar den officiella codemoden;
2013. Jag fixar brytande ändringar på `params`, `searchParams`, `cookies()`, `headers()` och `draftMode()`;
2024. Jag migrerar `middleware.ts` till `proxy.ts`;
2035. Jag kollar builds och kritiska sidor;
2046. Jag aktiverar Cache-komponenter på en sektion där cachen för närvarande skapar friktion;
2057. Jag definierar konventioner för taggar och ogiltigförklaring;
2068. Jag försöker React Compiler separat;
2079. jämförelse av mätvärden före och efter.
208 
209Den goda migrationen är inte den som använder alla nya funktioner. Det är det som gör appens beteende mer läsbart.
210 
211## Vad förändras i sättet att tänka
212 
213Det mest användbara med Next.js 16 är att det tvingar dig att namnge avsikter bättre. En funktion är inte bara "hämta produkten från databasen". Det är "skaffa produkten, jag kan cache den i timmar, jag ogiltigförklarar den med den här taggen". En komponent är inte bara "rendera sidan". Det är "det här är det snabba skalet, det här stycket är personligt, det här kommer strömmande."
214 
215Till en början verkar det som mer jobb. Då blir det en form av lugn. Prestandabeslut är inte längre dolda i en kombination av standardinställningar, heuristik och stamminne. De finns i koden.
216 
217## Användbara källor
218 
219- [Next.js 16 release notes](https://nextjs.org/blog/next-16)
220- [Cachekomponenter - Next.js docs](https://nextjs.org/docs/app/getting-started/cache-components)
221- [använd cache - Next.js docs](https://nextjs.org/docs/app/api-reference/directives/use-cache)
222- [React Compiler v1.0](https://react.dev/blog/2025/10/07/react-compiler-1)
223