Talently
Talently
Gatsby

Gatsby

El framework React para sitios web estáticos de alto rendimiento

Gatsby es un framework de React orientado a la generación de sitios estáticos y aplicaciones web de alto rendimiento. Basado en GraphQL para la capa de datos y con un ecosistema de plugins robusto, permite construir sitios ultrarrápidos consumiendo datos de múltiples fuentes como CMS, APIs y archivos locales, optimizando automáticamente imágenes, scripts y recursos.

ReactGraphQLSSGPerformance

Demanda del mercado

Gatsby tiene demanda estable en proyectos de marketing digital, blogs corporativos y sitios de contenido donde el rendimiento y el SEO son críticos. Ha perdido algo de tracción frente a Next.js para aplicaciones dinámicas, pero sigue siendo una opción sólida para sitios estáticos con múltiples fuentes de datos.

Fuerte en marketing y contenidoDemanda estable en agencias digitalesReferente en JAMstack

Requisitos técnicos

Intermediate

Requiere dominio de React, conceptos de GraphQL para consultar la capa de datos y familiaridad con el ciclo de build de sitios estáticos. Conocimiento de rendimiento web y Core Web Vitals es valioso para aprovechar las optimizaciones automáticas de Gatsby.

Casos de uso

Proyectos Reales

Gatsby se utiliza para desarrollar:

  • Sitios de marketing y landing pages de alto rendimiento
  • Blogs corporativos y sitios de contenido editorial
  • Documentación técnica de productos
  • Portfolios y sitios de presentación con múltiples fuentes de datos

Tipos de Empresa

Gatsby es adoptado por:

  • Agencias digitales con clientes de marketing
  • Empresas con sitios de contenido de alto tráfico
  • Startups con landing pages orientadas a conversión
  • Organizaciones con documentación técnica pública

Escenarios de Producción

Gatsby es ampliamente utilizado en entornos productivos como:

  • Sitios con contenido desde headless CMS como Contentful o Sanity
  • Blogs con alto volumen de artículos generados estáticamente
  • Landing pages con integración de múltiples fuentes de datos
  • Sitios de documentación con búsqueda integrada

Escalabilidad

Gatsby ofrece múltiples mecanismos para escalar aplicaciones:

  • Gatsby Cloud con builds incrementales para sitios grandes
  • Integración con CDN para distribución global de contenido estático
  • Deferred Static Generation para páginas de baja prioridad
  • Slice API para componentes compartidos que no requieren rebuild completo

Ventajas y Desventajas

Ventajas

Optimizaciones automáticas de rendimiento para imágenes, scripts y fuentes.

Ecosistema de plugins para integrar cualquier fuente de datos sin configuración.

Puntuaciones de Core Web Vitals excelentes por defecto en sitios bien construidos.

Desventajas

Tiempos de build largos en sitios con miles de páginas sin builds incrementales.

GraphQL como capa de datos puede ser excesivo para proyectos simples.

Ha perdido tracción frente a Next.js que cubre casos de uso similares con más flexibilidad.

Comparación

Ventajas de Next.js

  • Mayor flexibilidad combinando SSR, SSG e ISR
  • Mayor adopción y ecosistema más activo
  • Mejor para aplicaciones con contenido dinámico

Consideraciones

Next.js ha superado a Gatsby en adopción al cubrir tanto sitios estáticos como aplicaciones dinámicas. Gatsby sigue siendo competitivo para sitios de contenido puro con múltiples fuentes de datos donde su ecosistema de plugins aporta valor real.

Preguntas básicas

Gatsby es preferible cuando el proyecto consume datos de múltiples fuentes como CMS, APIs y archivos locales gracias a su ecosistema de plugins y GraphQL unificado. También cuando el equipo ya tiene experiencia con Gatsby o el proyecto es puramente estático sin necesidad de SSR dinámico.
Permite integrar fuentes de datos como Contentful, WordPress, Shopify o Markdown con configuración mínima. Los plugins de transformación, optimización de imágenes y rendimiento automatizan tareas que en otros frameworks requieren configuración manual, acelerando significativamente el desarrollo.
GraphQL actúa como capa de datos unificada que normaliza datos de múltiples fuentes en un mismo grafo consultable. Permite a los componentes solicitar exactamente los datos que necesitan independientemente de su origen, ya sea un CMS, una API REST o archivos locales.
Cuando se necesita máximo rendimiento con un sitio estático, flexibilidad para usar React en los componentes, integración con múltiples fuentes de datos o un proceso de desarrollo moderno con control de versiones del código y el contenido.
Optimización y conversión de imágenes a formatos modernos con gatsby-plugin-image, code splitting automático por ruta, prefetching de páginas enlazadas, inlining de CSS crítico y defer de scripts no críticos, generando puntuaciones de Lighthouse altas por defecto.
Mediante routing basado en sistema de archivos donde los archivos en la carpeta pages generan rutas automáticamente. Las páginas dinámicas se crean programáticamente en gatsby-node.js usando createPage con datos obtenidos de la capa GraphQL durante el build.
Es la capa centralizada de GraphQL que agrega datos de todas las fuentes configuradas mediante plugins de source. Permite consultar datos de cualquier origen con la misma sintaxis GraphQL desde cualquier componente, independientemente de dónde vengan originalmente los datos.
En sitios de contenido con múltiples fuentes de datos externas donde el ecosistema de plugins aporta valor real, en proyectos donde las optimizaciones automáticas de rendimiento son prioritarias, o en equipos React que construyen sitios de marketing con requisitos estrictos de Core Web Vitals.

