Cómo eliminar los recursos que bloquean el renderizado

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 las métricas web principales de su página.
Estos recursos que bloquean el renderizado incluyen cosas como fuentes externas que tardan demasiado en cargarse (que no deben usarse), archivos multimedia innecesarios, código inflado que simplemente no desaparece y complementos adicionales que no son necesarios.
Hay innumerables 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 mayor.
Al optimizar la estructura de su página en este sentido, 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 que necesita Google para cargar tu página.
- Reduciendo 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.
- Interacción mejorada con los usuarios móviles.
- Rendimiento general mejorado.
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 en las métricas de experiencia de la página de su sitio (y en la satisfacción del usuario) como resultado.
En 2021, el tiempo promedio que tomó renderizar completamente una página web móvil fue 22 segundos. En 2018, fue 15 segundos.
Claramente, este es un número significativamente más alto que el tiempo recomendado por Google de dos a tres segundos. También es significativamente más alto que antes.
¿Qué podría estar causando estos problemas de recursos que bloquean el renderizado?
¿Qué impulsa este aumento en la velocidad general de representación de la página?
Una tendencia interesante a notar es que hay aumento de la 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 determinada.
Con las fuentes del sistema, el navegador no tiene que cargar nada adicional, por lo que no hay ese paso de procesamiento adicional.
Esta dependencia entre industrias probablemente afectará este tiempo de renderizado. Por supuesto, esta no es la única razón de este problema con los recursos que bloquean el renderizado.
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 el punto de vista del marketing.
Pero en términos de recursos de bloqueo de renderizado, esto puede causar un aumento significativo en el tiempo de carga de la página y la forma en que 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 es posible que las malas prácticas de desarrollo web utilizadas por los desarrolladores web en la actualidad sean las culpables.
De cualquier manera, esto es algo en cualquier 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 la página completa.
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 el modelo de objeto del documento.
¿Qué es la ruta crítica de renderizado?
La ruta crítica de representación se refiere a todos los pasos necesarios para representar la página completa, desde el momento en que el navegador comienza a recibir datos por primera vez hasta el momento en que finalmente compila la página en el renderizado final.
Este es un proceso que solo puede tomar unos pocos milisegundos si lo optimizas correctamente.
Optimizar para la ruta crítica de renderizado significa asegurarse de que está optimizando para el rendimiento de 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, reduce la cantidad de tiempo que los usuarios pasan mirando una pantalla blanca en blanco para mostrar contenido visual lo más rápido posible (consulte 0.0s a continuación).

Hay todo un proceso de cómo hacer esto descrito en Documentación de la guía para desarrolladores de Googlepero me centraré en un bateador pesado en particular: reducir los recursos que bloquean el renderizado.
¿Cómo funciona la ruta crítica de renderizado?
La ruta crítica de representación se refiere a la serie de pasos que toma un navegador para representar una página al convertir HTML, CSS y JavaScript en píxeles de pantalla reales.

Esencialmente, el navegador necesita solicitar, recibir y analizar todos los archivos HTML y CSS (mas trabajo extra), antes de que comience a representar contenido visual.
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 mientras el navegador completa 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:

