Cómo eliminar los recursos que bloquean el renderizado

Descubrir recursos críticos que bloquean el renderizado y repararlos puede mejorar significativamente su SEO Sigue leyendo para aprender.

Los recursos de bloqueo de procesamiento son una parte fundamental de la optimización de la infraestructura de su página web.

Reducirlos puede ayudar a que su página se cargue mucho más rápido y mejorar significativamente los Core Web Vitals de su página.

Estos recursos que bloquean el renderizado incluyen cosas como fuentes externas que tardan demasiado en cargarse (que no necesitan usarse), archivos multimedia innecesarios, código inflado que simplemente no desaparece y complementos adicionales que no son

Existe una gran variedad de estos tipos de recursos que puede comprimir y combinar para crear archivos únicos que se descargan más rápido en sus dispositivos, creando una velocidad de página mucho más rápida.

Al optimizar la estructura de su página en este asunto, puede reducir la cantidad de trabajo que Google tiene que hacer para rastrear su sitio y, como resultado, puede mejorar su experiencia de usuario.

De hecho, los beneficios completos de hacer este proceso incluyen:

• Velocidad de página más rápida.
• Menos recursos requeridos por Google para cargar su página.
• Reducción de los problemas causados ​​por el exceso de código.
• Tamaño de archivo general más pequeño de su DOM (modelo de objeto de documento).
• Menos archivos JavaScript y CSS para descargar.
• Implementación mejor y más rápida en una variedad de plataformas y dispositivos.
• Mejora de la interacción del usuario en el móvil.
• Rendimiento mejorado en general.

Claramente, existen enormes beneficios al realizar este tipo de proceso de optimización en su sitio.

¿Por qué debería identificar los recursos que bloquean el renderizado?

Identificar y reducir los recursos responsables de bloquear la representación de su página web es un punto crítico de optimización que puede aumentar o disminuir la velocidad de su página.

Puede ser tan crítico que puede pagar dividendos a las métricas de experiencia de la página de su sitio (y la satisfacción de su usuario) como resultado.

En 2021, el tiempo promedio que tomó renderizar completamente una página web móvil fue de 22 segundos En 2018, fueron 15 segundos. 22 seconds

Claramente, este es un número sustancialmente más alto que el tiempo recomendado por Google de dos a tres segundos. También es sustancialmente más alto de lo que solía ser.

¿Qué podría estar causando estos problemas con los recursos de bloqueo de procesamiento?

¿Qué está impulsando este aumento en la velocidad general de procesamiento de la página?

Una tendencia interesante a tener en cuenta es que ha habido una mayor dependencia de las fuentes de terceros en comparación con las fuentes del sistema. El uso de fuentes de terceros como recurso tiende a interferir con el procesamiento y la representación de una página. increasing reliance on third-party fonts

Con las fuentes del sistema, el navegador no tiene que cargar nada adicional, por lo que no tiene como resultado ese paso de procesamiento adicional.

Es probable que esta dependencia entre industrias afecte este tiempo de renderizado Por supuesto, esta no es la única causa de este problema con los recursos de bloqueo de procesamiento.

Además, los propios servicios de Google tienden a tener un impacto significativo en el tiempo de procesamiento, como Google Analytics o el uso de un píxel de Facebook de terceros con fines de seguimiento.

El deseo de confiar en tales tecnologías no es necesariamente terrible desde una perspectiva de marketing.

Pero desde la perspectiva de los recursos de bloqueo de procesamiento, puede causar aumentos significativos en el tiempo de carga de la página y en cómo Google (y los usuarios) perciben su página.

La solución ideal es asegurarse de que su página se cargue para la interacción del usuario lo más rápido posible.

También existe la posibilidad de que las malas prácticas de desarrollo web que utilizan los desarrolladores web en la actualidad sean las culpables.

De cualquier manera, esto es algo en cada proyecto de sitio web que debe abordarse como parte de sus auditorías Core Web Vitals.

Sin embargo, la experiencia de la página no se trata solo de qué tan rápido se carga toda la página.

En cambio, se trata más de la experiencia general de la página medida por el marco de experiencia de la página de Google o Core Web Vitals.

Esta es la razón por la que desea trabajar para mejorar y optimizar la velocidad de su página para la ruta de representación crítica en todo el DOM o modelo de objeto de documento.