Preguntas técnicas

Gatsby ejecuta primero gatsby-node.js para crear nodos de datos y páginas programáticas, luego genera el grafo GraphQL agregando datos de todos los plugins de source, después renderiza cada página como HTML estático con React y finalmente optimiza recursos como imágenes y scripts para el bundle final.
gatsby-config.js configura plugins y metadatos del sitio. gatsby-node.js ejecuta código en el servidor durante el build para crear páginas y modificar el grafo de datos. gatsby-browser.js ejecuta código en el navegador para gestionar el ciclo de vida del cliente como wrapping de la aplicación o acciones en cambios de ruta.
Consultando los datos en gatsby-node.js con GraphQL durante el build, iterando sobre los resultados y llamando a createPage con el template de React correspondiente y los datos del nodo como contexto. El template recibe los datos mediante una query de página con la variable de contexto.
Es el plugin oficial para optimización de imágenes que genera automáticamente múltiples tamaños, convierte a formatos modernos como WebP y AVIF, implementa lazy loading con placeholder, reserva espacio para prevenir layout shift y sirve el tamaño adecuado según el dispositivo del usuario.
Usando Deferred Static Generation para páginas de baja prioridad que se generan en el primer request, webhooks del CMS que disparan rebuilds automáticos en Gatsby Cloud o plataformas de CI/CD, o complementando con llamadas a APIs en el cliente para datos muy dinámicos que no pueden esperar un rebuild.
Usando StaticQuery o el hook useStaticQuery para datos en componentes que no son páginas, page queries en los templates de página para datos específicos de cada ruta, y fragmentos de GraphQL para reutilizar partes comunes de queries entre múltiples componentes.
Usando client-only routes para páginas que requieren autenticación o datos del usuario, llamadas a APIs en el cliente con useEffect o React Query para datos en tiempo real, y servicios externos como Netlify Functions o AWS Lambda para lógica backend sin servidor dedicado.
Activando Deferred Static Generation para páginas de baja prioridad que pueden generarse bajo demanda, usando builds incrementales en Gatsby Cloud que solo regeneran páginas cuyos datos cambiaron, y optimizando las queries GraphQL para minimizar el procesamiento durante el build.

Preguntas avanzadas

Organizando los templates de página por tipo de contenido, usando fragmentos GraphQL para compartir campos comunes entre queries, separando la lógica de creación de páginas en gatsby-node.js por tipo de contenido y configurando los plugins de source con opciones específicas para cada fuente en gatsby-config.js.
Usando client-only routes para las rutas de preview que no se generan estáticamente, consumiendo la API de preview del CMS desde el cliente con las credenciales de preview y mostrando el contenido no publicado. Se configura una URL de preview en el CMS que apunte a esta ruta especial de la aplicación.
Cuando el sitio necesita SSR para contenido personalizado, cuando los tiempos de build se vuelven inmanejables sin Gatsby Cloud, o cuando Next.js cubre mejor los casos de uso del proyecto. La migración implica reemplazar la capa GraphQL con el sistema de fetching de Next.js y adaptar el routing basado en archivos.
Auditando con Lighthouse y Web Vitals regularmente, usando siempre gatsby-plugin-image para todas las imágenes, cargando fuentes con gatsby-plugin-google-gtag u optimizando self-hosted fonts, minimizando el JavaScript de terceros con carga diferida y monitorizando las métricas reales con herramientas como Speedcurve.
Implementando un plugin de source con la función sourceNodes que obtiene los datos de la fuente interna y los convierte en nodos del grafo con createNode. Se definen los tipos de nodo con createTypes en gatsby-node.js y se documentan las queries GraphQL disponibles para que los componentes puedan consumirlos.
Creando páginas por idioma en gatsby-node.js con prefijos de ruta localizados, usando gatsby-plugin-react-i18next para la gestión de traducciones con carga diferida, configurando hreflang en el head de cada página para SEO y generando sitemaps localizados con gatsby-plugin-sitemap.

Errores comunes en entrevistas

Proponer Gatsby sin evaluar Next.js para casos donde ambos son viables refleja falta de criterio sobre el ecosistema actual. Se espera poder articular cuándo Gatsby sigue aportando valor sobre Next.js y reconocer que Next.js ha ganado terreno en muchos casos de uso.
Proponer Gatsby para proyectos con contenido muy dinámico o personalizado sin evaluar las implicaciones de los tiempos de rebuild refleja no entender el modelo estático. Se espera conocer cuándo ISR de Next.js o SSR es más adecuado.
Desconocer Deferred Static Generation o builds incrementales cuando se trabaja con sitios de gran volumen refleja poca experiencia con Gatsby en producción real.
Usar etiquetas img estándar en lugar de los componentes GatsbyImage o StaticImage elimina las optimizaciones automáticas que son uno de los principales valores de Gatsby. Es un error frecuente en developers que vienen de React sin experiencia específica con Gatsby.
Poner toda la lógica de creación de páginas en un único archivo gatsby-node.js sin separación por tipo de contenido genera código difícil de mantener en proyectos grandes. No conocer cómo organizar este archivo refleja poca experiencia en proyectos Gatsby de mediana o gran escala.
Usar useStaticQuery en templates de página o page queries en componentes que no son páginas refleja no entender las restricciones del sistema de queries de Gatsby. Es una confusión frecuente en developers nuevos con el framework.