Por lo tanto, 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 de las métricas web clave.
¿Cómo optimizo la ruta crítica de renderizado?
Para mejorar la ruta de representación crítica, debe analizar sus recursos de bloqueo de representación.
Cualquier recurso que bloquee el renderizado puede eventualmente bloquear el renderizado inicial de la página y, como resultado, afectar negativamente los resultados de Core Web Vitals.
Esto incluye un proceso de optimización de:
- Reducir el número de recursos que son críticos para la ruta de renderizado. Esto se puede hacer usando un método diferido para todos los posibles recursos de bloqueo de procesamiento.
- Priorización de contenido que se encuentra en la parte visible de la página y descargar recursos multimedia importantes lo antes posible.
- Comprimir el tamaño del archivo de todos los demás recursos críticos.
Al hacer esto, es posible mejorar tanto su 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 crítica de representación, es importante analizar el proceso de carga inicial del navegador y por qué la ruta crítica de representación es tan importante.
Y este proceso incluye:
- Precargar elementos de página.
- Incrustación de estilos críticos.
- Aplazar 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 en la página para descargar. De forma predeterminada, esto sucede en un proceso en el que el navegador descarga todos los elementos a la vez.
Pero, ¿qué sucede cuando tiene muchos elementos en la página de descarga (como lo que sucede a menudo 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? Mediante el uso de la conexión de precarga para descargar de forma asincrónica archivos críticos que bloquean la representación de la página (que se analiza más adelante en este artículo).
La precarga de elementos es una técnica que ayuda a eliminar las hojas de estilo que bloquean el renderizado porque carga los archivos críticos necesarios para la primera etapa del proceso de dibujo antes de cargar todos los demás archivos.
Puede precargar CSS, JS, fuentes o imágenes. Aquí hay ejemplos de cómo precargarlos:
Precargar JavaScript
<link rel="preload" as="script" href="https://www.searchenginejournal.com/identify-reduce-render-blocking-resources/316365/critical.js">
Precarga de CSS
<link rel="preload" href="https://www.searchenginejournal.com/identify-reduce-render-blocking-resources/316365/style.css" as="style" />
Precarga de fuentes
<link rel="preload" href="https://www.searchenginejournal.com/identify-reduce-render-blocking-resources/316365/fonts/webfont.woff2" as="font" type="font/woff2" crossorigin />
Precargar imágenes
<link rel=preload href="https://www.searchenginejournal.com/identify-reduce-render-blocking-resources/316365/cat.png" as=image image>
Esto ayuda a acelerar el proceso de la página. Sin embargo, esto no es 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 página completa.
Desafortunadamente, este no es un esfuerzo realista.
Dado que los sitios de WordPress suelen tener muchos complementos y recursos que los desarrolladores simplemente no quieren (o no quieren) manejar, 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.
Incorporación de estilos críticos
Critical CSS es una técnica que obtiene CSS para que el contenido en la parte visible de la página brinde contenido al usuario lo más rápido posible.
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 (Document Object Model) de la parte visible de la página.
Usando nuestro ejemplo anterior de una página que carga todos los recursos a la vez, incrustar estilos críticos implica usar código en HTML
la etiqueta en sí.Si comprueba, por ejemplo, el código fuente de google.com, lo verá incrustado en CSS crítico en el
Sección HTML.
Hay varias herramientas que pueden ayudar a extraer CSS crítico.
Aplazar la carga de archivos JavaScript
Al usar este método, es posible retrasar la carga de archivos JavaScript hasta que se carguen otros elementos críticos del árbol DOM. Sin embargo, esto viene con algunas advertencias.
Un ejemplo de cómo diferir un archivo JavaScript:
<script defer src="https://www.searchenginejournal.com/identify-reduce-render-blocking-resources/316365/script.js"></script>
El número uno es que puede afectar negativamente la apariencia del sitio cuando retrasa la carga de archivos JavaScript, ya que algunos de ellos pueden ser elementos necesarios para que la página se cargue por completo.
El número dos es que si no tiene cuidado, al retrasar la carga de los archivos JavaScript, podría crear problemas con la interactividad de la página (interacción del siguiente sorteo de la métrica Core Web Vitals).
El número tres es que también puede crear problemas con el funcionamiento del sitio en general.
La idea es que debe tener cuidado al trabajar en este tipo de optimizaciones para no causar problemas sin darse cuenta en otras partes del proceso.
De esta manera, puede afectar significativamente la velocidad de su página y la forma en que 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 retrasa todos los archivos CRÍTICOS hasta que la página carga la parte HTML del documento.
¿Qué significa esto? Esto significa que Google no puede ver el documento completo tal como debe mostrarse. 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:
“Para una representación e indexación óptimas, siempre permita que Googlebot acceda a los archivos JavaScript, CSS y de imagen utilizados por su sitio web para que Googlebot pueda ver su sitio como un usuario normal.
Si el archivo robots.txt de su sitio prohíbe que se rastreen estos recursos, perjudicará directamente la calidad de procesamiento e indexación de su contenido por parte de nuestros algoritmos. Esto puede resultar en una clasificación subóptima”.
Si está aplazando archivos CSS y JavaScript críticos por razones de SEO, siempre que se asegure de que Google pueda ver esos archivos al cargar 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. Los sitios realmente se han vuelto más complejos en los últimos años.
Por lo tanto, también lo son los servidores. Pero hay limitaciones. Aunque los servidores pueden realizar y realizan tareas triviales durante todo el día, aún es posible que un servidor se atasque mientras trabaja para repensar cómo maneja los recursos del sitio.
Entonces, cuando esto sucede, hay un retraso adicional del que habría de otro modo, y sucede antes de que el navegador pueda comenzar a mostrar la página.
Cuando se produce este retraso, puede experimentar situaciones en las que un sitio puede tardar varios segundos en aparecer en la ventana del navegador.
Y asegurarse de que su servidor esté procesando los archivos correctamente es un excelente primer paso para aumentar la velocidad de su página.
Este es un ejemplo de lo que sucede cuando su servidor deja de responder y tarda demasiado en procesar ciertos recursos:

Entonces, ¿cómo funcionan los primeros consejos?
De acuerdo a Guía para desarrolladores de Google Chrome"primeros consejos es un código de estado HTTP (103 primeros consejos) que se utiliza para enviar una respuesta HTTP preliminar precisa antes de una respuesta final".
¿Qué logra esto?
Esto permite que el servidor brinde ciertos tipos de sugerencias al navegador sobre ciertos recursos críticos (archivos de JavaScript, hojas de estilo CSS y otros) que es probable que la página web cargue y use.
Este proceso ocurre en unos pocos milisegundos o menos mientras el servidor trabaja en la representación de los recursos de la página principal.
Las primeras sugerencias son algo que "ayuda al navegador" y acelera el tiempo de reflexión del servidor al trabajar en esta carga de antemano.
Por lo tanto, este proceso ayuda a acelerar el tiempo de carga de la página.
Herramientas para ayudarlo a optimizar su ruta crítica de renderizado
¿No eres un genio del código excepcional 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 te permite generar el CSS crítico que tu sitio necesita. Simplemente agregue su URL, haga clic en generar y listo.
- Un complemento para optimizar automáticamente la velocidad de la página: 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. Una vez instalado, este complemento en particular le permite aprovechar el almacenamiento en caché de la página, la compresión GZIP, la precarga de caché y el almacenamiento en caché del navegador.
- Optimización de WP: Este es un complemento de WordPress que le permite hacer varias cosas para optimizar mejor su sitio para una carga rápida. Estos incluyen optimizar su base de datos, comprimir sus imágenes y almacenar en caché sus páginas, además de minimizar y sincronizar sus archivos CSS y JavaScript.
Tenga en cuenta: este autor no tiene prejuicios financieros hacia ninguna de estas herramientas.
¿Por qué debería importarme?
Los datos de comportamiento de los usuarios 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 los tiempos 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 algunas actualizaciones importantes de Google en el horizonte para las que debe prepararse.
Identificar y optimizar los recursos que bloquean el procesamiento será fundamental para mantenerse al tanto de su juego cuando se implementen estas actualizaciones.
Google implementará experiencia de la página de escritorio en 2022comenzando el despliegue de la página de escritorio en febrero y finalizando en marzo.
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 las clasificaciones de escritorio.
Además, es Google trabajar en una métrica completamente nueva, posiblemente experimental, para las métricas web básicas, que tiene en cuenta la duración máxima del evento y la duración total del evento.
Su explicación de estos factores que consideran es:
Evento con duración máxima: la latencia de interacción es igual a la duración más larga de un solo evento de cualquier evento en el grupo de interacción.
Evento con duración total: La latencia de interacción es la suma de las duraciones de todos los eventos, ignorando cualquier superposición.
con mucha investigacion Al vincular las reducciones en los tiempos de carga de la página con las mejoras en los valiosos KPI (conversiones, tasas de rebote, tiempo en el sitio), mejorar la latencia del sitio se ha convertido en un objetivo comercial clave para muchas organizaciones.
Los profesionales de SEO se encuentran en una posición única para liderar este esfuerzo, ya que nuestro papel suele ser cerrar la brecha entre los objetivos comerciales y las prioridades de los desarrolladores web.
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 la optimización de recursos para bloquear la representación
Uno de los objetivos principales de optimizar la ruta crítica de representación es garantizar que los recursos necesarios para representar este contenido importante en la parte visible de la página se carguen lo más rápido 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 su página, la experiencia de la página y los resultados clave de las métricas web.
¿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.
¿Porqué es eso?
Aunque esto sucede en un milisegundo o menos (en la mayoría de los casos), el navegador no comenzará a mostrar el contenido de la página hasta que pueda solicitar, recibir y procesar 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 sin formato 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 parte del contenido para que parezca al menos aceptable para el usuario.
Si observamos el proceso de representación de la página, el cuadro gris a continuación representa el tiempo que le toma al navegador obtener todos los recursos CSS. De esta manera puede comenzar a construir el CSS DOM (o árbol CCSOM).
Esto puede 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 puede depender del tamaño y la cantidad de estos archivos CSS.
El siguiente árbol de renderizado muestra un ejemplo de un navegador que renderiza todos los archivos junto con CSS en el DOM:

Además, a continuación se muestra un ejemplo de la secuencia de representación de una página, en la que todos los archivos se cargan en un proceso, desde la construcción del DOM hasta el dibujo final y la composición de la página, lo que se conoce como la ruta crítica de representación.
Dado que CSS es un recurso que bloquea la visualización de forma predeterminada, tiene sentido mejorar el CSS hasta el punto en que no afecte negativamente al proceso de visualización de la página.
el oficial La recomendación de Google dice el seguimiento:
"CSS es un recurso de bloqueo de procesamiento. Entrégueselo al cliente lo antes posible y lo más rápido posible para optimizar el tiempo hasta el primer renderizado”.
HTML debe convertirse en algo con lo que el navegador pueda funcionar: el DOM. Los archivos CSS son de la misma manera. Esto debe convertirse a CSSOM.
Al optimizar los archivos CSS dentro del DOM y CSSOM, puede ayudar a reducir el tiempo que le toma al navegador 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 cargar JavaScript no siempre es necesario?
Con JavaScript, descargar y analizar todos los recursos de JavaScript no es un paso necesario para representar completamente una página.
Por lo tanto, en realidad no es una parte técnicamente necesaria para representar 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 visible de la página.
Pero si un navegador encuentra archivos JavaScript antes de que una página se represente por primera vez, el proceso de representación puede suspenderse 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 JavaScript para su uso posterior.
Un ejemplo de esto es si hay funciones JS como una advertencia que está incrustada en el HTML. Esto puede dejar de mostrar la página hasta que se ejecute 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 pueden 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:
"JavaScript también puede bloquear la construcción del DOM y ralentizar la representación de la página. Para garantizar un rendimiento óptimo... elimine cualquier JavaScript innecesario de la ruta crítica de representación.'
Cómo identificar los recursos que bloquean el renderizado
Para identificar la ruta de representación crítica y analizar los recursos críticos:
- Ejecutar 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; busque archivos CSS o JavaScript que se declaren antes de la línea verde "empezar a renderizar", pero que no sean críticos para cargar contenido en la parte visible de la página.

Una vez que haya identificado un recurso (potencialmente) que bloquea el procesamiento, pruebe a eliminarlo para ver si el contenido de la parte visible de la página se ve afectado.
En mi ejemplo, noté algunas consultas de JavaScript que podrían ser críticas.
Aunque es fundamental, a veces es una buena idea probar la eliminación de estos scripts para ver cómo los cambios en los elementos del sitio afectan la experiencia.

Hay otras formas de mejorar dichos recursos.
Para archivos JavaScript no críticos, puede considerar combinar los archivos y diferirlos al incluir esos 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 una página
Una vez que haya determinado que el recurso de bloqueo de representación no es crítico para representar contenido en la parte visible de la página, querrá explorar la 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 a través de la regla @import.
Asegúrate 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 causar problemas de rendimiento.
La declaración @import en realidad hará que el navegador procese un archivo CSS más lentamente. ¿Por qué? Porque también descarga todos los archivos importados.
La representación se bloqueará por completo hasta que se complete el proceso.
Realmente, la mejor solución es usar el método estándar de incluir una hoja de estilo CSS usando declaración en HTML.
Minimice sus archivos CSS y JavaScript
Si usa WordPress, usar un complemento para minimizar sus archivos CSS y JavaScript puede tener un gran impacto.
El proceso de minificación toma todos los espacios innecesarios en el archivo y los comprime aún más, para que pueda obtener un buen aumento de rendimiento.
Además, incluso si no usa WordPress, puede usar 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, ya que lleva menos tiempo descargar recursos de bloqueo que no son de procesamiento.
Use fuentes del sistema en lugar de fuentes de terceros
Aunque pueda parecer que las fuentes de terceros hacen que el sitio sea "más bonito", no es exactamente así.
Aunque 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 con los recursos que bloquean el procesamiento.
Debido a los archivos externos, el navegador debe realizar solicitudes de descarga externas para estos archivos para mostrar su página, lo que puede resultar en tiempos de descarga significativamente más largos.
Si está en un equipo que tiene mejores prácticas de desarrollo menos que ideales, entonces podría tener sentido tener muchos archivos de fuentes de terceros que no son necesarios para representar su sitio.
En este caso, eliminar todos estos archivos innecesarios puede mejorar en gran medida 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, admite el procesamiento solo del navegador sin fuentes externas peticiones.
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 desea hacer para ayudar a mitigar los problemas con ciertos aspectos de las fuentes de terceros.
Primero, si se usa junto con precarga y intercambio de fuenteslos problemas con las fuentes de terceros dejan de ser un problema.
El otro problema con el uso de fuentes de terceros es que las fuentes son invisibles hasta que se carga la fuente en sí, lo que afecta negativamente a Core Web Vitals y la experiencia del usuario. Para evitar esto, puede utilizar intercambio de fuentes css.
Así es como funciona: El CSS de intercambio de fuentes le dice al navegador que el texto que usa una fuente en particular debe mostrarse inmediatamente usando la 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.
El chico nuevo en el bloque: fuentes variables
A partir de 2020, las fuentes variables son 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 archivo. Pero antes de que las fuentes variables se vuelvan algo común, necesitará varios archivos de fuentes independientes para las fuentes.
También hay varios beneficios de 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 único archivo de fuente que contiene todas las variaciones de ancho, peso y otros atributos.
- Una gama de diseños más flexible: Con otros tipos de fuentes, se requieren de tres a cinco archivos de fuentes diferentes para proporcionar cada representación del lenguaje/voz de diseño del sitio. Y eso incluye cualquier permutación de títulos, master copy, etc. Pero con fuentes variables, usar un solo archivo de fuente le permite usar todas las variaciones posibles que se pueden asociar con el diseño de la fuente.
- Menos y solo un archivo: Debido a este ahorro en el tamaño del archivo, ayuda a comprimir aún más el tamaño de la página y reduce la velocidad de la página. Y la ventaja de un solo archivo por sí sola permite que un webmaster realmente comprima aún más la velocidad de su página.
La siguiente documentación habla de fuentes variables y como aplicarlos. Debido a sus ventajas, el uso de fuentes variables es una alternativa aceptable si es absolutamente necesario implementar fuentes de terceros.
Mejore sus técnicas de codificación y combinación de archivos
Si está trabajando con el código usted mismo, puede (o no puede... nadie está juzgando aquí) encontrar que las técnicas no son óptimas.
Un ejemplo: está utilizando CSS en línea en todas partes y está causando problemas de procesamiento y representación en el navegador.
La solución fácil es asegurarse de tomar todo el CSS en línea y codificarlo correctamente en el archivo de hoja de estilo CSS.
Si el código de otro desarrollador no está a la altura, puede causar problemas importantes con la representación de la página.
Por ejemplo: digamos que tiene una página que está codificada con técnicas más antiguas en lugar de las modernas y más simples.
Las técnicas más antiguas pueden implicar una gran cantidad de código y dar como resultado una representación de página más lenta.
Para eliminar esto, puede mejorar sus técnicas de codificación creando un código más simple 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 10 archivos JavaScript que contribuyen a la misma tarea, puede contratar a un desarrollador que pueda combinar todos esos archivos por usted.
Y si son archivos JavaScript menos críticos, para reducir 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 de la página.
Al combinar archivos y mejorar sus técnicas de codificación, puede contribuir en gran medida a una mejor experiencia de visualización de páginas.
Resultados clave
Si desea crear su propio proceso para encontrar y reducir los recursos que bloquean el renderizado, ya tiene las herramientas para hacerlo. El proceso se describe de la siguiente manera:
- Nivel 1: Rastrea tu sitio usando Screaming Frog u otras herramientas de rastreo.
- paso 2: Identificar páginas de baja velocidad.
- paso 2a: También puede utilizar Google Search Console o Google Analytics para este fin.
- paso 3: Prioriza las páginas de menor rendimiento que encuentres.
- paso 4: Vaya a los elementos de la lista de verificación anteriores (también puede crear una hoja de cálculo para cada elemento en una página, si lo prefiere) y encuentre, reduzca o repare estos recursos que bloquean el procesamiento 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 encaminarlo hacia el éxito con una velocidad de página mucho menor como resultado.
Con este proceso, también puede beneficiarse de la ventaja que tendrá y también puede experimentar un impulso de las principales métricas web de Google.
Identificar y corregir 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. La razón de esto es que ayudan a crear los mejores tiempos de representación posibles para sus páginas de clasificación.
Google trabaja constantemente para mejorar la velocidad de la página. Pero hay una cosa que siempre ha sido constante: cuanto más rápida sea la velocidad de la 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 eso también significa 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, el objetivo de todo este trabajo de optimización es mantener su sitio en la mejor forma durante el mejor tiempo!
Más recursos:
Imagen destacada: SuperOhMo/Shutterstock
window.addEventListener( 'load', function() { setTimeout(function(){ striggerEvent( 'load2' ); }, 2000); });
window.addEventListener( 'load2', function() {
if( sopp != 'yes' && addtl_consent != '1~' && !ss_u ){
!function(f,b,e,v,n,t,s) {if(f.fbq)return;n=f.fbq=function(){n.callMethod? n.callMethod.apply(n,arguments):n.queue.push(arguments)}; if(!f._fbq)f._fbq=n;n.push=n;n.loaded=!0;n.version='2.0'; n.queue=[];t=b.createElement(e);t.async=!0; t.src=v;s=b.getElementsByTagName(e)[0]; s.parentNode.insertBefore(t,s)}(window,document,'script', 'https://connect.facebook.net/en_US/fbevents.js');
if( typeof sopp !== "undefined" && sopp === 'yes' ){ fbq('dataProcessingOptions', ['LDU'], 1, 1000); }else{ fbq('dataProcessingOptions', []); }
fbq('init', '1321385257908563');
fbq('track', 'PageView');
fbq('trackSingle', '1321385257908563', 'ViewContent', { content_name: 'identify-reduce-render-blocking-resources', content_category: 'seo technical-seo' }); } });
Deja una respuesta