Guía de mejora de calidad del sitio Astro, continuación - Ajustes finales para lograr 100 en todos los apartados de PageSpeed Insights

Introducción

En la anterior Guía de mejora de calidad del sitio Astro, resumí el amplio conjunto de mejoras aplicadas al sitio renovado de Acecore. Este artículo es su continuación.

Este artículo cierra los pequeños temas que quedaron pendientes tras publicar el artículo anterior y lleva el sitio a un estado en el que las cuatro métricas de PageSpeed Insights marcan 100 tanto en móvil como en escritorio. Además, no fue solo un ajuste de puntuación: también se sacaron GA4 y la búsqueda de la carga inicial, se reorganizaron breadcrumbs e indexación en Search Console, se estabilizó la renderización de iconos y se dejó claro dónde ya no tenía sentido seguir optimizando.

Resultado de 100 en todos los apartados de PageSpeed Insights

A fecha del 29 de marzo de 2026, la página principal de Acecore mostraba los siguientes resultados.

Debajo quedan las capturas reales de PageSpeed Insights junto con las URLs de los informes. En la ronda anterior consideraba que “móvil 99 / el resto 100” era el techo realista. Esta vez, al retirar beacons de terceros innecesarios y revisar con cuidado el significado de los diagnósticos restantes, se pudo llegar a 100.

URLs de los informes

Para dejar juntas las capturas y una evidencia que pueda reabrirse después, también dejo aquí las URLs directas de los informes usados en esta medición.

• Informe móvil
• Informe de escritorio

Haz clic en cada imagen para abrir el informe correspondiente de PageSpeed Insights.

Móvil Escritorio

Qué tan impresionante es un 100

Al oír “100”, se puede pensar que Performance siempre sube si uno sigue quitando funciones, simplificando el diseño y recortando elementos externos. En parte es verdad: en un sitio estático, cuanto más se quita, más fácil resulta ganar velocidad.

Pero aquí no se trataba de construir una página de demostración vacía. Había que mantener GA4, anuncios, búsqueda, ClientRouter y CSS compartido, y aun así alinear las cuatro métricas a 100 en móvil y escritorio. El trabajo no consistió solo en aligerar la página, sino en decidir qué debía quedarse, qué podía salir y qué ya no merecía tocarse más.

Por supuesto, 100 no significa que sea absolutamente el sitio más rápido del mundo real. La experiencia de los usuarios depende de la red, los dispositivos, la región y el estado de caché. Aun así, sí puede decirse que el sitio ha alcanzado un nivel muy alto en el sentido de que las auditorías principales de Lighthouse no muestran carencias importantes mientras los elementos operativos necesarios siguen presentes.

Ajustes finales para llegar a 100

1. Desactivar Cloudflare Web Analytics y aclarar el papel de la medición

Cloudflare Web Analytics es útil como producto RUM ligero y privacy-first, pero en Acecore la parte de GA4 ya estaba ampliamente instrumentada para clics en CTA, búsquedas, acciones de contacto, generación de leads y otros eventos.

Al revisar de nuevo el papel de cada herramienta, concluí que, del lado de Cloudflare, el coste de seguir inyectando un beacon innecesario en PageSpeed ya era mayor que el valor que aportaba. Desactivé RUM desde el panel y confirmé que static.cloudflareinsights.com/beacon.min.js había desaparecido del HTML de producción.

Pero esto no significaba abandonar la medición por completo. Seguía siendo importante conservar la medición de CTA, enlaces externos, búsqueda y conversiones de contacto, así que el siguiente paso fue mantener GA4 cambiando el momento en que se carga.

2. Mantener GA4, pero sacarlo de la carga inicial

La distinción importante aquí no era solo entre “dejar GA4” o “quitarlo”, sino entre “dejarlo” y “cargarlo desde el primer momento”.

En la práctica, el punto de entrada de gtag siguió disponible desde el inicio para poder recibir eventos, pero el script real gtag/js se movió a requestIdleCallback y a la interacción del usuario. Además, según la página se mantiene un fallback distinto para evitar que analytics quede sin cargar si no hay interacción.