¿Qué es la ruta de representación crítica?

La ruta de representación crítica se refiere a todos los pasos necesarios para representar la página completa, desde que el navegador comienza a recibir datos por primera vez hasta que finalmente compila la página en la representación final.

Este es un proceso que puede tomar solo varios milisegundos si lo optimiza correctamente.

Optimizar para la ruta de renderizado crítica significa asegurarse de optimizar el rendimiento del renderizado en muchos dispositivos diferentes.

Esto se logra mediante la optimización de la ruta de renderizado crítica para llegar a su primera pintura lo más rápido posible.

Básicamente, está reduciendo la cantidad de tiempo que los usuarios pasan mirando una pantalla blanca en blanco para mostrar contenido visual lo antes posible (consulte 0.0s a continuación).

Hay todo un proceso sobre cómo hacer esto, descrito en la documentación de la guía para desarrolladores de Google, pero me centraré en un bateador pesado en particular: reducir los recursos de bloqueo de procesamiento. Google’s developer guide documentation

¿Cómo funciona la ruta de representación crítica?

La ruta de representación crítica se refiere a la serie de pasos que toma un navegador en su viaje para representar una página al convertir HTML, CSS y JavaScript en píxeles reales en la pantalla.

Esencialmente, el navegador necesita solicitar, recibir y analizar todos los archivos HTML y CSS (además de algún trabajo adicional) antes de comenzar a mostrar cualquier contenido visual. plus some additional work

Este proceso ocurre en una fracción de segundo (en la mayoría de los casos) Los usuarios verán una página en blanco en blanco hasta que el navegador complete estos pasos.

El siguiente es un ejemplo de cómo los usuarios pueden experimentar cómo se carga una página según las diferentes etapas del proceso de carga de la página:

Mejorar la ruta de representación crítica puede mejorar la experiencia general de la página, lo que puede ayudar a mejorar el rendimiento en las métricas de Core Web Vitals.

¿Cómo optimizo la ruta de representación crítica?

Para mejorar la ruta de representación crítica, debe analizar sus recursos de bloqueo de representación.

Cualquier recurso que bloquee el procesamiento puede terminar bloqueando el procesamiento inicial de la página y, como resultado, afectar negativamente sus puntajes de Core Web Vitals.

Esto implica un proceso de optimización de:

• Reducir la cantidad de recursos que son críticos para la ruta de renderizado Esto se puede hacer usando un método diferido para cualquier posible recurso de bloqueo de procesamiento.
• Priorizar el contenido que está en la mitad superior de la página y descargar recursos multimedia importantes lo antes posible.
• Comprima el tamaño de archivo de los recursos críticos restantes.

Al hacer esto, es posible mejorar tanto Core Web Vitals como la forma en que su página se muestra físicamente al usuario.

Antes de analizar las técnicas de optimización que puede utilizar para optimizar la ruta de representación crítica, es importante analizar el proceso de carga inicial del navegador y por qué la ruta de representación crítica es tan importante.

Y este proceso implica:

• Precargando elementos de página.
• Alineación de estilos críticos.
• Aplazamiento de la carga de archivos JavaScript.
• Primeros indicios.

Precargar elementos de página

Primero, cuando el navegador recupera la página del servidor, el navegador escaneará inicialmente y encontrará todos los elementos de la página para descargar. De forma predeterminada, esto sucede en un proceso en el que el navegador descarga todos los elementos simultáneamente.

Pero, ¿qué sucede cuando tiene muchos elementos de página para descargar (como lo que sucede con frecuencia con un sitio web de WordPress?) Bueno, esto puede atascar los recursos del servidor, lo que aumenta aún más el tiempo de carga de la página.

¿Cómo resuelves esto?

La precarga de elementos es una técnica que ayuda a eliminar las hojas de estilo que bloquean el renderizado porque carga archivos críticos necesarios para la primera etapa de pintura del proceso antes de cargar todos los demás archivos.

Puede precargar CSS, JS, fuentes o imágenes Aquí hay ejemplos de cómo precargarlos:

Precarga de JavaScript

<link rel="preload" as="script" href="critical.js">

Precarga de CSS

<link rel="preload" href="style.css" as="style" />

Precarga de fuentes

<link rel="preload" href="fonts/webfont.woff2" as="font" type="font/woff2" crossorigin />

Precarga de imágenes

