Performance, accesibilidad y SEO: Core Web Vitals + WCAG 2.2 + búsquedas

Hay tres mediciones que un sitio profesional debe pasar para considerarse profesional en 2026: Core Web Vitals en verde, conformidad WCAG 2.2 nivel AA, y técnica SEO sólida. Las tres están relacionadas: un sitio rápido y accesible suele rankear mejor, y la inversa también.

Este post enumera los criterios concretos, las métricas y los caminos para cumplirlas.

Capítulo 1 — Core Web Vitals

Google publica los Core Web Vitals en web.dev. En 2026 son tres métricas:

LCP — Largest Contentful Paint

Tiempo desde el inicio de carga hasta que el elemento “más grande” del viewport queda renderizado. Es la percepción de “ya está cargada la página”.

• Bueno: ≤ 2.5 segundos
• Necesita mejorar: 2.5–4 s
• Pobre: > 4 s

Causas típicas de LCP malo:

• Hero image grande sin optimizar (sin WebP/AVIF, sin srcset).
• CSS bloqueante en el head con muchas reglas.
• Fonts sin font-display: swap.
• Servidor lento (TTFB alto).

Mitigaciones:

• Imágenes responsive con srcset/sizes, formato moderno, lazy loading excepto el LCP image que va fetchpriority="high".
• Critical CSS inline.
• Preload de fonts y del hero image.
• CDN para assets estáticos.

INP — Interaction to Next Paint

Reemplazó a FID en marzo 2024 según web.dev. Mide la respuesta a las interacciones del usuario (clicks, taps, teclas) durante toda la sesión, no solo la primera.

• Bueno: ≤ 200 ms
• Necesita mejorar: 200–500 ms
• Pobre: > 500 ms

Causas típicas de INP malo:

• JavaScript pesado en el main thread.
• Event handlers que hacen trabajo síncrono extenso.
• Re-renders masivos en React/Vue cuando se interactúa.
• Third-party scripts (analytics, chat, ads) que bloquean.

Mitigaciones:

• Code splitting (cargar solo lo necesario).
• Diferir scripts no críticos.
• Web Workers para cómputo pesado.
• requestIdleCallback para tareas no urgentes.
• Reducir JS de terceros o cargarlo con defer.

CLS — Cumulative Layout Shift

Mide cuánto se mueve el contenido inesperadamente durante la carga (medido en una unidad sin dimensiones, no en píxeles).

• Bueno: ≤ 0.1
• Necesita mejorar: 0.1–0.25
• Pobre: > 0.25

Causas típicas de CLS malo:

• Imágenes sin width y height declarados.
• Fonts que cambian al cargar y reflujan texto.
• Banners de cookies que aparecen empujando contenido.
• Iframes (YouTube, Twitter, etc.) sin altura reservada.

Mitigaciones:

• Declarar dimensiones en imágenes, videos e iframes.
• font-display: swap con fallback metrics ajustados.
• Reservar espacio para banners/anuncios antes que aparezcan.
• Animaciones con transform y opacity (no afectan layout) en lugar de top/left/width.

Cómo medir

• Field data: usuarios reales, vía Chrome User Experience Report (CrUX) o Real User Monitoring propio.
• Lab data: Lighthouse, PageSpeed Insights, WebPageTest.

Google usa field data para ranking. El lab data es útil para debuggear.

Las cifras se evalúan en percentil 75 (web.dev): el 75% de las visitas debe estar bajo el umbral, no solo el promedio.

Capítulo 2 — Accesibilidad WCAG 2.2

WCAG 2.2 fue publicado por el W3C como Recommendation el 12 de diciembre de 2024 (fuente). Es la versión vigente, sucesora de WCAG 2.1 (2018) y 2.0 (2008).

Cuatro principios

WCAG estructura los criterios en cuatro principios:

1. Perceivable (perceptible): la información debe presentarse de forma que los usuarios la puedan percibir.
2. Operable: los componentes y la navegación deben ser operables.
3. Understandable (entendible): la información y la operación deben ser entendibles.
4. Robust (robusto): el contenido debe funcionar con tecnologías asistivas actuales y futuras.

Tres niveles de conformidad

• A (mínimo): básico.
• AA (recomendado): el estándar en sector privado y obligatorio en muchas regulaciones públicas.
• AAA (alto): difícil en sitios con mucho contenido textual.

WCAG 2.2 incluye 9 criterios nuevos sobre 2.1 (fuente), entre ellos: Focus Not Obscured, Focus Appearance, Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry, Accessible Authentication.

Criterios de alto impacto en sitios corporativos

Contraste de texto (1.4.3 / 1.4.6)

• AA: 4.5:1 para texto normal, 3:1 para texto grande.
• AAA: 7:1 / 4.5:1.

Herramientas: WebAIM Contrast Checker, Stark, contraste integrado en Chrome DevTools.

Navegación por teclado (2.1.1)

Todo lo que se hace con mouse debe poder hacerse con teclado solo. Tab para navegar, Enter para activar, Esc para cerrar, flechas para listas/menús. Focus visible.

Etiquetado y semántica (1.3.1, 4.1.2)

• HTML semántico (<nav>, <main>, <article>, <button>).
• Inputs con <label> asociado por for/id.
• Imágenes con alt significativo (o alt="" si son decorativas).
• ARIA solo cuando HTML semántico no alcanza.

Target size (2.5.8) — nuevo en 2.2

Botones y links táctiles deben tener mínimo 24×24 píxeles de área (excepciones para inline links en texto).

Focus visible (2.4.7) y focus appearance (2.4.13) — 2.4.13 es nuevo en 2.2