Con ese cambio, la medición de CTA, enlaces externos, búsqueda y contacto siguió intacta, pero sin meter ejecución de scripts de terceros en la fase más temprana del render. El resultado de 100, por tanto, no vino solo de quitar el beacon de Cloudflare, sino también de cargar GA4 de una forma más inteligente.

3. Mover la búsqueda y Pagefind a carga bajo demanda

La búsqueda es otra función que puede pesar en silencio sobre la carga inicial aunque el usuario no la abra enseguida. Acecore usa Pagefind para la búsqueda de texto completo, y en esta ronda se aplicó la misma lógica: mantener la funcionalidad, pero no pagar su coste por adelantado.

El modal de búsqueda ahora carga pagefind-ui.js y su CSS solo cuando la búsqueda se abre de verdad. La promesa se almacena para evitar dobles cargas, y los atajos de teclado o la apertura mediante query string siguen funcionando normalmente.

Esto no solo favorece la puntuación de Lighthouse. También hace más ligera la primera visualización cotidiana. La búsqueda sigue presente, pero ya no necesita ir montada en la carga crítica de cada página.

4. Interpretar los diagnósticos restantes de PageSpeed

Incluso después de llegar a 100, PageSpeed puede seguir mostrando diagnósticos como Network dependency tree o render-blocking resources. Si se malinterpretan como avisos que siempre deben eliminarse, es fácil acabar persiguiendo optimizaciones de bajo valor.

La cadena crítica en este caso era aproximadamente la siguiente:

1. /en/
2. ClientRouter.js
3. BaseLayout.css
4. BaseLayout.js

De esos elementos, el único que seguía siendo verdaderamente render-blocking era BaseLayout.css. Sin embargo, su tamaño ya es lo bastante pequeño y el 100 móvil se mantiene, así que por ahora lo clasifiqué como “diagnóstico restante aceptable”. Poder expresar ese juicio con palabras fue en sí mismo una ganancia importante, porque deja una regla clara para decidir cuándo detener futuras optimizaciones.

5. Ordenar breadcrumbs e indexación en Search Console

Cuando PageSpeed ya estaba estable en 100, volví a revisar el sitio desde el lado de búsqueda. Ahí seguía quedando una incoherencia real: Search Console mostraba breadcrumbs inválidos, aunque el marcado FAQ ya estaba en buen estado.

Para corregirlo, la salida de BreadcrumbList en páginas de listado se rehízo para permitir pasar elementos explícitos en lugar de deducirlos demasiado libremente desde la URL. Al mismo tiempo, se alineó el manejo de trailing slash para que canonical, hreflang y breadcrumbs dejaran de divergir.

También se aclaró el papel de indexación de etiquetas, archivos, autores y paginación. Son páginas útiles como navegación, pero es fácil que se comporten como objetivos de indexación delgados o duplicados. Por eso se alinearon con noindex, follow y exclusión del sitemap. Esto no borra de inmediato todos los informes de “rastreada, actualmente sin indexar”, pero sí significa que la intención de indexación ahora está expresada directamente en el código.

6. Unificar la renderización de iconos en un componente SVG compartido

Como parte del ajuste final, el proyecto ya estaba migrando desde las utilidades de iconos de UnoCSS hacia un componente Icon basado en SVG compartido. En esa transición, quedaron restos de icon class dinámicas en ProcessFigure y StatBar, lo que provocaba que en algunos artículos aparecieran solo círculos vacíos.

Unifiqué la renderización del lado del componente mediante Icon y además añadí un alias para absorber el nombre legacy check-circle dentro de circle-check.

Como resultado, se obtuvieron tres beneficios prácticos:

• Resulta mucho más difícil que un icono desaparezca por haberse dejado una class dinámica
• Los atributos de accesibilidad como aria-hidden pueden unificarse en el lado SVG
• La operación se vuelve más estable porque la renderización deja de depender del análisis estático de UnoCSS