<link rel=preload href="cat.png" as=image imagesrcset="cat.png 1x, cat-2x.png 2x">

Esto ayuda a acelerar el proceso de la página. Sin embargo, este no es un método ideal.

El método ideal es optimizar el sitio para usar solo dos o tres complementos, tal vez otros dos o tres archivos, y mantener las cosas al mínimo para la representación de la página completa.

Lamentablemente, este no es un esfuerzo realista a seguir.

Debido a que los sitios de WordPress tienden a tener muchos complementos y recursos con los que los desarrolladores simplemente no están dispuestos (o no quieren) lidiar, el camino más fácil hacia el éxito es trabajar para asegurarse de que estos recursos estén optimizados correctamente mediante el uso de ciertos complementos.

Inserción de estilos críticos

Critical CSS es una técnica que extrae el CSS del contenido de la mitad superior de la página para mostrar el contenido al usuario lo más rápido posible. extracts the CSS

Como mínimo, esto generalmente requiere:

• Cualquier declaración de fuente.
• Cualquier CSS específico del diseño.
• Todas las reglas de estilo CSS para los elementos DOM (modelo de objeto de documento) de la mitad superior de la página.

Usando nuestro ejemplo anterior de la página que carga todos los recursos simultáneamente, los estilos críticos integrados implican el uso de código dentro de la etiqueta HTML .

Si comprueba, por ejemplo, el código fuente de google.com, verá que está integrado con CSS crítico en la sección del HTML.

Hay varias herramientas que pueden ayudar a extraer CSS crítico.

• Criticalcss.com.
• Crítico.
• Complemento HTML Critical Webpack.

Aplazamiento de la carga de archivos JavaScript

Al usar este método, es posible diferir la carga de archivos JavaScript hasta que se carguen otros elementos críticos del árbol DOM. Sin embargo, esto viene con algunas advertencias.

Ejemplo de cómo diferir el archivo JavaScript:

<script defer src="script.js"></script>

El número uno es que puede afectar negativamente la apariencia del sitio al diferir la carga de archivos JavaScript porque algunos de estos podrían ser elementos necesarios para que la página se cargue por completo.

El número dos es que, si no tiene cuidado, al aplazar la carga de archivos JavaScript, podría introducir problemas con la interactividad de la página (interacción con la siguiente métrica Paint Core Web Vitals).

El número tres es que también puede presentar problemas con el funcionamiento general del sitio.

La idea es que debe tener cuidado cuando trabaja en este tipo de optimizaciones, para no causar problemas sin darse cuenta en otras partes del proceso.

Al hacerlo, puede tener un gran impacto en la velocidad de su página y en cómo Google ve su sitio.

Sin embargo, la otra preocupación es cuando usa complementos como Nitro para diferir archivos críticos como CSS y JavaScript.

Si bien esto puede tener un impacto positivo en la velocidad de la página, el principal problema es que el complemento difiere todos los archivos CRÍTICOS hasta que la página haya cargado la parte HTML del documento.

¿Qué significa esto? Esto es similar a bloquear sus archivos CSS y JavaScript usando robots.txt, que Google necesita para determinar si su sitio es compatible con dispositivos móviles.

La página oficial de desarrolladores de Google dice esto, como se menciona en otra parte:

“For optimal rendering and indexing, always allow Googlebot access to the JavaScript, CSS, and image files used by your website so that Googlebot can see your site like an average user.

If your site’s robots.txt file disallows crawling of these assets, it directly harms how well our algorithms render and index your content. This can result in suboptimal rankings.”

“Para una representación e indexación óptimas, siempre permita que Googlebot acceda a los archivos JavaScript, CSS y de imágenes utilizados por su sitio web para que Googlebot pueda ver su sitio como un usuario promedio.

Si el archivo robots.txt de su sitio no permite el rastreo de estos activos, perjudica directamente la calidad de procesamiento e indexación de su contenido por parte de nuestros algoritmos. Esto puede resultar en clasificaciones subóptimas”.

Si está aplazando archivos CSS y JavaScript críticos por razones de SEO, siempre que se asegure de que Google pueda ver estos archivos en la carga de la página, no debería tener problemas importantes con la forma en que Google puede ver su sitio.

Uso de sugerencias tempranas para una mejor optimización del servidor

