import { cache } from 'react';
import { Metadata } from 'next';
// Cache-uim apelul ca să evitam interogările duble în DB
const getProduct = cache(async (id: string) => {
// Înlocuiește cu apelul tău real de DB sau API
return { id, title: "Laptop Gaming ultra-portabil", desc: "Specificații de top" };
});
export async function generateMetadata({ params }: { params: { id: string } }): Promise<Metadata> {
const product = await getProduct(params.id);
return {
title: product.title,
description: product.desc,
openGraph: {
images: [`/api/og?title=${encodeURIComponent(product.title)}`],
},
};
}
export default async function Page({ params }: { params: { id: string } }) {
const product = await getProduct(params.id);
const jsonLd = {
"@context": "https://schema.org",
"@type": "Product",
"name": product.title,
"description": product.desc,
};
return (
<main>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
/>
<h1>{product.title}</h1>
<p>{product.desc}</p>
</main>
);
}Am trecut recent un proiect destul de măricel, un e-commerce cu vreo 15.000 de produse, pe ultimele versiuni de Next.js. M-am lovit direct de bubele Metadata API-ului când încerci să faci SEO dinamic ca la carte. Dacă nu ești atent, API-ul ăsta îți poate îngenunchea baza de date sau îți poate dubla timpul de build în producție.
Capcana fetch-urilor duble în generateMetadata
Cea mai mare greșeală pe care o văd frecvent este că se face un fetch în generateMetadata și încă unul, complet identic, în componenta paginii. Next.js zice că face deduplicare automată prin fetch()-ul nativ pe care l-au extins ei. Sună bine pe hârtie, nu?
În realitate, dacă folosești un ORM ca Prisma sau un client de baze de date precum Postgres.js direct în Server Components, deduplicarea aia nativă nu funcționează de la sine fiindcă nu trece prin API-ul de fetch. Am pățit asta pe pielea mea: numărul de interogări către baza de date s-a dublat instant în staging. Soluția este extrem de simplă dar des ignorată: folosește funcția cache din React pentru a memora rezultatul interogării pe durata aceluiași request. Am economisit cam 30% din timpul de răspuns al serverului doar cu acest mic artificiu.
Cum generăm imagini Open Graph dinamice
Pentru imagini OG dinamice, Next.js are suport excelent prin ImageResponse importat din next/og. Totuși, există un trade-off major aici de care trebuie să fii conștient.
Generarea de imagini pe server folosind Satori (motorul din spate) consumă destul de multe resurse de CPU. La proiectul de care ziceam, am decis să nu generăm imagini complet dinamice la absolut fiecare request pentru toate cele 15k produse. În schimb, am făcut o rută separată /api/og care generează imaginea și am pus-o în spatele unui CDN (Cloudflare) cu reguli agresive de cache. Dacă nu faci asta, la primul val de boți de la Facebook sau LinkedIn care îți scanează site-ul, serverul tău o să transpire serios și riști să ai timpi mari de încărcare.
JSON-LD nu are ce căuta în obiectul de Metadata
O altă confuzie frecventă este încercarea de a introduce datele structurate direct în obiectul returnat de generateMetadata. API-ul de metadata din Next.js este gândit exclusiv pentru tagurile standard din <head> (meta, link, title).
Pentru JSON-LD, cel mai curat mod este să injectezi un tag <script> direct în componenta paginii tale. React elimină automat duplicatele și se asigură că scriptul ajunge unde trebuie în documentul final. În plus, codul devine mult mai lizibil și mai ușor de întreținut. Nu te complica să pasezi obiecte gigantice prin metadata când poți pur și simplu să randezi un script inline în server component.
Voi cum gestionați randarea imaginilor OG la proiectele mari? Mergeți pe generare on-the-fly sau le pre-generați la build?