Al mismo tiempo, el análisis y la visualización de fechas del blog también se normalizaron alrededor del horario JST. No es el punto central de este artículo, pero sí mejora la estabilidad del orden de publicaciones del mismo día y la precisión temporal del marcado estructurado.

7. Lo que se probó pero no se adoptó

Cuando aparece un 100, la tentación natural es seguir persiguiendo cada diagnóstico restante hasta que ya no quede nada en pantalla. Comparé varias opciones en esa dirección, pero no adopté las siguientes.

• Dividir todavía más BaseLayout.css: podría hacer que los diagnósticos se vieran algo más limpios, pero el 100 móvil ya se mantiene y el beneficio práctico no justificaba la complejidad extra.
• Tomar como objetivo que desapareciera la mera visualización del network dependency tree: que un diagnóstico siga visible no significa automáticamente que exista un problema real para los usuarios.
• Reducir aún más los terceros hasta afectar incluso a GA4: quizá dejaría la página algo más ligera, pero a cambio se perdería medición clave del negocio.

Esa comparación fue importante. El ajuste final quedó cerrado no porque se hubiera quitado todo lo imaginable, sino porque los trade-offs restantes ya podían explicarse con claridad.

Aprendizajes prácticos del ajuste final

La mayor ganancia de esta vez no fue simplemente obtener 100 puntos. Fue haber llegado a un punto en el que puedo explicar qué debe eliminarse y qué es razonable dejar.

Por ejemplo, Cloudflare Web Analytics merece retirarse si solo sigue presente por inercia, mientras que GA4 debe mantenerse porque es el núcleo de la medición de eventos de negocio. Pero si GA4 se queda, eso no significa que tenga que ir en la carga inicial. La mejor solución es conservar la medición y cambiar el momento en que se carga.

La misma lógica aplica a la búsqueda y al SEO. La búsqueda debe quedarse, pero no hace falta montarla en el payload inicial. Las páginas de listado siguen siendo útiles para navegar, pero no tienen por qué tratarse como objetivos principales de indexación. Y network dependency tree no es un fallo por sí mismo; hay que mirar dentro y juzgar si la cadena restante es razonable.

También utilicé IA para ampliar el abanico de cambios candidatos, pero los criterios finales siguieron siendo tres preguntas muy concretas: si las mediciones mejoraban de verdad, si el coste operativo seguía siendo razonable y si las capacidades de medición necesarias permanecían intactas. La IA ayudó a abrir opciones; la decisión final siguió dependiendo de la medición y del juicio.

Si se optimiza pensando solo en la puntuación, el ajuste acaba yéndose demasiado lejos. Esta vez pude ordenar no solo las correcciones, sino también la línea a partir de la cual conviene detenerse, así que es razonable decir que las mejoras del sitio de Acecore han alcanzado, por ahora, un estado completo.

Resumen

Como continuación del artículo anterior, el ajuste final dejó resuelto lo siguiente:

• Confirmar 100 puntos en las cuatro métricas de PageSpeed Insights tanto en móvil como en escritorio
• Desactivar Cloudflare Web Analytics, manteniendo GA4 pero pasándolo a carga diferida
• Mover la búsqueda y Pagefind a carga bajo demanda y reducir el peso inicial
• Interpretar los diagnósticos de red restantes y aclarar qué problemas residuales son aceptables
• Limpiar la salida de breadcrumbs en Search Console y las reglas de indexación para páginas de listado
• Eliminar la falta de renderización de iconos al unificar en el SVG compartido Icon
• Descartar optimizaciones adicionales de poco retorno y dejar claro el punto razonable de parada

Al menos desde la perspectiva de Lighthouse y PageSpeed Insights, el sitio de Acecore ya se ha afinado hasta un punto en el que puede aspirar legítimamente a estar entre los más rápidos. Al mismo tiempo, la puntuación no es el objetivo, sino solo el resultado. A partir de aquí, seguiré manteniendo tanto la operación como las mejoras para que este estado no se deteriore.