Antes de que podamos hablar sobre los primeros consejos, debemos analizar el proceso de cómo el servidor carga una página web. De hecho, los sitios se han vuelto más sofisticados en los últimos años.

Y así, también lo han hecho los servidores. Pero, hay limitaciones Aunque los servidores pueden y realizan tareas triviales durante todo el día, aún es posible que un servidor se atasque al trabajar para pensar demasiado en cómo maneja los recursos de un sitio.

Entonces, cuando esto sucede, se produce una latencia adicional a la que se experimentaría de otra manera, y esto sucede antes de que el navegador pueda comenzar a mostrar la página.

Cuando se produce esta latencia, puede encontrarse con situaciones en las que un sitio puede tardar un par de segundos antes de aparecer en la ventana del navegador.

Y asegurarse de que su servidor reproduzca los archivos correctamente es un excelente primer paso para aumentar la velocidad de su página.

Aquí hay un ejemplo de lo que sucede cuando su servidor no responde correctamente y tarda demasiado en procesar ciertos recursos:

Entonces, ¿cómo funcionan las sugerencias tempranas?

De acuerdo con la guía para desarrolladores de Google Chrome, «las primeras sugerencias son un código de estado HTTP (103 Early Hints) que se utiliza para enviar una respuesta HTTP preliminar precisa antes de una respuesta final». Google Chrome Developer guide

¿Qué logra esto?

Esto permite que un servidor proporcione ciertos tipos de sugerencias a un navegador para ciertos recursos críticos (archivos de JavaScript, hojas de estilo CSS y más) que es probable que la página web cargue y use.

Este proceso ocurre en el lapso de unos pocos milisegundos o menos mientras el servidor trabaja en la representación de los recursos de la página principal.

Las sugerencias tempranas son algo que «ayuda a un navegador» y acelera el tiempo de reflexión del servidor al trabajar en esta carga por adelantado.

Debido a esto, este proceso ayuda a acelerar el tiempo de carga de la página como resultado.

Herramientas para ayudarlo a optimizar su ruta de renderizado crítica

¿No eres un maestro del código extraordinario y no puedes trabajar y optimizar el código, los complementos y las cosas debajo del capó de tu sitio web?

Bueno, nunca temas (¡demasiado!) Hay complementos de WordPress disponibles que pueden ayudarlo a hacer precisamente eso.

A continuación se incluye una lista de herramientas que puede utilizar para ayudar a optimizar su propia ruta de representación crítica para el éxito:

• Complemento CSS crítico: esta práctica herramienta le permite generar CSS crítico que su sitio necesita Simplemente agregue su URL, haga clic en generar y listo.
• Complemento de velocidad de página de optimización automática: este complemento en particular es otro complemento de velocidad de página que también le permite diferir archivos críticos Además, ayuda a inyectar CSS en línea en el encabezado de la página, transfiere los scripts al pie de página y minimiza los archivos HTML.
• Complemento de velocidad de página de WP Rocket: este complemento de velocidad de página es uno de los complementos de almacenamiento en caché más potentes Después de la instalación, este complemento en particular le permite aprovechar el almacenamiento en caché de la página, la compresión GZIP, la carga previa del caché y el almacenamiento en caché del navegador.
• WP-Optimize: este es un complemento de WordPress que le permite hacer varias cosas para ayudar a optimizar mejor su sitio para tiempos de carga rápidos Incluyen la optimización de su base de datos, la compresión de sus imágenes y el almacenamiento en caché de sus páginas, además de minimizar y sincronizar sus archivos CSS y JavaScript.

Tenga en cuenta: este autor no tiene prejuicios financieros con ninguna de estas herramientas.

¿Por qué debería importarme?

Los datos de comportamiento del usuario de Google informan que la mayoría de los usuarios abandonan un sitio lento después de unos tres segundos.

Además de los estudios que muestran que reducir el tiempo de carga de la página y mejorar la experiencia de la página conduce a una mayor satisfacción del usuario, también hay varias actualizaciones importantes de Google en el horizonte para las que querrá prepararse.

Identificar y optimizar los recursos que bloquean el procesamiento será fundamental para mantenerse al tanto del juego cuando lleguen estas actualizaciones.

Google implementará la experiencia de página en el escritorio en 2022, comenzando su implementación de la experiencia de página de escritorio en febrero y terminando en marzo. page experience on the desktop in 2022

