Si optimizaste tu código, pero tu sitio aún se carga demasiado lento, es probable que sea por las secuencias de comandos de terceros.
Las secuencias de comandos de terceros proporcionan una variedad de funciones útiles que hacen que la Web sea más dinámica, interactiva y, en cierto modo, interconectada. Algunos de ellos incluso podrían ser fundamentales para la función o el flujo de ingresos de tu sitio web. Sin embargo, su uso es arriesgado:
- Pueden ralentizar el rendimiento de tu sitio.
- Pueden causar problemas de privacidad o seguridad.
- Pueden ser impredecibles y su comportamiento puede tener consecuencias no deseadas.
Lo ideal es que te asegures de que las secuencias de comandos de terceros no afecten la ruta de acceso de renderización crítica de tu sitio. En esta guía, veremos cómo encontrar y solucionar problemas relacionados con la carga de JavaScript de terceros y minimizar los riesgos para los usuarios.
¿Qué son las secuencias de comandos de terceros?
A menudo, el código JavaScript de terceros hace referencia a secuencias de comandos que se pueden incorporar en cualquier sitio directamente desde un proveedor externo. Los siguientes son algunos ejemplos:
Botones para compartir contenido en redes sociales (Facebook, X, LinkedIn, Mastodon)
Incorporaciones de reproductores de video (YouTube, Vimeo)
Iframes de publicidad
Secuencias de comandos de estadísticas y métricas
Secuencias de comandos de pruebas A/B para experimentos
Bibliotecas de ayuda, como formato de fecha, animación o bibliotecas funcionales
<iframe
width="560"
height="315"
src="https://www.youtube.com/embed/mo8thg5XGV0"
frameborder="0"
allow="autoplay; encrypted-media"
allowfullscreen
>
</iframe>
Lamentablemente, incorporar secuencias de comandos de terceros significa que, a menudo, dependemos de ellas para que se ejecuten con rapidez y no ralenticen nuestras páginas. Las secuencias de comandos de terceros son una causa común de las ralentizaciones del rendimiento causadas por recursos fuera del control del propietario del sitio, incluidos los siguientes problemas:
Se envían demasiadas solicitudes de red a varios servidores. Cuantas más solicitudes tenga que realizar un sitio, más tiempo puede tardar en cargarse.
Enviar demasiado código JavaScript que mantiene ocupado el subproceso principal Demasiado código JavaScript puede bloquear la construcción del DOM, lo que retrasa la renderización de la página. El análisis y la ejecución de secuencias de comandos que requieren mucho uso de la CPU pueden retrasar la interacción del usuario y agotar la batería.
El envío de videos o archivos de imagen no optimizados grandes puede consumir datos y costar dinero a los usuarios.
Problemas de seguridad que pueden actuar como un punto único de fallo (SPOF) si tu página carga una secuencia de comandos sin precaución.
Caché HTTP insuficiente, lo que obliga al navegador a enviar más solicitudes de red para recuperar recursos
La falta de compresión del servidor suficiente hace que los recursos se carguen lentamente.
Bloquear la visualización del contenido hasta que se complete el procesamiento Esto también puede ser cierto para las secuencias de comandos de pruebas A/B asíncronas.
Uso de APIs heredadas que se sabe que dañan la experiencia del usuario, como document.write()
Elementos DOM excesivos o selectores CSS costosos
La inclusión de varias incorporaciones de terceros puede provocar que se extraigan varios frameworks y bibliotecas varias veces, lo que desperdicia recursos y empeora los problemas de rendimiento existentes.
Las secuencias de comandos de terceros suelen usar técnicas de incorporación que pueden bloquear window.onload si sus servidores responden con lentitud, incluso si la incorporación usa async o defer.
Tu capacidad para solucionar problemas con secuencias de comandos de terceros puede depender de tu sitio y de tu capacidad para configurar la forma en que cargas el código de terceros. Por suerte, existen varias soluciones y herramientas para encontrar y solucionar problemas con recursos de terceros.
¿Cómo identificas una secuencia de comandos de terceros en una página?
El primer paso para optimizarlas es identificar las secuencias de comandos de terceros en tu sitio y determinar su impacto en el rendimiento. Te recomendamos que uses herramientas gratuitas de prueba de velocidad web, como Herramientas para desarrolladores de Chrome, PageSpeed Insights y WebPageTest, para identificar las secuencias de comandos costosas. Estas herramientas muestran información de diagnóstico enriquecida que puede indicarte cuántas secuencias de comandos de terceros usa tu sitio y cuáles tardan más tiempo en ejecutarse.
La vista en cascada de WebPageTest puede destacar el impacto del uso intensivo de secuencias de comandos de terceros. En la siguiente imagen de Tags Gone Wild, se muestra un diagrama de ejemplo de las solicitudes de red necesarias para cargar el contenido principal de un sitio, en lugar de las secuencias de comandos de seguimiento y marketing.
El desglose de dominios de WebPageTest también puede ser útil para visualizar cuánto contenido proviene de orígenes de terceros. Se desglosa en bytes totales y cantidad de solicitudes:
¿Cómo puedo medir el impacto de la secuencia de comandos de terceros en mi página?
Cuando veas que una secuencia de comandos causa problemas, averigua qué hace y determina si tu sitio la necesita para funcionar. Si es necesario, ejecuta una prueba A/B para equilibrar su valor percibido en función de su impacto en la participación clave de los usuarios o las métricas de rendimiento.
Auditoría del tiempo de inicio de Lighthouse
La auditoría del tiempo de inicio de JavaScript de Lighthouse destaca las secuencias de comandos que tienen un tiempo de análisis, compilación o evaluación costoso. Esto puede ayudarte a identificar secuencias de comandos de terceros que usan mucho la CPU.
Auditoría de cargas útiles de red de Lighthouse
La Auditoría de cargas útiles de red de Lighthouse identifica las solicitudes de red, incluidas las solicitudes de red de terceros que ralentizan el tiempo de carga de la página y hacen que los usuarios gasten más de lo esperado en datos móviles.
Bloqueo de solicitudes de red de las herramientas para desarrolladores de Chrome
Chrome DevTools te permite ver cómo se comporta tu página cuando no está disponible una secuencia de comandos, una hoja de estilo o algún otro recurso especificado. Esto se hace con el bloqueo de solicitudes de red, una función que puede ayudar a medir el impacto de quitar recursos individuales de terceros de tu página.
Para habilitar el bloqueo de solicitudes, haz clic con el botón derecho en cualquier solicitud del panel de red y selecciona Bloquear URL de solicitud. Luego, se mostrará una pestaña de bloqueo de solicitudes en el panel de DevTools, lo que te permitirá administrar qué solicitudes se bloquearon.
Panel de rendimiento de las Herramientas para desarrolladores de Chrome
El panel Rendimiento de Chrome DevTools ayuda a identificar problemas con el rendimiento web de tu página.
- Haz clic en Grabar.
- Carga tu página. DevTools muestra un diagrama en cascada que representa cómo tu sitio gasta su tiempo de carga.
- Navega a De abajo hacia arriba en la parte inferior del panel Rendimiento.
- Haz clic en Agrupar por producto y ordena las secuencias de comandos de terceros de tu página por tiempo de carga.
Para obtener más información sobre el uso de Chrome DevTools para analizar el rendimiento de carga de la página, consulta Cómo comenzar a analizar el rendimiento del tiempo de ejecución.
El siguiente es nuestro flujo de trabajo recomendado para medir el impacto de las secuencias de comandos de terceros:
- Usa el panel Network para medir el tiempo que tarda en cargarse tu página.
- Para emular condiciones reales, te recomendamos que actives la limitación de red y la limitación de CPU. Es poco probable que tus usuarios tengan las conexiones de red rápidas y el hardware de computadoras de escritorio que reducen el impacto de las secuencias de comandos costosas en condiciones de laboratorio.
- Bloquea las URLs o los dominios responsables de las secuencias de comandos de terceros que creas que son un problema (consulta el panel de rendimiento de Chrome DevTools para obtener orientación sobre cómo identificar secuencias de comandos costosas).
- Vuelve a cargar la página y vuelve a medir el tiempo de carga.
- Para obtener datos más precisos, te recomendamos que midas el tiempo de carga al menos tres veces. Esto se debe a que algunas secuencias de comandos de terceros recuperan diferentes recursos en cada carga de página. Para ayudarte con esto, el panel de rendimiento de DevTools admite varias grabaciones.
Mide el impacto de las secuencias de comandos de terceros con WebPageTest
WebPageTest admite el bloqueo de solicitudes individuales para cargar y medir su impacto en Configuración avanzada > Bloquear. Usa esta función para especificar una lista de dominios que se bloquearán, como los dominios de publicidad.
Te recomendamos que uses el siguiente flujo de trabajo para usar esta función:
- Prueba una página sin bloquear a terceros.
- Repite la prueba con algunos terceros bloqueados.
- Selecciona los dos resultados del Historial de pruebas.
- Haz clic en Comparar.
En la siguiente imagen, se muestra la función de diapositivas de WebPageTest, que compara las secuencias de carga de páginas con y sin recursos de terceros activos. Te recomendamos que verifiques esta opción para las pruebas de orígenes de terceros individuales para determinar qué dominios afectan más el rendimiento de tu página.
WebPageTest también admite dos comandos que operan a nivel del DNS para bloquear dominios:
blockDomains
toma una lista de dominios para bloquear.- blockDomainsExcept toma una lista de dominios y bloquea todo lo que no esté en la lista.
WebPageTest también tiene una pestaña de punto único de fallo (SPOF) que te permitesimular un tiempo de espera o una falla completa para cargar un recurso. A diferencia del bloqueo de dominios, el SPOF se agota lentamente, lo que puede ser útil para probar el comportamiento de tus páginas cuando los servicios de terceros tienen una carga pesada o no están disponibles temporalmente.
Cómo detectar iframes costosos con tareas largas
Cuando las secuencias de comandos en iframes de terceros tardan mucho en ejecutarse, pueden bloquear el subproceso principal y retrasar otras tareas. Estas tareas largas pueden hacer que los controladores de eventos funcionen con lentitud o que se pierdan fotogramas, lo que empeora la experiencia del usuario.
Para detectar tareas largas para la supervisión de usuarios reales (RUM), usa la API de PerformanceObserver de JavaScript para observar las entradas de longtask. Estas entradas contienen una propiedad de atribución que puedes usar para determinar qué contexto de marco provocó la tarea larga.
El siguiente código registra entradas longtask
en la consola, incluida una para un iframe "costoso":
<script>
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// Attribution entry including "containerSrc":"https://example.com"
console.log(JSON.stringify(entry.attribution));
}
});
observer.observe({entryTypes: ['longtask']});
</script>
<!-- Imagine this is an iframe with expensive long tasks -->
<iframe src="https://example.com"></iframe>
Para obtener más información sobre la supervisión de tareas largas, consulta Métricas de rendimiento centradas en el usuario.
¿Cómo se carga una secuencia de comandos de terceros de manera eficiente?
Si una secuencia de comandos de terceros ralentiza la carga de la página, tienes varias opciones para mejorar el rendimiento:
- Carga la secuencia de comandos con el atributo
async
odefer
para evitar bloquear el análisis de documentos. - Si el servidor de terceros es lento, considera alojar la secuencia de comandos por tu cuenta.
- Si la secuencia de comandos no agrega un valor claro a tu sitio, quítala.
- Usa sugerencias de recursos, como
<link rel=preconnect>
o<link rel=dns-prefetch>
, para realizar una búsqueda de DNS en dominios que alojan secuencias de comandos de terceros.
Usa async
o defer
La ejecución de JavaScript bloquea el analizador. Cuando el navegador encuentra una secuencia de comandos, debe pausar la construcción del DOM, pasarla al motor de JavaScript y permitir que se ejecute antes de continuar con la construcción del DOM.
Los atributos async
y defer
cambian este comportamiento de la siguiente manera:
async
hace que el navegador descargue la secuencia de comandos de forma asíncrona mientras sigue analizando el documento HTML. Cuando finaliza la descarga de la secuencia de comandos, el análisis se bloquea mientras se ejecuta.defer
hace que el navegador descargue la secuencia de comandos de forma asíncrona mientras sigue analizando el documento HTML y, luego, espera para ejecutar la secuencia de comandos hasta que se complete el análisis del documento.
Usa siempre async
o defer
para las secuencias de comandos de terceros, a menos que la secuencia de comandos sea necesaria para la ruta de acceso de renderización crítica. Usa async
si es importante que la secuencia de comandos se ejecute antes en el proceso de carga, como en el caso de algunas secuencias de comandos de estadísticas. Usa defer
para recursos menos críticos, como videos que se renderizan más abajo en la página de lo que el usuario verá inicialmente.
Si tu principal preocupación es el rendimiento, te recomendamos que esperes para agregar secuencias de comandos asíncronas hasta que se cargue el contenido fundamental de tu página. No recomendamos usar async
para bibliotecas esenciales, como jQuery.
Algunas secuencias de comandos deben cargarse sin async
o defer
, en especial aquellas que son partes fundamentales de tu sitio. Entre ellas, se incluyen bibliotecas de la IU o frameworks de redes de distribución de contenido (CDN) sin los que tu sitio no puede funcionar.
Otras secuencias de comandos simplemente no funcionan si se cargan de forma asíncrona. Revisa la documentación de las secuencias de comandos que usas y reemplaza las que no se pueden cargar de forma asíncrona por alternativas que sí lo puedan hacer. Ten en cuenta que algunos terceros recomiendan ejecutar sus secuencias de comandos de forma síncrona, incluso si funcionaran igual de bien de forma asíncrona.
Recuerda que async
no soluciona todo. Si tu página incluye una gran cantidad de secuencias de comandos, como secuencias de comandos de seguimiento con fines publicitarios, cargarlas de forma asíncrona no evitará que ralenticen la carga de la página.
Usa sugerencias de recursos para reducir el tiempo de configuración de la conexión
Establecer conexiones con orígenes de terceros puede llevar mucho tiempo, en especial en redes lentas, ya que las solicitudes de red tienen varios componentes complejos, incluidas las búsquedas de DNS y los redireccionamientos. Puedes usar sugerencias de recursos, como , para realizar búsquedas de DNS para dominios que alojan secuencias de comandos de terceros al principio del proceso de carga de la página, de modo que el resto de la solicitud de red pueda continuar más rápido después:
<link rel="dns-prefetch" href="http://example.com" />
Si el dominio de terceros al que te conectas usa HTTPS, también puedes usar , que realiza búsquedas de DNS y resuelve los recorridos de ida y vuelta de TCP y controla las negociaciones de TLS. Estos otros pasos pueden ser muy lentos porque implican verificar los certificados SSL, por lo que la conexión previa puede disminuir en gran medida el tiempo de carga.
<link rel="preconnect" href="https://cdn.example.com" />
Secuencias de comandos de "zona de pruebas" con un iframe
Si cargas una secuencia de comandos de terceros directamente en un iframe, no se bloqueará la ejecución de la página principal. AMP usa este enfoque para mantener JavaScript fuera de la ruta de acceso crítica. Ten en cuenta que este enfoque aún bloquea el evento onload
, por lo que intenta no adjuntar funciones críticas a onload
.
Chrome también admite la Política de Permisos (anteriormente, Política de Funciones), un conjunto de políticas que permiten a un desarrollador inhabilitar de forma selectiva el acceso a ciertas funciones del navegador. Puedes usarlo para evitar que el contenido de terceros introduzca comportamientos no deseados en un sitio.
Autoalojan secuencias de comandos de terceros
Si deseas tener más control sobre cómo se carga una secuencia de comandos fundamental, por ejemplo, para reducir el tiempo de DNS o mejorar los encabezados de almacenamiento en caché HTTP, es posible que puedas alojarla por tu cuenta.
Sin embargo, el autoalojamiento tiene sus propios problemas, en especial cuando se trata de actualizar las secuencias de comandos. Las secuencias de comandos alojadas por el usuario no recibirán actualizaciones automáticas para cambios en la API ni correcciones de seguridad, lo que puede generar pérdidas de ingresos o problemas de seguridad hasta que puedas actualizar la secuencia de comandos de forma manual.
Como alternativa, puedes almacenar en caché secuencias de comandos de terceros con trabajadores del servicio para tener más control sobre la frecuencia con la que se recuperan las secuencias de comandos de la red. También puedes usar los trabajadores del servicio para crear estrategias de carga que reduzcan las solicitudes de terceros no esenciales hasta que tu página alcance un momento clave del usuario.
Realiza pruebas A/B en muestras más pequeñas de usuarios
Las pruebas A/B (o pruebas divididas) son una técnica para experimentar con dos versiones de una página y analizar la experiencia y el comportamiento de los usuarios. Pone las versiones de la página a disposición de diferentes muestras del tráfico de tu sitio web y determina, a partir de las estadísticas, qué versión proporciona un mejor porcentaje de conversiones.
Sin embargo, por diseño, las pruebas A/B retrasan la renderización para decidir qué experimento debe estar activo. A menudo, se usa JavaScript para verificar si alguno de tus usuarios pertenece a un experimento de prueba A/B y, luego, habilitar la variante correcta. Este proceso puede empeorar la experiencia incluso para los usuarios que no forman parte del experimento.
Para acelerar la renderización de la página, te recomendamos que envíes tus secuencias de comandos de pruebas A/B a una muestra más pequeña de tu base de usuarios y ejecutes el código que decide qué versión de la página mostrar en el servidor.
Carga diferida de recursos de terceros
Los recursos de terceros incorporados, como los anuncios y los videos, pueden ser factores importantes que ralentizan la velocidad de la página cuando se crean de forma deficiente. La carga diferida se puede usar para cargar recursos incorporados solo cuando sea necesario, por ejemplo, esperar a publicar anuncios en el pie de página hasta que el usuario se desplace lo suficiente como para verlos. También puedes cargar de forma diferida contenido de terceros después de que se cargue el contenido de la página principal, pero antes de que un usuario interactúe con la página.
Ten cuidado cuando cargues recursos de manera diferida, ya que a menudo implica código JavaScript que puede verse afectado por conexiones de red inestables.
DoubleClick tiene orientación sobre cómo cargar anuncios de forma diferida en su documentación oficial.
Carga diferida eficiente con Intersection Observer
Históricamente, los métodos para detectar si un elemento es visible en el viewport para la carga diferida son propensos a errores y, a menudo, ralentizan el navegador. Estos métodos ineficientes suelen detectar eventos de desplazamiento o redimensionamiento y, luego, usan APIs de DOM, como getBoundingClientRect(), para calcular dónde se encuentran los elementos en relación con el viewport.
IntersectionObserver es una API del navegador que permite a los propietarios de páginas detectar de manera eficiente cuándo un elemento observado entra o sale del viewport del navegador. LazySizes también tiene una compatibilidad opcional con IntersectionObserver.
Estadísticas de carga diferida
Si aplazas la carga de tus secuencias de comandos de estadísticas durante demasiado tiempo, es posible que pierdas datos de estadísticas valiosos. Por fortuna, hay estrategias disponibles para inicializar las estadísticas de forma diferida y, al mismo tiempo, conservar los datos de carga temprana de la página.
En la entrada de blog The Google Analytics Setup I Use on Every Site I Build de Phil Walton, se describe una de esas estrategias para Google Analytics.
Carga secuencias de comandos de terceros de forma segura
En esta sección, se proporciona orientación para cargar secuencias de comandos de terceros de la forma más segura posible.
Evita document.write()
Las secuencias de comandos de terceros, en especial para servicios más antiguos, a veces usan document.write()
para insertar y cargar secuencias de comandos. Esto es un problema porque document.write()
se comporta de manera incoherente y sus fallas son difíciles de depurar.
La solución para los problemas de document.write() es no usarlo. En Chrome 53 y versiones posteriores, las Herramientas para desarrolladores de Chrome registran advertencias en la consola por el uso problemático de document.write()
:
Si recibes este error, puedes verificar el uso de document.write()
en tu sitio buscando los encabezados HTTP que se envían a tu navegador.
Lighthouse también puede destacar las secuencias de comandos de terceros que todavía usan document.write()
.
Usa los administradores de etiquetas con cuidado
Una etiqueta es un fragmento de código que permite a los equipos de marketing digital recopilar datos, configurar cookies o integrar contenido de terceros, como widgets de redes sociales, en un sitio. Estas etiquetas agregan solicitudes de red, dependencias de JavaScript y otros recursos a tu página que pueden afectar su rendimiento, y minimizar ese impacto para los usuarios se vuelve más difícil a medida que se agregan más etiquetas.
Para que la página se cargue rápido, te recomendamos que uses un administrador de etiquetas, como Google Tag Manager (GTM). GTM te permite implementar etiquetas de forma asíncrona para que no se bloqueen entre sí, reduce la cantidad de llamadas de red que un navegador necesita para ejecutar etiquetas y recopila datos de etiquetas en la IU de su capa de datos.
Riesgos de usar administradores de etiquetas
Aunque los administradores de etiquetas están diseñados para optimizar la carga de páginas, usarlos de forma descuidada puede ralentizarla de las siguientes maneras:
- Una cantidad excesiva de etiquetas y objetos de escucha de eventos automáticos en tu administrador de etiquetas hace que el navegador realice más solicitudes de red de las que necesitaría y reduce la capacidad de tu código para responder a los eventos con rapidez.
- Cualquier persona que tenga credenciales y acceso puede agregar JavaScript a tu administrador de etiquetas. Esto no solo puede aumentar la cantidad de solicitudes de red costosas necesarias para cargar tu página, sino que también puede presentar riesgos de seguridad y otros problemas de rendimiento debido a secuencias de comandos innecesarias. Para reducir estos riesgos, te recomendamos limitar el acceso a tu administrador de etiquetas.
Evita las secuencias de comandos que contaminen el alcance global
Las secuencias de comandos de terceros pueden comportarse de todo tipo de maneras que dañen tu página de forma inesperada:
- Las secuencias de comandos que cargan dependencias de JavaScript pueden contaminar el alcance global con código que interactúa mal con tu código.
- Las actualizaciones inesperadas pueden causar cambios rotundos.
- El código de terceros se puede modificar en tránsito para que se comporte de manera diferente entre las pruebas y la implementación de tu página.
Te recomendamos que realices auditorías periódicas de las secuencias de comandos de terceros que cargas para detectar posibles amenazas. También puedes implementar la autoprueba, la integridad de subrecursos y la transmisión segura de código de terceros para proteger tu página.
Estrategias de mitigación
Estas son algunas estrategias a gran escala para minimizar el impacto de las secuencias de comandos de terceros en el rendimiento y la seguridad de tu sitio:
HTTPS: Los sitios que usan HTTPS no deben depender de terceros que usen HTTP. Para obtener más información, consulta Contenido mixto.
Zona de pruebas: Considera ejecutar secuencias de comandos de terceros en iframes con el atributo
sandbox
para restringir las acciones disponibles para las secuencias de comandos.Política de seguridad del contenido (CSP): Puedes usar encabezados HTTP en la respuesta de tu servidor para definir comportamientos de secuencias de comandos de confianza para tu sitio y detectar y mitigar los efectos de algunos ataques, como secuencias de comandos entre sitios (XSS).
El siguiente es un ejemplo de cómo usar la directiva script-src de CSP para especificar las fuentes de JavaScript permitidas de una página:
// Given this CSP header Content-Security-Policy: script-src
https://example.com/ // The following third-party script will not be loaded or
executed
<script src="https://not-example.com/js/library.js"></script>
Lecturas adicionales
Para obtener más información sobre cómo optimizar JavaScript de terceros, te recomendamos que leas lo siguiente:
- Rendimiento y resiliencia: Pruebas de esfuerzo de terceros
- Cómo agregar interactividad con JavaScript
- Posibles peligros de las secuencias de comandos de terceros
- Cómo las secuencias de comandos de terceros pueden ser ciudadanos de alto rendimiento en la Web
- Por qué la velocidad es importante: magia del CSS
- La paradoja de la cadena de suministro de JavaScript: SRI, CSP y confianza en bibliotecas de terceros
- El CSS de terceros no es seguro
Agradecemos a Kenji Baheux, Jeremy Wagner, Pat Meenan, Philip Walton, Jeff Posnick y Cheney Tsai por sus comentarios.