Un glosario de trabajo de los términos que aparecen en cada RFP, brief y conversación de arquitectura componible.
API-first es un enfoque de diseño donde el contrato de la API se define antes que cualquier código de backend o frontend, tratando la API misma como el producto principal. Produce endpoints consistentes, versionado predecible y plataformas que integran limpiamente con cualquier canal que venga, sea web, app iOS o un agente de IA. La disciplina importa más en stacks componibles porque la API es el tejido conector entre cada servicio best-of-breed.
Un asset es contenido binario almacenado en un CMS o DAM, incluyendo imágenes, videos, PDFs, audio y archivos de marca como tipografías y logos. Una plataforma DAM como Bynder es el sistema de registro de assets a escala empresarial, mientras que un CMS como Contentful suele guardar un subconjunto operativo para los canales que sirve. Los flujos de asset cubren ingesta, etiquetado de metadatos, gestión de derechos, generación de derivados (miniaturas, formatos) y la URL de entrega que consumen los servicios downstream.
AEO (Optimización para Motores de Respuesta) es la disciplina de estructurar contenido para que motores de respuesta con IA como Perplexity, ChatGPT Search y Google AI Overviews puedan citarlo directamente. Las técnicas principales incluyen encabezados en forma de pregunta, párrafos con respuesta al inicio, listas extraíbles, secciones de FAQ con schema FAQPage e higiene de citación (autoría, fechas, fuentes primarias). AEO es un superset del SEO clásico que asume que el lector es a menudo un LLM componiendo una respuesta, lo que cambia los patrones de escritura que ganan.
La accesibilidad (a menudo abreviada a11y) es la disciplina de diseño e ingeniería de construir experiencias digitales que personas con discapacidad puedan usar, incluyendo discapacidades visuales, auditivas, motoras y cognitivas. La accesibilidad cubre navegación por teclado, soporte de lectores de pantalla, contraste de color, gestión de foco, subtitulado, HTML semántico y atributos ARIA para widgets personalizados. Para marcas empresariales, la accesibilidad es también una obligación legal en muchas jurisdicciones (ADA en EE. UU., EAA en la UE) y un factor claro de confianza de marca.
ARIA (Accessible Rich Internet Applications) es una especificación del W3C que aporta semántica extra para widgets de UI personalizados como menús, tabs y diálogos, para que las tecnologías asistivas los interpreten correctamente. ARIA define roles (qué es un elemento), estados (qué está haciendo) y propiedades (sus capacidades), que las tecnologías asistivas (lectores de pantalla, switch devices) usan para describir la página al usuario. La primera regla de ARIA es evitar ARIA cuando sea posible: los elementos nativos de HTML (button, dialog, details) ya traen la semántica correcta, y ARIA es el fallback para widgets personalizados que HTML no provee.
Una SPA (Aplicación de una sola página) es una aplicación web que carga el shell una sola vez y actualiza la URL y la vista con JavaScript del lado del cliente, sin recargar la página completa al navegar. Las SPAs se sienten fluidas porque la navegación es instantánea después de la carga inicial, pero pagan un costo en primer pintado más lento, SEO más complejo y el riesgo constante de estado huérfano entre vistas. La mayoría de aplicaciones Next.js modernas son técnicamente híbridas SPA-MPA: el primer render es HTML del servidor y las navegaciones siguientes ocurren en el cliente con datos de ruta prefetcheados.
Una MPA (Aplicación multipágina) es una arquitectura web donde cada navegación dispara una solicitud HTTP real y una página fresca renderizada en el servidor, el enfoque por defecto para sitios de marketing y la mayoría de contenido CMS. Las MPAs ganan en performance de carga inicial, SEO, defaults de accesibilidad y comportamiento nativo del botón atrás, al costo de sentirse un poco menos "app" en la navegación interna. La mayoría de sitios componibles empresariales usan arquitectura estilo MPA con view transitions, así cada página es rápida e indexable mientras la navegación sigue sintiéndose fluida.
La arquitectura componible es un patrón de software que ensambla una plataforma de negocio a partir de servicios independientes API-first en lugar de un único stack de un solo proveedor. Los equipos eligen un producto best-of-breed para cada capacidad (CMS, DAM, búsqueda, entrega, mensajería) y los conectan con APIs documentadas y un modelo de contenido compartido. El trade-off es más trabajo de integración al inicio, a cambio de poder reemplazar cualquier servicio después sin reconstruir toda la plataforma.
Cloud-native es un patrón de diseño donde el software se construye específicamente para servicios de nube gestionados como contenedores, funciones serverless y runtimes edge, en vez de adaptarse a ellos. Asume escalado elástico, cómputo efímero e infraestructura gestionada como defaults, lo que elimina la mayor parte de la planeación de capacidad que requerían las plataformas on-premise. La mayoría de plataformas componibles modernas (Vercel, Netlify, AWS Lambda, Cloudflare Workers) son cloud-native por diseño.
Un CDN (Red de Distribución de Contenido) es una red distribuida de servidores que cachea contenido estático en puntos de presencia alrededor del mundo, así los usuarios se conectan a un servidor cercano en vez de a un origen lejano. Los CDNs reducen la latencia de carga, absorben picos de tráfico, terminan TLS eficientemente y añaden una capa de protección DDoS en el borde de la red. En plataformas componibles, el CDN normalmente hospeda la salida prerenderizada del frontend (Vercel, Cloudflare, Akamai), con el CMS headless y otros servicios sentados detrás del cache como orígenes.
Un CMS (Sistema de Gestión de Contenido) es la plataforma de software donde los equipos editoriales escriben, organizan y publican contenido, y donde vive el modelo de datos. Los CMS tradicionales como AEM y Sitecore acoplan autoría con renderizado en un solo stack, mientras que los CMS headless como Contentful y Sanity exponen contenido como API y dejan el renderizado a un frontend separado. Para los equipos empresariales que avanzan hacia arquitectura componible, el CMS suele ser la primera plataforma a reemplazar, porque controla el modelo de contenido que leen todos los canales downstream.
Cache Components es un primitivo de Next.js 16 que cachea la salida de un Server Component con tags y tiempos de vida explícitos, reemplazando el cacheo implícito basado en fetch de versiones anteriores. Los desarrolladores declaran de qué datos depende un componente, qué tags identifican esos datos y cuánto tiempo vale la salida renderizada, lo que le da al framework la información necesaria para invalidar con precisión al actualizar contenido. El cambio hace explícito el comportamiento de cache en vez de inferido, lo que resuelve el bug de performance más común en Next.js: envenenamiento de cache por Server Components accidentalmente dinámicos.
Core Web Vitals son las métricas estandarizadas de salud de experiencia de usuario de Google, actualmente Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). Cada métrica tiene un umbral "bueno" (LCP bajo 2.5 segundos, INP bajo 200 milisegundos, CLS bajo 0.1) que las páginas deben cumplir en el 75 por ciento de las sesiones reales para que Google las cuente como aprobadas. Core Web Vitals son una señal de ranking confirmada y un proxy fuerte de calidad percibida, y por eso aparecen en casi todo brief de modernización.
CLS (Cumulative Layout Shift) es la métrica de Core Web Vitals que mide cambios inesperados de layout en una página durante su vida, sumados como un score sin unidades. Google considera bueno un CLS bajo 0.1, 0.1 a 0.25 necesita mejora, y arriba de 0.25 es pobre. La mayoría de problemas de CLS vienen de imágenes sin dimensiones explícitas, anuncios o embeds que cargan tarde, y tipografías web que cambian al descargar, todos con arreglos bien conocidos.
Un cache hit es una solicitud que encuentra una entrada fresca en el caché y se sirve directo desde el caché, sin contactar al servidor de origen. Los cache hits son esencialmente gratis en términos de cómputo, a menudo bajo 30 milisegundos de extremo a extremo, y por eso un cache hit ratio alto es un objetivo central de optimización en cualquier frontend componible. La mayoría de los equipos apunta a un hit ratio arriba del 90 por ciento en sitios de marketing con mucho contenido, donde los misses los dominan las actualizaciones editoriales y los backfills de stale-while-revalidate.
Un cache miss es una solicitud que no encuentra una entrada fresca en el caché y se reenvía al servidor de origen, que construye y devuelve una respuesta que el CDN entonces cachea para solicitudes futuras. Los cache misses son más lentos que los hits (el round-trip al origen más el tiempo de cómputo) y más caros de servir, y por eso un caché mal configurado siempre aparece primero como un problema de latencia o de costo. La mayoría de arquitecturas componibles empresariales usa stale-while-revalidate para mantener los misses fuera del camino crítico, sirviendo contenido viejo rápido mientras el caché se refresca en segundo plano.
CSRF (Cross-Site Request Forgery) es una vulnerabilidad donde un sitio malicioso engaña al navegador de un usuario autenticado para enviar una solicitud a otro sitio (al banco del usuario, por ejemplo) en nombre del usuario. La defensa estándar es un token CSRF: un valor único que el servidor emite por sesión y que el cliente debe incluir en cualquier solicitud que cambie estado, y que un sitio externo no puede leer ni falsificar. En Next.js, la protección CSRF está integrada en los Server Actions, pero las API routes personalizadas y los form posts tradicionales requieren emisión y verificación explícita de token.
CSP (Content Security Policy) es un header de respuesta HTTP que le dice al navegador qué orígenes de scripts, estilos, imágenes, tipografías y otros recursos pueden cargarse en una página. Un CSP bien configurado bloquea la mayoría de los ataques XSS, evita exfiltración de datos por scripts inline y limita lo que una librería de terceros comprometida puede hacer. Los CSPs son notoriamente difíciles de desplegar sin romper analytics, píxeles publicitarios y widgets de terceros, por eso los equipos los despliegan primero en modo report-only para capturar violaciones antes de aplicar.
La consistencia eventual es una propiedad de distribución de datos donde una escritura se propaga a todas las réplicas eventualmente, pero las lecturas en el intervalo entre la escritura y la propagación completa pueden devolver valores viejos. Los CDNs, las bases de datos replicadas y el DNS se comportan con consistencia eventual, con ventanas de propagación que van de milisegundos a minutos según el sistema. La consistencia eventual es el trade-off correcto para sistemas con mucho contenido porque escala más barato que la consistencia fuerte, siempre que la aplicación muestre la antigüedad de forma apropiada con timestamps de "última actualización" o UI optimista.
Una plataforma DAM (Gestión de Activos Digitales) es el sistema de registro para imágenes, videos, archivos de marca y metadatos de derechos de una organización. Bynder, Cloudinary y Aprimo son opciones DAM comunes en empresas, con flujos para ingesta, etiquetado, aprobación, generación de derivados y entrega a CMS, ecommerce y plataformas de marketing downstream. Un DAM es donde se crean los metadatos listos para IA, porque el modelo de contenido decide qué pueden hacer realmente las herramientas downstream con cada asset.
La detección de bots es la disciplina de distinguir a usuarios humanos y submitters de formularios de scripts automáticos y crawlers, sin obligar al humano a resolver un CAPTCHA. Las herramientas modernas (Vercel BotID, Cloudflare Turnstile, Google reCAPTCHA v3, hCaptcha) puntúan cada solicitud según huella del navegador, señales de comportamiento y reputación de red. La detección de bots corre invisible para usuarios genuinos, retando solo las solicitudes que el sistema marca como sospechosas, lo que mantiene altas las tasas de completado de formulario mientras bloquea la mayoría de los envíos automáticos.
Una entrada es una instancia de un tipo de contenido en un CMS headless, como un evento específico, un artículo o un perfil de ponente. Los editores crean, editan y publican entradas desde la interfaz de autoría del CMS, y cada entrada se expone a través de la API de entrega de contenido para que el frontend la renderice. En Contentful, una entrada tiene un ID estable que el frontend usa para traerla, y un historial de versiones que la plataforma guarda para rollback y auditoría.
Edge computing es el patrón de correr código de servidor en puntos de presencia cercanos al usuario, típicamente dentro de la red global de un CDN, en vez de en un solo centro de datos central. Vercel Edge Functions, Cloudflare Workers y Fastly Compute@Edge son los runtimes edge más comunes, cada uno corriendo un V8 isolate ligero con cold starts por debajo del milisegundo. Edge computing es el lugar correcto para manejar requests de baja latencia como chequeos de autenticación, decisiones de personalización, asignación de A/B y reescritura de requests, pero no para cómputo pesado u operaciones con estado.
Una función edge es código de servidor que corre dentro de un punto de presencia (POP) de CDN físicamente cercano al usuario, en vez de en una sola región de centro de datos central. Vercel Edge Functions, Cloudflare Workers y Netlify Edge Functions corren un V8 isolate ligero que arranca en menos de un milisegundo y maneja solicitudes con cold starts por debajo de 50 ms. Las funciones edge son el lugar correcto para chequeos de autenticación, reglas de personalización, ramificación de pruebas A/B y reescritura de requests, pero no para cómputo pesado ni queries largas a base de datos.
Un feature flag es un interruptor en tiempo de ejecución dentro del código que prende o apaga una ruta específica sin redesplegar la aplicación, controlado a través de un servicio de configuración. Los flags se usan para condicionar acceso a features nuevas (sacándolas a un porcentaje de usuarios), para hacer kill-switch a código roto en producción y para coordinar releases entre marketing e ingeniería. LaunchDarkly, Statsig y Vercel Edge Config son plataformas comunes de flags, todas evalúan el flag en tiempo de request para que los cambios surtan efecto sin desplegar código.
Una firma de webhook es un hash criptográfico (usualmente HMAC-SHA256) que el emisor calcula a partir del payload y un secreto compartido, e incluye en un header HTTP para que el receptor verifique la autenticidad. El receptor calcula el mismo hash sobre el payload entrante y lo compara contra el valor del header, rechazando la solicitud si los hashes no coinciden en tiempo constante. Todo endpoint de webhook público debe verificar firmas, porque el endpoint es accesible públicamente y un handler sin autenticación es un vector trivial de denegación de servicio o inyección de datos.
GEO (Optimización para Motores Generativos) es Answer Engine Optimization aplicado específicamente a motores generativos de IA, incluyendo ChatGPT, Claude, Perplexity, Google AI Overviews y Microsoft Copilot. Los patrones son los mismos que AEO (párrafos con respuesta al inicio, datos estructurados, higiene de citación) con énfasis extra en contenido extraíble, densidad de entidades nombradas y señales de confianza de fuente primaria. Para marcas B2B, GEO determina si tu plataforma aparece como fuente citada cuando los compradores le preguntan a una IA sobre tu categoría, que es cada vez más donde empieza la investigación de decisión.
Un CMS headless es un sistema de gestión de contenido que expone su contenido como JSON o GraphQL y deja el renderizado a un frontend separado. La capa de presentación se desacopla del almacenamiento y del flujo editorial, así el mismo contenido alimenta web, móvil, kiosco, voz y superficies de IA desde una sola fuente. Contentful, Sanity y Storyblok son opciones headless comunes para equipos empresariales que dejan plataformas legadas como AEM o Sitecore.
HMAC (Hash-based Message Authentication Code) es un algoritmo criptográfico que combina una función hash (típicamente SHA-256) con un secreto compartido para producir una firma de longitud fija para un trozo de datos. La firma prueba dos cosas: que los datos no fueron modificados en tránsito y que el emisor conocía el secreto compartido, lo que juntas dan integridad y autenticación. HMAC es el algoritmo detrás de casi cualquier esquema de firma de webhook (Stripe, Contentful, GitHub, Slack), detrás del firmado JWT HS256, y detrás de muchos patrones de autenticación servicio-a-servicio internos.
Un honeypot es un campo de formulario oculto que es invisible para humanos (posicionado fuera de pantalla con CSS u oculto por tabindex) pero visible para form-fillers automáticos en el HTML. Cuando llega un envío con el campo honeypot lleno, el servidor lo rechaza sin explicación, asumiendo que ningún humano pudo haber escrito ahí. Los honeypots son la defensa antispam más barata y accesible para formularios de bajo riesgo, capturando solitos entre el 80 y el 95 por ciento de envíos automáticos.
ISR (Regeneración Estática Incremental) es un patrón de renderizado de Next.js donde una página se construye una vez como HTML estático, se sirve desde un CDN y se reconstruye en segundo plano cuando sus datos cambian. Un intervalo de revalidación o una llamada a revalidate bajo demanda, típicamente disparada desde un webhook del CMS, dispara la reconstrucción, y la próxima solicitud ve la página fresca. ISR es la opción por defecto para sitios de marketing con mucho contenido porque combina velocidad de CDN estático con frescura editorial, sin el costo de renderizar cada request en el servidor.
INP (Interaction to Next Paint) es la métrica de Core Web Vitals que mide qué tan rápido responde una página a interacciones del usuario como clics, taps y teclas, tomando la interacción peor (o casi peor) a lo largo de la visita. Google considera bueno un INP bajo 200 milisegundos, 200 a 500 milisegundos necesita mejora, y arriba de 500 milisegundos es pobre. INP reemplazó a First Input Delay (FID) como Core Web Vital en marzo de 2024, porque INP captura responsividad sostenida en vez de solo la reacción inicial.
La idempotencia es la propiedad de una operación que produce el mismo estado final sin importar cuántas veces se invoque con las mismas entradas. GET, PUT y DELETE son idempotentes por convención HTTP, mientras que POST no, y se usan idempotency keys para hacer seguros los reintentos de POST ante fallos de red. La idempotencia importa más en la capa de integración de plataformas componibles, donde los reintentos de webhook y el reproceso de eventos son comunes y una operación debe poder correr dos veces sin duplicar su efecto.
JAMstack es un patrón arquitectónico de 2015 que combinó JavaScript en el frontend, APIs para datos dinámicos y markup estático prerenderizado en build time, servido desde un CDN. El acrónimo (JavaScript, APIs, Markup), acuñado por Netlify, enmarcó una generación de generadores estáticos como Gatsby, Hugo y los primeros Next.js, antes de que los runtimes serverless y edge hicieran la arquitectura más dinámica. La mayoría de los equipos hoy usa la palabra "componible" en su lugar, porque los supuestos sobre prerenderizado estático ya no describen completamente cómo funciona un frontend moderno.
JSON-LD (JavaScript Object Notation for Linked Data) es una sintaxis JSON para incrustar datos estructurados de Schema.org dentro de una página, típicamente como un script tag en el head. Es el formato recomendado por Google y la mayoría de motores de IA porque vive junto al HTML sin afectar el layout visible, y anida referencias de entidad y propiedades limpiamente. En Next.js, JSON-LD se renderiza típicamente como un script tag en el layout, con los datos estructurados compuestos a partir de los mismos campos de contenido que usa la propia página.
Un JWT (JSON Web Token) es un objeto JSON firmado que lleva aserciones sobre un sujeto (típicamente un usuario) y se puede pasar entre servicios para autorizar solicitudes. Un JWT tiene tres partes (header, payload, firma) unidas por puntos, con la firma validando criptográficamente que el payload no se modificó desde que se emitió. Los JWT son comunes para autenticación sin estado en microservicios y SPAs, aunque su manejo de expiración, revocación y almacenamiento en el navegador tienen pitfalls bien conocidos.
Un locale es un par idioma y región, escrito en formato BCP 47 como en-US o es-ES, que identifica para qué audiencia es un contenido. Un CMS headless usa locales para gestionar traducciones paralelas de la misma entrada, así los editores publican una sola pieza de contenido a múltiples sitios regionales con texto y formato localizado. La estrategia de locales decide qué mercados sirve una plataforma al lanzar, cómo funciona el fallback cuando falta una traducción, y si la estructura de URL varía por región.
LCP (Largest Contentful Paint) es la métrica de Core Web Vitals que mide cuándo el elemento visible más grande de la página (normalmente la imagen del hero o el titular principal) termina de renderizar. Google considera bueno un LCP de 2.5 segundos o menos, entre 2.5 y 4 segundos necesita mejora, y arriba de 4 segundos es pobre. La optimización de imágenes, el renderizado en servidor o generación estática, y eliminar JavaScript bloqueante son los tres arreglos de mayor impacto para LCP en la mayoría de modernizaciones.
MACH es un acrónimo de Microservicios, API-first, Cloud-native y Headless, cuatro principios de diseño que juntos describen lo que la mayoría llama hoy arquitectura componible. La MACH Alliance, fundada en 2020, impulsa el acrónimo como estándar de certificación para plataformas que cumplen los cuatro criterios. En la práctica los términos MACH y componible se usan de forma intercambiable, siendo componible el término de negocio y MACH la etiqueta técnica.
Los microservicios son un patrón arquitectónico donde una plataforma de negocio se divide en servicios pequeños e independientes, cada uno con sus propios datos y comunicándose por red a través de APIs. Cada servicio se puede desplegar, escalar y actualizar sin coordinar con los demás, lo que hace más rápidos a los equipos que los gestionan pero sube el listón en observabilidad y manejo de contratos. Un stack martech componible es, en la capa de plataforma, una arquitectura de microservicios donde Contentful, Algolia, Bynder y Vercel corren como servicios independientes.
Un modelo de contenido es el esquema y las relaciones que definen cada tipo de contenido que un equipo editorial puede publicar, los campos de cada tipo y cómo distintos tipos se referencian entre sí. En un CMS headless como Contentful o Sanity, el modelo de contenido es la base sobre la que se construye la plataforma, porque determina qué pueden crear los editores, qué devuelve la API y qué puede renderizar el frontend. La mayoría de las modernizaciones que fallan lo hacen porque se levantó el modelo de contenido de la plataforma vieja sin repensarlo para entrega headless y reuso multi-canal.
Un motor de personalización es un servicio que decide qué variante de contenido, layout u oferta debe ver un visitante específico, basado en sus atributos, comportamiento o pertenencia a un segmento de audiencia. Optimizely y Dynamic Yield son motores comunes en stacks empresariales, generalmente emparejados con un CMS que guarda el contenido variante y un CDP que aporta las señales de audiencia. Un motor de personalización es tan bueno como las audiencias que lo alimentan y la disciplina de experimentación detrás, y por eso la mayoría de programas de personalización se atasca en calidad de datos, no en features de plataforma.
La optimización de imágenes es la práctica de redimensionar imágenes de origen automáticamente, convertirlas a formatos modernos como AVIF y WebP, y servir la variante más pequeña viable a cada dispositivo. Next.js Image, Cloudinary, imgix y la pipeline de imágenes de Vercel realizan optimización al vuelo con caché, así los editores suben una sola imagen de origen y la plataforma genera las variantes por dispositivo. En plataformas componibles, la optimización de imágenes es la mayor mejora individual de LCP disponible, generalmente recortando el largest contentful paint entre 30 y 60 por ciento en páginas con muchas imágenes.
Open Graph es un estándar de metadatos, introducido por Facebook en 2010, que los publishers añaden al head de una página para controlar cómo aparece cuando se comparte en plataformas sociales. Las etiquetas og:title, og:description y og:image determinan el título, el blurb y la imagen de preview que salen en Facebook, LinkedIn, Slack, iMessage y la mayoría de apps de mensajería. Open Graph es una de las tareas de mayor impacto en treinta minutos dentro de un flujo de publicación, porque la mayoría de los clics desde redes sociales y chat dependen enteramente del preview que compone la plataforma.
Un origen es el servidor canónico detrás de un CDN, el lugar al que un edge del CDN va a buscar contenido cuando tiene un cache miss. Un origen puede ser un solo servidor de aplicación, un cluster balanceado, un object store como S3 o R2, o una plataforma de aplicación gestionada como Vercel. La protección del origen es una preocupación de seguridad porque exponer la URL del origen evita el caché y la protección DDoS del CDN, por eso los CDNs modernos ofrecen origin shields y allowlists por IP.
OAuth es un protocolo de autorización que permite a un usuario otorgar a una aplicación de terceros acceso limitado a sus recursos en otro servicio, sin compartir su contraseña. OAuth 2.0 es la versión vigente más usada, con flujos para apps de navegador, apps de servidor, móvil nativo, SPAs y tokens máquina-a-máquina. OAuth es lo que está detrás de los botones "Iniciar sesión con Google" y "Conectar con LinkedIn", y sustenta cómo las plataformas componibles se comunican entre sí en nombre del usuario.
Una plataforma PIM (Gestión de Información de Producto) es el sistema de registro para atributos de producto, taxonomías y datos a nivel SKU que consumen las herramientas downstream de comercio y marketing. Akeneo, inriver y Salsify centralizan descripciones, especificaciones, imágenes y overrides por canal, así el mismo producto se lee consistente en ecommerce, marketplaces y catálogos impresos. Un PIM se vuelve esencial en el momento que una marca vende más de unos cientos de SKUs por más de un canal, porque sin él los datos de producto se desincronizan entre sistemas.
Una plataforma de experimentación es la infraestructura para correr pruebas A/B, multivariadas y experimentos de feature sobre audiencia en vivo, incluyendo asignación de tráfico, asignación de variantes y cálculo de significancia estadística. Optimizely, Statsig, LaunchDarkly y Vercel Edge Config soportan experimentación junto a feature flags, con resultados que vuelven a las analíticas del equipo para tomar decisiones. La plataforma es la parte fácil; la mayoría de programas de experimentación fracasa en la calidad de hipótesis y en la disciplina de cortar las pruebas que no mueven la aguja.
RSC (Componentes de Servidor de React) son componentes en React 19 y posteriores que se renderizan exclusivamente en el servidor, con su salida transmitida al cliente como React serializado en vez de HTML. Los Server Components pueden acceder a bases de datos, sistemas de archivos y APIs privadas directamente, mientras los Client Components manejan la interactividad en el navegador, y Next.js App Router orquesta la mezcla. El patrón reduce el tamaño del bundle de JavaScript porque los componentes no interactivos nunca se envían al navegador, que es el mayor contribuyente a mejoras de Core Web Vitals en apps modernas.
La revalidación es el proceso de preguntarle al origen si el contenido cacheado sigue vigente, y reconstruir la entrada de caché o servir la existente. La revalidación puede ser por tiempo (la entrada expira después de N segundos), por tag (la caché se invalida cuando se dispara un evento relacionado) o bajo demanda (una llamada de API fuerza la reconstrucción). En Next.js, las funciones revalidateTag y revalidatePath se llaman típicamente desde un handler de webhook de Contentful cuando se publica contenido, así los cambios editoriales llegan en segundos.
Un rate limit es un techo sobre cuántas solicitudes puede hacer un cliente (identificado por IP, API key o user ID) a un servicio en una ventana de tiempo dada. Patrones comunes incluyen contadores de ventana fija, ventanas deslizantes, token buckets y leaky buckets, cada uno con trade-offs distintos de tolerancia a ráfagas y complejidad de implementación. Los rate limits protegen los servicios de abuso, loops accidentales en código cliente y sobrecostos por operaciones caras, y se aplican típicamente en el CDN, el API gateway o la capa de aplicación.
SSR (Renderizado en el Servidor) es una estrategia donde el HTML de una página se genera bajo demanda en el servidor para cada request entrante, y luego se envía al navegador. Produce HTML fresco por request, ideal para personalización, autenticación y datos en vivo, al costo de mayor cómputo en el origen comparado con renderizado estático. Next.js, Remix y Astro soportan SSR a través de sus runtimes de servidor, y la mayoría de arquitecturas componibles usa SSR para páginas autenticadas e ISR para el resto.
SSG (Generación de Sitios Estáticos) es una estrategia donde cada página se construye en HTML estático al momento del deploy, se sube a un CDN y se sirve idéntica a cada visitante. Es la forma más rápida y barata de servir contenido, con cero cómputo por request y entrega solo por CDN, pero cada actualización requiere reconstruir y redesplegar todo. SSG funciona bien para sitios de marketing, documentación y blogs con baja frecuencia de actualización, mientras que ISR agrega reconstrucciones incrementales para sitios donde los cambios editoriales deben publicar en minutos.
Un Server Action es un mecanismo de Next.js para llamar código del servidor directamente desde un submit de formulario o un event handler del cliente, sin escribir una API route separada. La función se marca con la directiva "use server", puede acceder a bases de datos y servicios privados, y bajo el capó React envía su invocación como un RPC. Los Server Actions son cómo funcionan los formularios, las mutaciones y las escrituras de contenido en apps Next.js modernas, reemplazando el patrón anterior de hacer POST a una API route escrita a mano.
Suspense es un primitivo de React que permite a un componente mostrar UI temporal (como un skeleton o spinner) mientras sus hijos esperan datos o código por cargar. Funciona tanto con code-splitting (componentes lazy) como con data fetching (Server Components, el hook use, librerías de terceros), y se compone con boundaries anidadas para controlar la granularidad. En Next.js App Router, Suspense es el mecanismo detrás del streaming server rendering, enviando HTML inicial rápido al navegador mientras los datos lentos se resuelven en segundo plano.
Streaming es un patrón de renderizado donde el servidor envía HTML al navegador en trozos a medida que cada parte está lista, en vez de esperar a que toda la página termine de renderizar. El navegador empieza a pintar desde el primer trozo, así los usuarios ven el header, el hero y el contenido principal mientras las partes lentas (como recomendaciones personalizadas) terminan en segundo plano. El streaming server rendering es una de las mayores mejoras disponibles de LCP y TTFB en frontends modernos, y está activo por defecto en Next.js App Router vía boundaries de Suspense.
Schema.org es un vocabulario compartido de tipos y propiedades (como Article, Event, Product, Person) que los publishers usan para marcar los datos estructurados dentro de una página web. Los buscadores (Google, Bing) y los motores de respuesta con IA (ChatGPT, Perplexity, Google AI Overviews) leen el marcado Schema.org para entender el contenido de una página más allá del texto visible. Schema.org es el input más citado para la selección de AI Overviews y Featured Snippets, y por eso los programas de GEO y AEO lo tratan como requisito de lanzamiento.
SEO (Optimización para Motores de Búsqueda) es la disciplina de hacer que las páginas web sean encontrables, rankeables y clickeables en motores de búsqueda, principalmente Google y Bing. Cubre SEO técnico (rastreabilidad, performance, datos estructurados), SEO on-page (calidad de contenido, targeting de palabras clave, enlazado interno) y SEO off-page (backlinks, menciones de marca, citaciones). El SEO clásico sigue trayendo la mayoría del tráfico orgánico para marcas B2B, pero AEO y GEO son ahora disciplinas hermanas que comparten el mismo contenido pero optimizan para distintos tipos de lector.
Stale-while-revalidate (SWR) es un patrón de caché donde el caché sirve una respuesta vieja de inmediato ante un cache miss, mientras una revalidación en segundo plano trae y guarda la respuesta fresca para la próxima solicitud. El patrón está definido en HTTP RFC 5861 y lo soportan la mayoría de CDNs (Vercel, Cloudflare, Fastly), y la librería SWR de React para data fetching del lado del cliente. Stale-while-revalidate da a los usuarios cargas de página instantáneas asegurando frescura eventual, que es el trade-off correcto para casi todo contenido de marketing y editorial.
Un tipo de contenido es un esquema reusable dentro de un CMS que define los campos y relaciones de una clase de contenido, como evento, artículo, ponente o producto. Cada tipo de contenido se convierte en un endpoint de API y una plantilla de creación para los editores, lo que permite que la misma plataforma entregue notas de prensa, páginas de producto y landings de evento desde un solo codebase. Los tipos bien acotados suelen tener entre cinco y doce campos, y se referencian entre sí en vez de duplicar datos.
El texto enriquecido es un campo de contenido tipo documento estructurado en un CMS que soporta encabezados, listas, párrafos, enlaces, embeds y bloques de código, expuesto como un árbol parseable en vez de HTML crudo. El formato Rich Text de Contentful es un árbol JSON que el frontend renderiza con un conjunto conocido de tipos de nodo, lo que da a los editores autoría WYSIWYG sin amarrar la salida a un solo design system. El texto enriquecido es la opción correcta para contenido editorial largo, mientras que los campos estructurados (Symbol, Number, Reference) manejan metadatos, taxonomías y enlaces.
Un token es una cadena que autoriza una acción específica o concede acceso a un recurso, generalmente embebida en un header HTTP o un parámetro de URL. Los tokens pueden ser opacos (un ID aleatorio que el servidor busca) o firmados (un JWT o HMAC que el receptor verifica sin una búsqueda en base de datos), con trade-offs distintos de revocación y estado. La mayoría de plataformas componibles modernas usa una combinación de tokens de sesión para autenticación de usuario, tokens de API para llamadas servicio-a-servicio y tokens en URL firmadas para acceso temporal a assets.
Un webhook es una llamada HTTP que un servicio dispara a otro para notificarle que ocurrió un evento, como una publicación de contenido, una subida de asset o un envío de formulario. Los receptores exponen una URL pública, validan la solicitud con una firma en un header y responden con un 200 para confirmar recepción antes de procesar el evento de forma asíncrona. Las plataformas componibles usan webhooks intensivamente porque permiten que servicios independientes se coordinen sin polling, como Contentful avisándole a Algolia que reindexe cuando se publica un artículo nuevo.
WCAG (Web Content Accessibility Guidelines) es el estándar internacional de accesibilidad digital, publicado por el W3C y adoptado por reguladores en EE. UU., la UE, Reino Unido, Canadá y otros. WCAG 2.2 es la versión actual, organizada en cuatro principios (Perceptible, Operable, Comprensible, Robusto) y tres niveles de conformidad (A, AA, AAA), siendo AA el objetivo típico de cumplimiento. La mayoría de programas digitales empresariales apunta a WCAG 2.2 AA en todo el sitio público, y muchos exigen AAA para superficies de alto valor o riesgo como checkout y gestión de cuenta.