Según Google, las mismas tres métricas de Core Web Vitals (LCP, FID y CLS), junto con sus umbrales asociados, ahora estarán vinculadas a la clasificación de escritorio.

Además, Google está trabajando en una nueva métrica Core Web Vitals, posiblemente experimental, que tiene en cuenta la duración máxima del evento y la duración total del evento. working on

Su explicación de estos factores que están considerando son:

Maximum event duration: the interaction latency is equal to the largest single event duration from any event in the interaction group.
Total event duration: the interaction latency is the sum of all event durations, ignoring any overlap.

Duración máxima del evento: la latencia de la interacción es igual a la mayor duración del evento individual de cualquier evento en el grupo de interacción. Duración total del evento: la latencia de la interacción es la suma de todas las duraciones de los eventos, ignorando cualquier superposición.

Con muchos estudios que relacionan las reducciones en los tiempos de carga de la página con las mejoras en los valiosos KPI (conversiones, tasa de rebote, tiempo en el sitio), mejorar la latencia del sitio se ha convertido en un objetivo comercial prioritario para muchas organizaciones. many studies

Los profesionales de SEO están en una posición única para guiar este esfuerzo, ya que nuestro papel suele ser cerrar la brecha entre los objetivos comerciales y las prioridades de los desarrolladores web.

Tener la capacidad de auditar un sitio, analizar resultados e identificar áreas de mejora nos ayuda a trabajar con los desarrolladores para mejorar el rendimiento y trasladar los resultados a las partes interesadas clave.

Los objetivos de optimizar los recursos de bloqueo de procesamiento

Uno de los objetivos principales de optimizar la ruta de representación crítica es asegurarse de que los recursos que se necesitan para representar ese contenido importante de la mitad superior de la página se carguen tan rápido como sea humanamente posible.

Cualquier recurso que bloquee el renderizado debe perder prioridad y cualquier recurso que impida que la página se renderice rápidamente.

Cada punto de optimización contribuirá a la mejora general de la velocidad de la página, la experiencia de la página y las puntuaciones de Core Web Vitals.

¿Por qué mejorar el CSS de bloqueo de procesamiento?

Google ha dicho muchas veces que la codificación no es necesariamente importante para la clasificación.

Pero, de la misma manera, obtener un beneficio de clasificación de las mejoras de optimización de la velocidad de la página puede ayudar potencialmente, según la consulta.

Cuando se trata de archivos CSS, se consideran recursos que bloquean el renderizado.

¿Por qué es esto?

Aunque sucede en un milisegundo o menos (en la mayoría de los casos), el navegador no comenzará a mostrar ningún contenido de la página hasta que pueda solicitar, recibir y manejar todos los estilos CSS.

Si un navegador muestra contenido que no tiene el estilo adecuado, todo lo que obtendrá es un montón de texto normal y enlaces que ni siquiera tienen el estilo.

Esto significa que su página básicamente estará «desnuda», a falta de un término mejor.

Eliminar los estilos CSS dará como resultado una página que es literalmente inutilizable.

Será necesario volver a pintar la mayoría del contenido para que parezca un poco aceptable para un usuario.

Si examinamos el proceso de representación de la página, el cuadro gris a continuación representa el tiempo de navegación necesario para obtener todos los recursos CSS De esta manera, puede comenzar a construir el DOM de CSS (o árbol CCSOM).

Esto podría tomar desde un milisegundo hasta varios segundos, dependiendo de lo que su servidor necesite hacer para cargar estos recursos.

También puede variar, lo que podría depender del tamaño, junto con la cantidad, de estos archivos CSS.

El siguiente árbol de representación muestra un ejemplo de un navegador que muestra todos los archivos junto con CSS dentro del DOM:

Además, a continuación se muestra un ejemplo de la secuencia de renderizado de una página, en la que todos los archivos se cargan en un proceso, desde la construcción del DOM hasta el pintado y composición final de la página, lo que se conoce como ruta crítica de renderizado.

Debido a que CSS es un recurso que bloquea el renderizado de manera predeterminada, tiene sentido mejorar el CSS hasta el punto en que no afecte negativamente el proceso de renderizado de la página.

La recomendación oficial de Google establece lo siguiente: Google recommendation states

“CSS is a render-blocking resource. Get it to the client as soon and as quickly as possible to optimize the time to first render.”

