Voy a documentar lo que voy a ir haciendo con una web, businet.brigzen.com, que usa WordPress y con el tema Astra para optimizar su carga de manera que pase con 100 puntos el PageSpeed Insight.
Lo primero que voy a hacer es pasarla por el PageSpeed Insight y ver de qué se queja, tomaré nota de los scripts y de los estilos y trabajaré en función de ellos.
Este es el resultado en PageSpeed Insight sin hacer ningún cambio.
Estas son las cosas a mejorar
Los estilos que se están cargando
https://businet.brigzen.com/wp-content/themes/astra/assets/css/minified/main.min.css?ver=3.6.6
https://fonts.googleapis.com/css?family=Merriweather%3A400%2C%7COxygen%3A400%2C&display=fallback&ver=3.6.6
https://businet.brigzen.com/wp-includes/css/dist/block-library/style.min.css?ver=5.8
https://businet.brigzen.com/wp-content/plugins/wpforms-lite/assets/css/wpforms-full.min.css?ver=1.6.8.1
https://use.fontawesome.com/releases/v5.15.3/css/all.css?ver=2.0.1
https://use.fontawesome.com/releases/v5.15.3/css/v4-shims.css?ver=2.0.1- El primero es el CSS propio del tema, dónde me tengo que enfocar en sacar el CSS crítico.
- El segundo es la solicitud para las fuentes que son tomadas de Google Fonts. Esto se elimina, se aplaza, o se descargan en local. Yo opto por quitarlas. De esa manara se elimina una consulta y un archivo que bloquea el renderizado al mismo tiempo.
- Tercera es el CSS de los bloques de WordPress que entiendo que a partir de la reciente versión 5.8 el mismo WordPress genera un archivo con el CSS crítico.
- El cuarto es el CSS del plugin para el formulario de contacto que a su vez creo que es el causante que está haciendo otro llamado a font-awesome
- El quinto y sexto son solicitudes para el CSS de las font-awesome, esto también es apreciable si se elimina. Aunque creo que luego se puede vivir aplazándolo de manera diferida.
Más o menos estos de aquí abajo
De esos, 5 están dando lata en el PageSpeed Insight bloqueando el renderizado. No hay scripts porque Astra los coloca al final del body.
Estas son las métricas de los CSS en GTMetrix
Estos son los scripts 🙂
https://businet.brigzen.com/wp-includes/js/wp-emoji-release.min.js?ver=5.8
https://businet.brigzen.com/wp-includes/js/jquery/jquery.min.js?ver=3.6.0
https://businet.brigzen.com/wp-includes/js/jquery/jquery-migrate.min.js?ver=3.3.2
https://businet.brigzen.com/wp-content/themes/astra/assets/js/minified/frontend.min.js?ver=3.6.6
https://businet.brigzen.com/wp-includes/js/wp-embed.min.js?ver=5.8
https://businet.brigzen.com/wp-content/plugins/wpforms-lite/assets/js/jquery.validate.min.js?ver=1.19.0
https://businet.brigzen.com/wp-content/plugins/wpforms-lite/assets/js/mailcheck.min.js?ver=1.1.2
https://businet.brigzen.com/wp-content/plugins/wpforms-lite/assets/js/wpforms.js?ver=1.6.8.1Se empieza por el servidor si se pudiese
Cuando se quiere trabajar con un sitio web optimizado para el SEO y que cumpla con las CWV debemos empezar si es posible desde el servidor. Es decir, tomar en cuenta ajustes y optimización en el servidor, luego en el código HTML y CSS.
Uno de los puntos álgidos en el servidor es proporcionarle por medio de módulos la capacidad para detectar CSS crítico, extraerlo y colocarlo en la cabecera entre etiquetas <script></script>, cosa muy importante cuando se usa temas de WordPress por ejemplo.
Pero, por ahora, el tema del servidor lo pasamos por alto por algunas razones:
- Usualmente usamos servicios de hosting que son servidores compartidos o VPS cuaya optimización se escapa de nuestras manos.
- El uso de un CDN nos ayuda enormemente a la velocidad de entrega inicial, con lo que la rapidez de un server queda en un segundo plano a no ser que uses una web muy dinámica y el que cacheo ya no te va.
- El tema del CSS crítico y los scripts deberían quedar resueltos si se trabaja con código propio.
El tema que se está usando
Pero ya que lo usual es implementar una serie de códigos de terceros que mantendrán las actualizaciones al día por mucho tiempo y que ahorraran días, semanas o meses de desarrollo, entonces esto queda por tomar la decisión de usar un tema WordPress de calidad que esté enfocado hacia el SEO.
En estos casos podrían ser los temas oficiales de WordPress, este mismo que estoy usando en esta Web es Twenty Nineteen. O podrían ser Astra o GeneratePress. Si me pones a elegir diría que GeneratePress es el más optimo para el SEO, me gusta mucho porque no incorpora jQuery entre sus scripts. No obstante Astra sí lo incorpora pero no lo hace necesario para el renderizado y dado eso lo ponen al final de la página. No obstante Astra está enfocándose en su compatibilidad con Elementor, cosa que hace que definitivamente me decante por GeneratePress.
Si pensabas que un sitio web se podía optimizar luego de haber montado los códigos, te equivocaste, se podrá corregir, pero será bastante complicado. Insisto, si tú hiciste tus códigos, entonces ya se te hará más fácil por más embrollada que esté tu web.
Dicho lo anterior, la optimización que estoy llevando a cabo aquí es con el tema Astra, no hagamos las cosas tan fácil, ¿verdad?
Lo más problemático: FontAwesome
Puedes ver en la figura 2 que la mayor queja de PSI es “Elimina los recursos que bloqueen el renderizado“. Son puros archivos CSS.
Astra manda todas las referencias a recursos Javascript al final del body.
De todos las referencias CSS la más pesada y la que mayor ahorro de tiempo supone es la que hace referencia a use.fontawesome.com.
Estos recursos están siendo requeridos por un complemento instalado para ello. En este caso es el plugin Better Font Awesome (sorry Mickey Kay, tuve que tomar un plugin como ejemplo).
Incluso en GTMetrix se observan no uno si no dos llamadas a recursos externos FontAwesome que no me he prestado a averiguar por qué, ya que igual me voy a volar el plugin.
Para una carga optimizada, mientras menos llamadas a recursos externos mejor. En el caso de FontAwesome lo primero que se me viene a la cabeza es dejar de usarlo. Con eso me ahorro llamadas a recursos externos y algo menos que bloquea el renderizado. Pero la verdad es que los SVG molan bastante y hasta dan el toque profesional al acabado final.
En esta Web los utilizo para decorar algunos enlaces a sitios con información personal mía.
Para ir solucionando se podría agregar un DNS-Prefetch a la referencia, pero dudo sobre su efectividad ya que el llamado a estos recursos esta inmediatamente después, en el mismo head.
Sea o no, mi mejor solución es cargar esos recursos en el servidor y volarme el plugin. Sin más preámbulos, en mi artículo Incorporar Font Awesome a WordPress manteniendo las métricas Core Web Vitals está explicado el procedimiento al detalle.
Por favor, continúa en ese artículo, luego regresa aquí desde esta línea.
Finalizada la optimización de FontAweson podríamos experimentar una mejora en la métrica de PSI y ya veríamos que no aparece la consulta a use.fontawesome.com bloqueando el renderizado.
Lo segundo: los CSS de los bloques de WordPress
Antes de continuar quiero aclarar que podríamos guiarnos por ir arreglando los archivos que son más pesados, pero eso es una guía mas no lo regla. Se puede observar en la figura 9 que google fonts representan un mayor ahorro de tiempo que lo que supone el CSS de las librerías. Eso es porque se trata de optimización y no reducción del tamaño total de archivos. Quizás, el hecho de que las google fonts sean un recurso externo consume más tiempo.
Pero a lo que vinimos a esta parte, el CSS de los bloques de WordPress, el que se muestra aquí abajo.
<link rel='stylesheet' id='wp-block-library-css' href='https://businet.brigzen.com/wp-includes/css/dist/block-library/style.min.css' media='all' />Lo que se podía hacer hasta hace poco menos de un mes, específicamente entes del 21 de julio, era de nuevo extraer los códigos css críticos, colocarlos en línea o en un archivo diferente y diferir el archivo original.
No obstante a partir del 21 de julio entró a disposición WordPress 5.8, en esta versión agregaron algo fantástico. Nuestros compañeros desarrolladores del core de WordPress encontraron la forma de extraer el CSS de los bloques específicos que se están usando en la página que se descarga y lo incorporan de forma dinámica como CSS inline.
Tengo entendido que para ello el tema instalado debe ser compatible con eso (de ahí la importancia de estilos de terceros para que otros hagan los trabajados de actualización), pero para saberlo creo que habría que consultarlo con el desarrollador del código. No obstante no pondría en duda que Astra ya se adelantó a ello desde hace rato.
Luego, aparte de ser compatible, debe estar habilitado, para ello se debe agregar la siguiente instrucción al archivo function.php del tema secundario:
add_filter( 'should_load_separate_core_block_assets', '__return_true' );Gracias a ello ahora pasamos de esto:
A esto:
Ahora tenemos un CSS inline con el id wp-block-library-inline, y además, la referencia al archivo que estaba anteriormente lo ha removido y ha creado otro con el id wp-block-cover que lo ha puesto al final de la página, cosa muy ideal para que cargue el resto del CSS que no se usa en caso que el usuario navegue por la web y se los encuentre. Tal cual como se debe de hacer.
Ahora deberíamos ver una mejora en la métrica de PSI y un recurso menos que bloquea el renderizado.
Las fonts de Google
La lógica de esta redacción es que ataquemos ahora los CSS propios del tema. Pero hagamos un cambio y vallamos con lo aparentemente más pequeño. En este caso las fuentes de Google. Este tema está usando Oxigen y Merriweather.
Podríamos hacer algo parecido a las Fontawesome, es decir, cargar las fuentes en el servidor. Pero esto no es lo que aplicamos cuando vamos con todo con el SEO y la optimización para pasar las Core Web Vitals.
Cargar las fuentes en el servidor va a ocasionar que igualmente tengamos que transferir esos archivos al usuario para poder usarlas.
Para optimizar las fuentes no hay nada mejor que no cargar ninguna fuente. La optimización de las fuentes da mucha lata, y sinceramente el diseño preciso no va bien con técnicas SEO.
Si lo que se quiere es darle prioridad al SEO y por ende, a pasar las CWV entonces lo más recomendable es deshacernos de las fuentes externas y trabajar con las fuentes locales de los diferentes sistemas operativos.
Como algo establecido entre los SEO se ha optado por una pila de las fuentes con mejor estilo de los diferentes sistemas operativos y se agregan como atributos font-family al selector body en el CSS como se muestra abajo.
body {
font-family: -apple-system, /*Customization*/
BlinkMacSystemFont,
"Segoe UI",
Roboto,
Oxygen-Sans,
Ubuntu,
Cantarell,
"Helvetica Neue",
sans-serif;
}Luego quitar del CSS todas las personalizaciones de fuentes que estaban usando las fuentes de Google.
Esto es lo que hacen los pioneros en SEO tal como puedes ver abajo.
Finalmente sacamos la referencia a las fonts de Google con el siguiente script en el plugin de funciones personales o en el function.php del tema secundario.
function brigzen_deregister_theme_styles() {
wp_dequeue_style( 'astra-google-fonts' );
}
add_action( 'wp_enqueue_scripts', 'brigzen_deregister_theme_styles', 100 );Más detalle sobre el script de arriba en mi artículo Colocar referencia a estilos y scripts en el head de una web con WordPress.
Ahora tenemos otra ligera mejora en las métricas de PageSpeed Insight y de nuevo un recurso menos que bloquea el renderizado.
A estas alturas ya los recursos que bloquean el renderizado no es el mayor requerimiento.
WPForms – un estilo a diferir
Como se habrá dado cuenta ya, esto de optimizar una web no es de aplicar una serie de procedimientos establecidos, se trata más bien de evaluar lo que está ocurriendo y aplicar una solución particular o apropiada según el escenario. En el caso del formulario de contacto ocurre que el estilo es necesario para su funcionamiento. Pero…
Cargar los estilos solo en la página de contacto
Normalmente el formulario de contacto creado con complementos como WPForms o Contact Form 7 colocan la hoja de estilos en toda la web. Entonces ocurre que de X cantidad de páginas y y artículos en una web solo una tiene el formulario, pero igual la hoja de estilos se carga en la X cantidad de páginas.
Esto se soluciona colocando un script en un plugin personalizado para ello o en su defecto en al archivo function.php del tema secundario. Este script filtra la url de la página con una función, que si no coincide con la especificación entonces saca la referencia del estilo con la función wp_dequeue_style.
// Deregistrar estilos CSS de Contact Form 7 en las páginas sin formulario
function brigzen_deregister_styles() {
if ( ! is_page( 'contacto' ) ) {
wp_dequeue_style( 'wpforms-full' );
}
}
add_action( 'wp_print_styles', 'brigzen_deregister_styles', 100 );Se debe cambiar “contacto” por el slug de la página que tiene el formulario. Y se debe cambiar “wpforms-full” por el id de la referencia al estilo del formulario.
Si son varias páginas que tienen formularios entonces se coloca los slugs separados por coma.
// Deregistrar estilos CSS de Contact Form 7 en las páginas sin formulario
function brigzen_deregister_styles() {
if ( ! is_page( 'contacto', 'contacto-2', 'contacto-3' ) {
wp_dequeue_style( 'wpforms-full' );
}
}
add_action( 'wp_print_styles', 'brigzen_deregister_styles', 100 );Esta solución va a sacar la referencia a esa hoja de estilos de todas las páginas, menos en la que efectivamente tenga el formulario. Por lo tanto debería dejar de ver el reclamo de PSI para con esta referencia a ese estilo, a excepción solo de que esté chequeando en PSI la página donde tiene el formulario.
Diferir la referencia a la hoja de estilos
Ahora bien, en la web en la que estoy haciendo esta optimización, businet.brigzen.com, el formulario de contacto está en la misma home al final. De hecho esa web tiene una sola página. Por lo que la solución anterior no me vendría al caso.
Entonces, y debido a que el formulario está al final de la página, vendría mejor diferir la referencia a la hoja de estilo del formulario de contacto.
Eso se hace convirtiendo la referencia a la hoja de estilos de esto:
<link rel='stylesheet' id='wpforms-full-css' href='https://businet.brigzen.com/wp-content/plugins/wpforms-lite/assets/css/wpforms-full.min.css?ver=1.6.8.1' media='all' />A esto:
<link rel="preload" as="style" id="wpforms-full" href="https://businet.brigzen.com/wp-content/plugins/wpforms-lite/assets/css/wpforms-full.min.css?ver=1.6.8.1" media="all" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="https://businet.brigzen.com/wp-content/plugins/wpforms-lite/assets/css/wpforms-full.min.css?ver=1.6.8.1"></noscript>Es decir, así:
<link rel="preload" as="style" id="style-css" href="styles.css" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>Esto se logra colocando el siguiente script en el archivo del plugin de funciones personales o en el archivo functions.php del tema secundario:
add_filter( 'style_loader_tag', 'brigzen_defer_styles', 10, 3 );
function brigzen_defer_styles( $tag, $handle, $src ) {
$defer_styles = array(
'wpforms-full'
);
if ( in_array( $handle, $defer_styles ) ) {
return '<link rel="preload" as="style" id="' . $handle . '" href="' . $src . '" media="all" onload="this.onload=null;this.rel=\'stylesheet\'"><noscript><link rel="stylesheet" href="' . $src . '"></noscript>' . "\n";
}
return $tag;
}Este script y lo que implica lo he explicado en al artículo Diferir los scripts en WordPress, solo que aquí lo he adaptado para que me funcione con los estilos.
Ahora de nuevo deberíamos tener otra mejora en las métricas de PSI y otro estilo menos que bloquea el renderizado. Solo nos queda uno, pero ya de lejos es el menor de los requerimientos.
El CSS del tema
El asunto del CSS crítico del tema es algo complicado y es la piedra de tranca de todo aquel que ve infructuoso los intentos por optimizar su sitio web.
Para el sitio web que estoy usando como ejemplo, businet.brigzen.com, esta optimización es algo fácil porque es de una sola página.
Lo que se puede hacer
En mi caso es muy simple, puedo extraer el CSS crítico con la ayuda de DevTool de Chrome, algo parecido a como hice con las FontAwesome, que se explica mejor en el artículo Eliminar los Recursos que Bloquean el Renderizado de Web.dev.
Esa extracción es a mano, copio el style.css completo en un archivo y voy borrando los códigos CSS que están en rojo hasta quedar solo con los que están marcados en azul. ¡Arcaico ¿verdad?!
Luego ese archivo lo minimizo con la ayuda de alguna herramienta online y lo incorporo inline en el head de la web.
Finalmente difiero el archivo de estilos como hice con la del formulario de contacto y, si es posible, aunque no del todo necesario, borro las instrucciones CSS que ya están en inline (Google me lo agradecería).
De esta manera podríamos llegar a un punto en el que se trabaje con dos hojas de estilos si se desea editar.
Pero no es la práctica correcta
El CSS va a variar dependiendo el tipo de página que se esté cargando; sea la home, una página, un artículo, la página de categorías, la página de blog, la página de autor, la página de resultados de búsquedas, páginas silos, etc. Entonces así se embrolla bastante.
Se puede incorporar en un solo archivo el CSS crítico de toda la web y PSI quizás no de mucha lata ya que el código CSS que encontremos particular para la página de categorías no diferirá mucho del CSS crítico de la página de artículo.
Lo que he hecho en alguna oportunidad es utilizar el CSS crítico de la home, páginas y artículos solamente; y me ha bastado para pasar las métricas PSI.
Otra propuesta
Podría ser, aunque no lo he intentado, que apliquemos filtros para cargar el CSS específico a cada página usando el script que se usó para con la hoja de estilos del formulario de contacto.
// Deregistrar estilos CSS de Contact Form 7 en las páginas sin formulario
function brigzen_deregister_styles() {
if ( ! is_page( 'contacto', 'contacto-2', 'contacto-3' ) {
wp_dequeue_style( 'wpforms-full' );
}
}
add_action( 'wp_print_styles', 'brigzen_deregister_styles', 100 );Solamente que tendríamos que buscar la manera de que el slug sea del tipo …/blog/* (lo que sea) para los artículos. Pero esto haría que tuviésemos que trabajar con tanta multitud de archivos de estilos como tipos de páginas haya.
La solución correcta
La verdadera solución a la extracción del CSS crítico de un sitio web, su incorporación inline en el head de la página y el posterior aplazamiento de la hoja de estilo original es en el servidor.
Por eso mencionaba al principio de este artículo que la optimización Web no era algo que se debía resolver luego de tener el sitio web terminado. Esto es algo que se debe tomar en cuenta desde el mismísimo servidor.
Por ello la frustración de algunos en intentar lograr satisfacer al implacable PageSpeed Insight.
El CSS crítico es algo que debe producirse automáticamente tal como hicieron con los CSS críticos de los bloques de WordPress 5.8.
Del lado servidor han surgido desarrollos a modo de módulos Node.js como CriticalCSS o módulos Apache como mod_pagespeed para automatizar la extracción del CSS crítico y colocarlo inline. Para el caso de WordPress, que está basado en PHP, la propuesta de mod_pagespeed es la más acertada. Solo que los hosting lo han negado porque su uso involucra un consumo significativo del CPU.
Pienso que los hosting deberían pillar estas cosas porque si yo trabajara con una sola web creo que preferiría hospedarla en un servidor local y servir mis códigos vía CDN.
Estoy convencido de que en algún momento el mismo core de WordPress incorporará la capacidad para servir el CSS crítico inline y aplazar la hoja de estilo del tema. A todas estas es una cosa más que se supone debe hacer un gestor de contenidos.
Para finalizar esta parte, yo he optado por la primera solución que propuse, la idea es sacar el CSS y colocarlo inline. Pero sabiendo que no es la manera correcta y teniendo cuidado con las media queries para los tamaños de pantallas, es decir, no borrar los enunciados tipo @media (max-width: 921px) {}, así la herramienta los marque en rojo, solo borrar las instrucciones CSS internas.
Resultados
Si has logrado implementar alguna solución, la métrica de PSI puede que mejore algo más, pero quizás nada significativo. Lo que sí debe ocurrir es que ya no veas recursos que bloqueen el renderizado.
Nos está empezando a aparecer algo sobre minimización de los recursos de Javascript pero ya iremos a ello. Voy a ver a ahora lo de las benditas imágenes para darle un empujón a esa métrica de PSI hasta los 100 puntos.
Optimización de las imágenes
Todos los requerimientos que se solicitan en PSI asociados a las imágenes emergen porque las imágenes que se han usado no han sido optimizadas correctamente.
Para que una imagen esté optimizada debe, para empezar, ser del tamaño justo del que se está usando en la web; estar en formato de nueva generación como JPEG 2000, JPEG XR o WebP; y estar comprimida correctamente, lo que PSI se refiere a correctamente codificada.
Este paso es muy sencillo, cumpliré los tres requerimientos optimizando las imágenes.
Esto se resuelve adaptando el tamaño de las imágenes al tamaño en que son presentadas, por lo menos, en el modo desktop y, si es posible, un poquito más para los temas de pantallas retinas.
Una de las imágenes que estaba dando problemas es esta.
En esta imagen el problema es que estaba siendo presentada en un tamaño más grande del que realmente es, no estaba comprimida y estaba en formato jpeg. Lo que hice fue modificar el código del html para que presentara la imagen en el tamaño propio de la imagen, luego la trabajé con GIMP para convertirla de jpeg a WebP; finalmente la pasé por mi compresor online favorito.
Entonces terminó pasando de de ser una imagen jpeg no comprimida y ensanchada a una imagen en formato WebP, comprimida y en su tamaño correcto.
La otra imagen era el logo de la página.
En este caso solo la pasé por el compresor ya mencionado dejándola en formato png y en su mismo tamaño. De hecho, por ser el logo, me permito cargar una imagen más grande de como va a ser representada por esto del tema de pantallas retinas. Tampoco me siento seguro todavía de colocar una imagen WebP como logo.
La última imagen era esta.
Es una imagen jpeg que aborda todo el ancho de la pantalla, pero su ancho era de 2400px. La he modificado a 2000px de ancho, suficiente para pantallas 1900, la convertí a WebP y la pase por el compresor.
Algunas notas
El CSM WordPress a partir de su muy reciente versión 5.8 ha pasado a ser compatible con los formatos de imágenes WebP, no obstante ya desde antes se podrían haber usado subiéndolas por FTP.
Cuando trabajes con imágenes y no tengas los respaldos a la mano como me pasa a mi y vas a usar las que están en el servidor, entonces asegúrate de usar las originales y no las que crea el mismo CSM a partir de las originales.
Estos procesos de optimización, al igual como he comentado con la automatización del CSS crítico, deberían ser gestionados por el mismo gestor de contenidos. Sigo insistiendo que para eso están. Por los momentos estos trabajos o son llevados a cabo por uno mismo o adquiriendo desarrollos no nativos del CSM como lo son los diferentes complementos para WordPress.
A precargar todo
Llegados aquí podríamos decir que empezamos una nueva etapa. La etapa de las precargas. Es donde se nos hace útil cosas como GT Metrix. Hasta el momento eso se ha adelantado con los archivos CSS y los archivos js.
En la figura de abajo puedes ver que algunos archivos de imágenes empiezan a cargarse más tarde que otros archivos. También algo parecido ocurre con las fuentes, la franja gris es un tiempo de espera por respuesta luego que se solicita.
Los archivos CSS los hemos diferido, pero los archivos js los hemos encontrado al final del body por haber seleccionado un tema algo optimizado. Aunque la verdadera optimización del Javascript pasa por colocar las referencias igualmente en la cabecera pero de forma diferida. Y el código JS que sea necesario para el renderizado colocarlo inline en la cabecera.
Si quisiera ser muy detallista con esta optimización entonces debería pasar esos códigos Javascript a la cabecera de la página y luego diferirlos, sería lo mismo porque ninguno de esos códigos se usa para el renderizado.
¿Pero qué ganaría con ello? Los estaría precargando en vez de que el explorador llegue al final del body para que luego se de cuenta de que necesita unos archivos JS, cosa que pudo haber hecho en paralelo.
Pero debido a que no nos está causando un problema mayor, porque, tal como lo veo, es casi imperceptible el tiempo que tarda el renderizado en llegar al final de la página. Los dejo así y precargo el resto. En este punto, con el resto me estoy refiriendo a fuentes e imágenes.
Para un mejor explicación sobre la precarga de fuentes e imágenes lee mi artículo sobre Precarga los recursos de una web. Luego de esa lectura regresa aquí a este punto.
Una vez que hemos terminado las precargas de lo que nos compete aquí, imágenes y fuentes, deberíamos tener algo así en nuestro head:
Ya a este punto no veo diferencia en las métricas PSI.
No obstante, ya no arroja errores relacionados con las imágenes.
Aun cuando no aprecio una diferencia marcada en los puntos de la métricas PSI, pasar de como estaba en la figura 26 a como se ve abajo es una optimización deseada.
Todas las imágenes y las fuentes comienzan la descarga en el primer lote (si se puede decir así). Luego creo que los scripts comienzan luego por precisamente el hecho de estar al final del body. Hay que entender que lo que ocurre aquí es que esas imágenes y archivos de fuentes se están empezando a descargar antes de que el explorador sepa que las necesita.
Pero si has sido detallista te habrás dado cuenta que el tiempo de respuesta del servidor en la figura 30 fue por mucho más rápida que en la figura 26. Esto ha ocurrido porque he montado la Web en el CDN Cloudflare.
Montar la Web en un CDN
El último paso de esta optimización web es el uso de una CDN. En este caso he usado CloudFlare, en su versión gratuita, pero he habilitado la carga completa con la ayuda del complemento WP Cloudflare Super Page Cache que se conecta vía API con CloudFlare.
La carga completa significa que el CDN va a cargar todas las páginas estáticas y las va a mantener en caché. De lo contrario solo te sirve imágenes y algunos archivos.
Esto mejora sumamente los tiempos de entrega y viéndose ahora sí una mejora significativa en las métricas de PSI.
No llegué a 100 como hubiese esperado. Creo que el detalle está en la separación del CSS crítico, por lo que tendría que ser más minucioso en detallar qué puede estar pasando. No obstante, insisto que es algo que se debe solucionar desde el servidor de forma automática.
Incluso he usado complementos como WP Rocket que no llegan a hacer todo lo que se supone que hagan.
Les agradezco los comentarios constructivos.