¿Tu sitio se ve increíble pero tarda en cargar? Eso es exactamente lo que más daña tu posicionamiento en Google. En FENCODE lo vivimos de primera mano, y hoy te contamos cómo lo resolvimos.
Miguel Fernandez
Autor
Existe una creencia muy común entre los equipos de diseño y desarrollo: que un sitio visualmente impresionante tiene que sacrificar rendimiento, o viceversa. La verdad es que no tienes que elegir.
Cuando auditamos fencode.dev con Lighthouse —la herramienta de Google que mide la calidad técnica de un sitio web— encontramos varios puntos críticos que estaban afectando tanto la experiencia del usuario como nuestro posicionamiento orgánico. El resultado: implementamos una serie de cambios estratégicos que mejoraron drásticamente nuestros scores sin tocar una sola línea de diseño visual.
En este artículo te explicamos exactamente qué hicimos, por qué funciona, y cómo puedes aplicarlo a tu propio proyecto, ya sea en Next.js 15 o en cualquier otra tecnología web moderna.
Lighthouse es una herramienta de auditoría desarrollada por Google que evalúa tu sitio en cuatro dimensiones clave:
Cada categoría se puntúa de 0 a 100. Google utiliza muchas de estas métricas como factores de ranking, especialmente las relacionadas con los Core Web Vitals: tres indicadores que miden directamente la experiencia real del usuario al navegar tu sitio.
LCP — Largest Contentful Paint (Pintura del Elemento Más Grande)
Mide cuánto tiempo tarda en aparecer el elemento visual principal de tu página: el título hero, la imagen de portada, o cualquier bloque dominante en el primer vistazo. Google considera que un LCP por debajo de 2.5 segundos es bueno. Si supera los 4 segundos, estás en zona roja. En términos prácticos: es el tiempo que tiene tu sitio para decirle al usuario "aquí estás en el lugar correcto" antes de que cierre la pestaña.
CLS — Cumulative Layout Shift (Desplazamiento Acumulado del Layout)
Cuantifica cuánto "salta" o se mueve el contenido mientras la página termina de cargar. Ese molesto efecto donde intentas hacer clic en un botón y en el último momento el layout cambia y terminas tocando otra cosa. Un CLS ideal es menor a 0.1. Valores más altos son señal de que las imágenes no tienen dimensiones declaradas, las fuentes cambian el tamaño del texto al cargar, o los elementos dinámicos aparecen sin espacio reservado.
INP — Interaction to Next Paint (Interacción hasta la Siguiente Pintura)
Es la métrica más reciente, incorporada oficialmente en 2024 en reemplazo del FID. Mide cuánto tarda el navegador en responder visualmente después de que el usuario realiza una acción: un clic, un toque en pantalla, una pulsación de tecla. Un INP saludable es menor a 200 milisegundos. Si el hilo principal de JavaScript está ocupado procesando animaciones o lógica pesada, el usuario siente el sitio como "trabado" aunque técnicamente todo esté cargado.
Dicho en palabras simples: un sitio lento es un sitio que Google penaliza.
El LCP (Largest Contentful Paint) mide cuánto tiempo tarda en aparecer el elemento visual más grande de tu página, generalmente el título principal o la imagen hero. Google recomienda que este valor sea menor a 2.5 segundos.
En nuestro caso, teníamos el H1 animado con Framer Motion con un delay de entrada. Eso significaba que el navegador tenía que esperar que terminara la animación antes de "ver" el contenido principal. El resultado: un LCP inflado artificialmente.
La solución fue simple pero poderosa: eliminamos los delays de entrada en el texto principal. El título ahora aparece de forma instantánea. Las animaciones se aplican sobre contenido ya visible, no como condición para mostrarlo.
Regla de oro: si el usuario no puede leer de qué trata tu sitio en los primeros 1.5 segundos, ya lo perdiste.
Cómo aplicarlo en Next.js 15:
// ❌ Esto daña tu LCP
<motion.h1
initial={{ opacity: 0 }}
animate={{ opacity: 1 }}
transition={{ delay: 0.8 }} // Este delay es invisible para el usuario pero destruye el LCP
>
Tu Título Principal
// ✅ Esto lo protege
<motion.h1
initial={{ opacity: 1 }} // Visible desde el inicio
animate={{ y: [5, 0] }} // Animación sutil que no bloquea el render
transition={{ duration: 0.4 }}
>
Tu Título Principal
Teníamos archivos .lottie (animaciones vectoriales interactivas) de hasta 1.5MB cargándose en el primer render, compitiendo directamente con las imágenes y el contenido crítico por el ancho de banda del usuario.
La solución fue crear un componente InViewLottie que utiliza el IntersectionObserver del navegador para no descargar ni ejecutar la animación hasta que el usuario hace scroll hacia ella. Si nunca llega a verla, nunca la carga.
// Componente InViewLottie simplificado
'use client';
import { useRef, useState, useEffect } from 'react';
export function InViewLottie({ src }: { src: string }) {
const ref = useRef(null);
const [isVisible, setIsVisible] = useState(false);
useEffect(() => {
const observer = new IntersectionObserver(
([entry]) => { if (entry.isIntersecting) setIsVisible(true); },
{ threshold: 0.1 }
);
if (ref.current) observer.observe(ref.current);
return () => observer.disconnect();
}, []);
return (
{isVisible && }
);
}
Adicionalmente, activamos optimizePackageImports en next.config.ts para hacer Tree Shaking agresivo de librerías como Framer Motion y Lucide React.
¿Qué significa eso exactamente? Imagina que instalas una librería de íconos con 1,000 íconos distintos, pero en tu sitio solo usas 8. Sin Tree Shaking, el navegador descarga los 1,000 de todos modos. Con Tree Shaking, el proceso de compilación "sacude el árbol" y deja caer todo lo que no se usa, enviando al usuario únicamente los 8 que necesita. El resultado es un bundle de JavaScript considerablemente más liviano, lo que impacta directamente en la velocidad de carga.
optimizePackageImports le indica a Next.js que aplique esta optimización de forma automática sobre las librerías que especifiques, asegurándonos de incluir solo el código que realmente usamos:
// next.config.ts
const nextConfig = {
experimental: {
optimizePackageImports: ['framer-motion', 'lucide-react'],
},
};
El CLS (Cumulative Layout Shift) mide cuánto "salta" el contenido de tu página mientras carga. Ese molesto efecto donde intentas hacer clic en un botón y de repente el layout cambia y terminas haciendo clic en otra cosa. Google lo penaliza severamente porque destruye la experiencia del usuario.
En nuestro caso, las tarjetas del blog causaban saltos porque los títulos podían ocupar una o dos líneas, deformando los contenedores.
Dos ajustes clave:
a) Altura fija en componentes variables:
.blog-card-title {
min-height: 3rem; /* Siempre ocupa el mismo espacio */
display: -webkit-box;
-webkit-line-clamp: 2;
-webkit-box-orient: vertical;
overflow: hidden;
}
b) CSS sobre JavaScript para animaciones de UI:
Reemplazamos animaciones de entrada en JavaScript por transiciones CSS puras. Menos trabajo para el hilo principal del navegador, navegación más fluida.
/* ✅ CSS puro es siempre más eficiente para animaciones UI */
.faq-content {
max-height: 0;
overflow: hidden;
transition: max-height 0.3s ease-out;
}
.faq-content.open {
max-height: 500px;
}
Cada vez que tu sitio necesita conectarse a un servidor externo (Google Fonts, Supabase, una CDN), el navegador pierde milisegundos valiosos en el proceso de "descubrimiento". La solución es decirle al navegador de antemano a dónde se va a conectar.
En Next.js 15, esto se hace en el archivo layout.tsx:
// app/layout.tsx
export default function RootLayout({ children }) {
return (
{children}
);
}
También implementamos Critical CSS mediante la librería critters, que inyecta directamente en el HTML el CSS necesario para renderizar el contenido visible sin tener que esperar a que cargue el stylesheet completo. Esto elimina el famoso FOUC (Flash of Unstyled Content).
El rendimiento técnico es solo la mitad de la ecuación. La otra mitad es estructurar tu contenido para que Google no solo lo encuentre, sino que lo entienda.
Canonical y redirección 301:
Si tu sitio responde tanto en tudominio.com como en www.tudominio.com, Google puede interpretarlo como contenido duplicado y dividir tu autoridad de dominio. La solución es forzar una redirección 301 hacia la versión canónica.
// next.config.ts
async redirects() {
return [
{
source: '/:path*',
has: [{ type: 'host', value: 'fencode.dev' }],
destination: 'https://www.fencode.dev/:path*',
permanent: true,
},
];
}
JSON-LD: El lenguaje que Google entiende:
Los datos estructurados le explican a Google exactamente qué es tu contenido: quién lo escribió, cuándo, qué categoría tiene. Esto mejora la forma en que apareces en los resultados de búsqueda y puede generar rich snippets que aumentan tu CTR.
// Para artículos de blog
const jsonLd = {
'@context': 'https://schema.org',
'@type': 'BlogPosting',
headline: post.title,
author: { '@type': 'Person', name: post.author },
datePublished: post.publishedAt,
breadcrumb: {
'@type': 'BreadcrumbList',
itemListElement: [
{ '@type': 'ListItem', position: 1, name: 'Blog', item: 'https://www.fencode.dev/blog' },
{ '@type': 'ListItem', position: 2, name: post.title },
],
},
};
// En tu componente
Next.js 15 introdujo un cambio importante en cómo se manejan los parámetros de rutas dinámicas. Los params ahora son promesas asíncronas, y si no migras tu código, obtienes warnings en consola que, aunque parecen inofensivos, suman carga al proceso de hidratación de React 19.
// ❌ Forma antigua (Next.js 14 y anteriores)
export default function BlogPost({ params }: { params: { slug: string } }) {
const { slug } = params;
// ...
}
// ✅ Forma correcta en Next.js 15
export default async function BlogPost({
params,
}: {
params: Promise;
}) {
const { slug } = await params;
// ...
}
Todos estos cambios tienen un hilo conductor: entender y optimizar el Camino Crítico de Renderizado. Este concepto describe la secuencia de pasos que el navegador sigue para convertir tu código en píxeles en la pantalla del usuario.
Cada recurso que bloquea ese camino (un JS pesado, un CSS no crítico, una fuente sin preconnect) es un milisegundo que el usuario espera. Y cada milisegundo que espera es una probabilidad más alta de que se vaya.
La optimización no es instalar librerías. Es entender ese camino y eliminar cada obstáculo en él.
Quizás te preguntas si todo esto vale el esfuerzo. Aquí va la respuesta en números:
Antes de cerrar, aquí tienes una lista de verificación que puedes aplicar hoy mismo a cualquier proyecto:
preconnect y font-display: swapOptimizar el rendimiento de tu sitio web no es un lujo técnico ni un proyecto para "cuando haya tiempo". Es una condición necesaria para competir en el entorno digital actual, donde Google evalúa tu velocidad antes de decidir si mereces visibilidad.
La buena noticia es que no tienes que elegir entre un sitio visualmente impactante y uno técnicamente eficiente. Con las estrategias correctas, puedes tener los dos.
En FENCODE hemos recorrido ese camino, y los resultados hablan solos. Si tienes un proyecto que necesita ese salto de calidad técnica, en fencode.dev estamos listos para ayudarte.
¿Tienes preguntas sobre cómo implementar alguno de estos cambios en tu proyecto? Contáctanos directamente desde el formulario de contacto. Revisamos cada consulta con atención.