“CSS es un recurso de bloqueo de procesamiento Entrégueselo al cliente lo antes y lo más rápido posible para optimizar el tiempo de renderizado inicial”.

El HTML debe convertirse en algo con lo que el navegador pueda trabajar: el DOM Los archivos CSS son de la misma manera Esto debe convertirse en el CSSOM.

Al optimizar los archivos CSS dentro del DOM y CSSOM, puede ayudar a reducir el tiempo que tarda un navegador en procesar todo, lo que contribuye en gran medida a una experiencia de página mejorada.

¿Por qué mejorar el JavaScript que bloquea el renderizado?

¿Sabías que no siempre es necesario cargar JavaScript?

Con JavaScript, descargar y analizar todos los recursos de JavaScript no es un paso necesario para representar completamente una página.

Por lo tanto, esto no es realmente una parte técnicamente necesaria del procesamiento de la página.

Pero la advertencia a esto es: la mayoría de los sitios modernos están codificados de tal manera que se requiere JavaScript (por ejemplo, el marco Bootstrap JS) para representar la experiencia de la parte superior de la página.

Pero si un navegador encuentra archivos JavaScript antes de la primera representación de una página, el proceso de representación se puede detener hasta más tarde y después de que los archivos JavaScript se hayan ejecutado por completo.

Esto se puede especificar de otra manera aplazando los archivos de JavaScript para su uso posterior.

Un ejemplo de esto es si hay funciones JS como una alerta integrada en el HTML Esto podría detener la representación de la página hasta después de la ejecución de este código JavaScript.

JavaScript tiene el poder exclusivo de modificar los estilos HTML y CSS, por lo que tiene sentido.

El análisis y la ejecución de JavaScript podrían retrasarse debido al hecho de que JavaScript puede cambiar potencialmente todo el contenido de la página. Este retraso está integrado en el navegador de forma predeterminada, solo para un escenario «por si acaso».

Recomendación oficial de Google: Official Google recommendation

“JavaScript can also block DOM construction and delay when the page is rendered. To deliver optimal performance … eliminate any unnecessary JavaScript from the critical rendering path.”

“JavaScript también puede bloquear la construcción de DOM y retrasar cuando se procesa la página Para ofrecer un rendimiento óptimo… elimine cualquier JavaScript innecesario de la ruta de representación crítica».

Cómo identificar los recursos que bloquean el renderizado

Para identificar la ruta de representación crítica y analizar los recursos críticos:

• Ejecute una prueba usando webpagetest.org y haga clic en la imagen de la «cascada».
• Concéntrese en todos los recursos solicitados y descargados antes de la línea verde «Iniciar procesamiento».

Analice su vista de cascada;

Después de identificar un recurso que bloquea (potencialmente) el procesamiento, pruebe a eliminarlo para ver si el contenido de la mitad superior de la página se ve afectado.

En mi ejemplo, noté algunas solicitudes de JavaScript que pueden ser críticas.

Aunque son críticos, a veces es una buena idea probar la eliminación de estos scripts para probar cómo los elementos cambiantes en el sitio afectan la experiencia.

También hay otras formas de mejorar dichos recursos.

Para los archivos JavaScript no críticos, es posible que desee combinar los archivos y diferirlos al incluir estos archivos en la parte inferior de su página.

Para archivos CSS no críticos, también puede reducir la cantidad de archivos CSS que tiene combinándolos en un solo archivo y comprimiéndolos.

Mejorar sus técnicas de codificación también puede resultar en un archivo que se descarga más rápido y causa menos impacto en la velocidad de representación de su página.

Cómo reducir los elementos que bloquean el renderizado en la página

Una vez que determine que un recurso de bloqueo de representación no es crítico para mostrar contenido en la mitad superior de la página, querrá explorar una gran cantidad de métodos disponibles para mejorar la representación de su página y diferir los recursos no críticos.

Hay muchas soluciones a este problema, desde aplazar archivos JavaScript y CSS hasta reducir el impacto que puede tener CSS.

Una posible solución es no agregar CSS usando la regla @import.

Asegúrese de no agregar CSS usando la regla @Import

Desde una perspectiva de rendimiento, aunque @import parece mantener su archivo HTML más limpio, en realidad puede crear problemas de rendimiento.

La declaración @import en realidad hará que el navegador procese un archivo CSS más lentamente ¿Por qué?