El elemento con foco debe ser claramente visible. Espesor mínimo del borde y contraste contra el fondo definidos en 2.2.

Cómo testear

• Automatizado: axe-core (extensión y librería), Lighthouse Accessibility, WAVE. Detectan ~30-40% de los issues.
• Manual: navegación con teclado, lector de pantalla (NVDA en Windows, VoiceOver en macOS, TalkBack en Android), pruebas con zoom 200%.
• Usuarios reales con discapacidades: cuando se puede, lo más valioso. Servicios especializados ofrecen testing con paneles diversos.

Por qué importa más allá del cumplimiento

• En muchos países hay regulación que obliga (sector público, sector financiero, según jurisdicción). En Argentina, la Ley 26.653 de Accesibilidad de la Información en sitios web del Estado.
• 15-20% de la población tiene alguna discapacidad. Diseñar inaccesible los excluye comercialmente.
• Los criterios de accesibilidad mejoran la usabilidad para todos: contraste alto se ve mejor en pantalla con sol, navegación por teclado es más rápida para usuarios power.

Capítulo 3 — SEO técnico

Google publica los lineamientos de Page Experience que combinan Core Web Vitals con otras señales (fuente).

Fundamentos

HTML semántico y estructurado

• <title> único por página, descriptivo.
• <meta name="description"> 150-160 caracteres, persuasivo.
• Headings jerárquicos: un <h1> por página, <h2>/<h3> ordenados.
• URLs limpias, descriptivas, en minúsculas, separadas por guiones.

Schema.org / JSON-LD

Microdatos que permiten a Google entender el contenido. Para un sitio corporativo:

• Organization con nombre, logo, dirección, teléfono.
• LocalBusiness para presencia física.
• Article para posts de blog.
• BreadcrumbList para navegación.
• FAQPage para preguntas frecuentes.

Sitemap.xml

Indexable, declarado en robots.txt. Astro lo genera con el adapter @astrojs/sitemap. Para sitios multi-idioma, declarar las alternativas con xhtml:link.

robots.txt

Indica qué se indexa y qué no. Permitir todo lo público, bloquear /admin/, /api/, parámetros de tracking.

Canonical correcto

<link rel="canonical"> en cada página apuntando a la URL preferida. Evita problemas de contenido duplicado entre versiones (con/sin slash final, parámetros UTM, etc.).

Internacionalización

Para sitios con múltiples idiomas o países:

• <html lang="es-AR"> correcto.
• <link rel="alternate" hreflang="..."> declarando todas las versiones lingüísticas y regionales.
• x-default para la versión que se sirve si ninguna otra coincide.

Mobile-first

Google indexa la versión mobile del sitio. Si la versión móvil tiene menos contenido o peor performance que la desktop, el ranking sufre.

Velocidad como factor

Page Experience consolida los Core Web Vitals como señal de ranking. Un sitio rápido rankea mejor, todo lo demás igual.

Contenido y E-E-A-T

Más allá de lo técnico, Google valora Experience, Expertise, Authoritativeness, Trustworthiness. Para un sitio profesional:

• Contenido escrito por personas con experiencia documentada.
• Autoría visible (quién escribió cada post).
• Citaciones a fuentes confiables.
• Información de la empresa actualizada y verificable.

La intersección de los tres

Hacer las tres bien refuerza cada una:

• Un sitio rápido (CWV verde) tiene tasa de rebote menor → señal positiva para SEO.
• HTML semántico facilita accesibilidad y parsing de Google.
• Imágenes con alt significativo cumplen WCAG y mejoran SEO de imágenes.
• Headings jerárquicos ayudan a usuarios de lectores de pantalla y a Google a entender la estructura.

Lo opuesto también: dejar afuera una de las tres degrada las otras. Un sitio rápido pero inaccesible excluye usuarios y pierde por compliance. Un sitio accesible pero lento castiga el ranking. Un sitio rápido y accesible pero con SEO técnico flojo no se descubre.

Cómo encarar un sitio nuevo o mejorado

Sprint 1 — Auditoría de baseline

Antes de tocar nada, medir:

• Lighthouse en 5-10 páginas críticas.
• Field CWV de Search Console (CrUX).
• axe-core sobre las mismas páginas.
• Validar HTML, sitemap, robots, hreflang.

Sprint 2 — Quick wins

• Optimizar imágenes (WebP/AVIF, dimensiones declaradas, lazy load).
• Diferir JS no crítico.
• Agregar lang, alt, label faltantes.
• Corregir errores de validación HTML.
• Agregar Schema.org básico.

Sprint 3 — Profundo

• Refactor de componentes con problemas de focus management.
• Code splitting agresivo.
• Critical CSS inline.
• Pruebas con teclado y lector de pantalla.

Sprint 4 — Validación y monitoreo

• RUM para CWV en producción.
• Pruebas con usuarios reales de accesibilidad.
• Monitoreo continuo en Search Console.
• Re-auditoría trimestral.

Conclusión

Performance, accesibilidad y SEO no son tres proyectos: son tres dimensiones del mismo proyecto. Las métricas son objetivas y públicas. Los caminos para cumplirlas están documentados (web.dev, WCAG 2.2, Google Search Central). La diferencia entre un sitio profesional y uno improvisado en 2026 es haber medido y cumplido las tres, no haber elegido el framework de moda. Si tu sitio falla en alguna, sabés exactamente qué arreglar y dónde leer cómo hacerlo.

Fuentes y referencias

• web.dev — Core Web Vitals
• W3C — WCAG 2.2
• Google Search Central — Page Experience
• MDN — Web Performance

Fuentes

• web.dev — Core Web Vitals
• W3C — WCAG 2.2
• Google Search Central — Page Experience
• MDN — Web Performance