La representación se bloqueará por completo hasta que se complete el proceso.

De hecho, la mejor solución es usar el método estándar de incluir una hoja de estilo CSS usando la declaración en el HTML.

Minimice sus archivos CSS y JavaScript

Si está en WordPress, usar un complemento para minimizar sus archivos CSS y JavaScript puede tener un impacto tremendo.

El proceso de minificación toma todos los espacios innecesarios dentro de un archivo y los comprime aún más, por lo que puede terminar con un buen aumento de rendimiento.

Además, incluso si no está en WordPress, puede utilizar los servicios de un desarrollador bien calificado para completar el proceso manualmente.

Esto llevará más tiempo, pero puede valer la pena.

Los archivos minificados suelen ser mucho más ligeros que sus homólogos anteriores, lo que significa que la renderización inicial se completará mucho más rápido.

Además de esto, después del proceso de minificación, también puede esperar que el proceso de descarga sea más rápido porque se necesita menos tiempo para descargar recursos de bloqueo que no son de procesamiento.

Use fuentes del sistema en lugar de fuentes de terceros

Si bien las fuentes de terceros pueden parecer que hacen que un sitio sea «más bonito», este no es exactamente el caso.

Si bien puede parecer sorprendente en la superficie, estos archivos de fuentes de terceros a menudo tardan más en cargarse y pueden contribuir a su problema de recursos de bloqueo de procesamiento.

Debido a los archivos externos, el navegador tiene que realizar solicitudes externas para descargar estos archivos para mostrar su página, lo que puede resultar en tiempos de descarga significativamente más altos.

Si está en un equipo que tiene mejores prácticas de desarrollo menos que ideales, entonces podría ser lógico que tenga muchos archivos de fuentes de terceros que no son necesarios para renderizar su sitio.

En este caso, eliminar todos estos archivos innecesarios puede mejorar significativamente sus recursos de bloqueo de procesamiento y contribuir a su mejora general en Core Web Vitals.

El uso de fuentes del sistema, por otro lado, solo mantiene el procesamiento dentro del navegador sin solicitudes externas.

Además, es probable que haya fuentes del sistema que sean muy similares a las fuentes de terceros que utiliza.

Sin embargo, si es absolutamente necesario usar fuentes de terceros, hay dos cosas que debe hacer para ayudar a mitigar los problemas con ciertos aspectos de las fuentes de terceros.

En primer lugar, si se usan junto con la precarga y el intercambio de fuentes, los problemas con las fuentes de terceros dejan de ser un problema. font-swap

El otro problema cuando se usan fuentes de terceros es que las fuentes son invisibles hasta que se carga la fuente misma, lo que afecta negativamente a Core Web Vitals y la experiencia del usuario. Para evitar esto, puede usar CSS de intercambio de fuentes. font-swap CSS

Así es como funciona: el CSS de intercambio de fuentes le explica al navegador que el texto que usa una fuente en particular debe mostrarse inmediatamente usando una fuente del sistema Una vez que la fuente personalizada esté lista, esta fuente personalizada reemplazará la fuente del sistema Este es el método más efectivo que puede usar para evitar fuentes invisibles durante la carga de la página.

The New Kid On The Block: fuentes variables

A partir de 2020, las fuentes variables se han vuelto ampliamente compatibles con la mayoría de los navegadores ¿Qué son exactamente las fuentes variables?

Con fuentes variables, todos sus estilos de fuente están contenidos en un solo archivo Pero antes de que las fuentes variables se convirtieran en algo común, necesitaría varios archivos de fuentes independientes para las fuentes.

También hay varios beneficios al usar fuentes variables, que incluyen:

• Tamaño de archivo más pequeño: las fuentes variables tienen un tamaño de archivo más pequeño porque son un archivo de una sola fuente que contiene todas las variaciones de ancho, peso y otros atributos.
• Una gama de diseño más flexible: Con otros tipos de fuentes, se necesitan de tres a cinco archivos de fuentes diferentes para proporcionar cada representación individual del lenguaje/voz de diseño de un sitio. Y esto incluye cada permutación de encabezados, texto del cuerpo, etc. Pero con las fuentes variables, el uso de un solo archivo de fuente le permite utilizar todas las variaciones posibles que podrían estar asociadas con el diseño de una fuente.
• Menos y solo un archivo: debido a este ahorro de tamaño de archivo, esto ayuda a comprimir aún más el tamaño de su página y disminuye la velocidad de su página Y el beneficio de archivo único en sí mismo le permite al webmaster comprimir aún más la velocidad de su página.

La siguiente documentación habla sobre las fuentes variables y cómo implementarlas. Debido a sus beneficios, el uso de fuentes variables es una alternativa aceptable si es absolutamente necesario implementar fuentes de terceros. variable fonts

Mejore sus técnicas de codificación y combinación de archivos

Si usted mismo está trabajando con el código, puede (o no puede… nadie está juzgando aquí) encontrar que las técnicas son menos que óptimas.

Un ejemplo: está utilizando CSS en línea en todas partes, y esto está causando fallas en el procesamiento y la representación dentro del navegador.

La solución fácil es asegurarse de tomar todo el CSS en línea y codificarlo correctamente dentro del archivo de hoja de estilo CSS.

Si el código de otro desarrollador no está a la altura, esto puede crear problemas importantes con la representación de la página.

Por ejemplo: supongamos que tiene una página que está codificada con técnicas más antiguas en lugar de modernas y más sencillas.

Las técnicas más antiguas podrían incluir una gran cantidad de código y dar como resultado una representación más lenta de la página.

Para eliminar esto, puede mejorar sus técnicas de codificación mediante la creación de un código más ágil y menos inflado, lo que da como resultado una experiencia de representación de página mucho mejor.

La combinación de archivos también puede mejorar la situación

Por ejemplo: si tiene ocho o diez archivos JavaScript que contribuyen a la misma tarea, puede contratar a un desarrollador que pueda combinar todos estos archivos por usted.

Y si son archivos JavaScript menos críticos, para disminuir aún más los problemas de representación de la página, estos archivos también se pueden diferir agregándolos al final del código HTML en la página.

Al combinar archivos y mejorar sus técnicas de codificación, puede contribuir significativamente a mejores experiencias de representación de páginas.

Conclusiones clave

Si desea crear su propio proceso para encontrar y reducir los recursos que bloquean el renderizado, ahora tiene las herramientas para hacerlo. El proceso se describe de la siguiente manera:

• Paso 1: rastrea tu sitio usando Screaming Frog u otras herramientas de rastreo.
• Paso 2: identifique las páginas con una velocidad de página lenta.
• Paso 2a: también puede usar Google Search Console o Google Analytics para este propósito.
• Paso 3: ordena las páginas con el rendimiento más bajo que encuentres en una lista priorizada.
• Paso 4: Vaya a los elementos de la lista de verificación anteriores (también puede crear una hoja de cálculo de cada elemento por página si lo prefiere) y busque, reduzca o repare estos recursos que bloquean el renderizado según sea necesario.
• Paso 5: Enjuague y repita para cada página de su sitio.

La idea es crear un proceso que sea fácilmente escalable, fácil de implementar y que pueda ponerlo en el camino hacia el éxito con una velocidad de página mucho menor como resultado.

Con este proceso, usted también puede beneficiarse de la ventaja que tendrá, y también podría experimentar un impulso de Core Web Vitals de Google.

Identificar y reparar los recursos que bloquean el renderizado es una parte fundamental de la optimización de la velocidad que la mayoría de las auditorías incluyen en este paso. El razonamiento detrás de esto es que ayudan a crear los mejores tiempos de renderizado posibles para sus páginas de clasificación.

Google está trabajando para mejorar la velocidad de la página todo el tiempo Pero hay una cosa que siempre ha sido constante: cuanto más rápida sea la velocidad de tu página, mejor.

Al integrar un proceso escalable donde puede lograr esto rápidamente, es posible abordar incluso los proyectos de optimización de velocidad de página más grandes y complejos con relativa facilidad.

Y esto también se traduce en una mejor experiencia de usuario.

Al encontrar y reparar los recursos que bloquean el procesamiento, también puede mejorar la forma en que su usuario experimenta su sitio y continuará manteniendo contentos a los visitantes de su sitio web.

¡Después de todo, mantener su sitio en la mejor forma para el horario de máxima audiencia es de lo que se trata todo este trabajo de optimización!

Más recursos:

Imagen destacada: SuperOhMo/Shutterstock

Leer el articulo original en Search Engine Journal.