Carga JavaScript de terceros

Arthur Evans

Si optimizaste tu código, pero tu sitio aún se carga con demasiada lentitud, es probable que la culpa sea de 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 esté más interconectada. Algunos de ellos incluso podrían ser cruciales para la función o el flujo de ingresos de tu sitio web. Sin embargo, usarlas es riesgoso:

  • 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 renderización crítica de tu sitio. En esta guía, explicaremos cómo encontrar y corregir problemas relacionados con la carga de JavaScript de terceros y minimizar los riesgos para los usuarios.

¿Qué son las secuencias de comandos de terceros?

El JavaScript de terceros suele hacer 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 en redes sociales (Facebook, X, LinkedIn y Mastodon)

  • Incrustaciones 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 auxiliares, como las de formato de fecha, animación o funcionales

ejemplo de un video de YouTube incorporado
Un ejemplo de incorporación de video de YouTube que se puede agregar a una página con el siguiente código.
<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 que provocan los recursos que están fuera del control del propietario del sitio, incluidos los siguientes problemas:

  • Se activan demasiadas solicitudes de red a varios servidores. Cuantas más solicitudes deba realizar un sitio, más tiempo puede tardar en cargarse.

  • Enviar demasiado código JavaScript que mantiene ocupado el subproceso principal Demasiado 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 consumen mucha CPU pueden retrasar la interacción del usuario y agotar la batería.

  • Enviar archivos de imagen o videos grandes y sin optimizar 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.

  • Almacenamiento en caché HTTP insuficiente, lo que obliga al navegador a enviar más solicitudes de red para recuperar recursos

  • La falta de una compresión del servidor suficiente hace que los recursos se carguen con lentitud.

  • Bloquean la visualización del contenido hasta que se completa el procesamiento. Esto también puede ocurrir con las secuencias de comandos de pruebas A/B asíncronas.

  • Uso de APIs heredadas que se sabe que perjudican la experiencia del usuario, como document.write().

  • Elementos del DOM excesivos o selectores CSS costosos

  • Incluir varios elementos incorporados de terceros puede hacer 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 las secuencias de comandos de terceros puede depender de tu sitio y de tu capacidad para configurar cómo cargas el código de terceros. Afortunadamente, existen varias soluciones y herramientas para encontrar y corregir problemas con los recursos de terceros.

¿Cómo se identifican las secuencias de comandos de terceros en una página?

Identificar las secuencias de comandos de terceros en tu sitio y determinar su impacto en el rendimiento es el primer paso para optimizarlas. Te recomendamos que uses herramientas gratuitas de test de velocidad web, como las 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 en ejecutarse.

La vista de 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.

Vista de cascada de WebPageTest que muestra un sitio web real en comparación con la cantidad de tiempo que se tarda en cargar las secuencias de comandos de seguimiento
Las secuencias de comandos de esta página tardan más en cargarse que la página en sí.

El desglose de dominios de WebPageTest también puede ser útil para visualizar cuánto contenido proviene de orígenes de terceros. Se desglosa por el total de bytes y la cantidad de solicitudes:

desglose del contenido por dominio (primera vista).
Muestra el porcentaje de solicitudes y bytes para cada tercero.
Los gráficos de desglose de dominios muestran qué cantidad del contenido de una página proviene de terceros.

¿Cómo puedo medir el impacto de las secuencias 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 con su impacto en las métricas clave de participación o rendimiento de los usuarios.

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 las secuencias de comandos de terceros que consumen mucha CPU.

Lighthouse muestra compatibilidad con la evaluación y el análisis de secuencias de comandos
La auditoría del tiempo de inicio muestra qué secuencias de comandos tardan más en cargarse.

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 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.

Lighthouse muestra compatibilidad con cargas útiles de red grandes
La auditoría de cargas útiles de red muestra qué solicitudes de red tardan más y recuperan la mayor cantidad de datos.

Bloqueo de solicitudes de red de las Herramientas para desarrolladores de Chrome

Las Herramientas para desarrolladores de Chrome te permiten ver cómo se comporta tu página cuando una secuencia de comandos, una hoja de estilo o algún otro recurso especificado no están disponibles. 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 redes y selecciona Block Request URL. Luego, se mostrará una pestaña de bloqueo de solicitudes en el panel lateral de Herramientas para desarrolladores, lo que te permitirá administrar las solicitudes que se bloquearon.

Bloquea las URLs de solicitud desde el panel de red de las Herramientas para desarrolladores
Bloquea solicitudes de red individuales para ver cómo se comporta tu página sin ellas.

Panel de rendimiento de las Herramientas para desarrolladores de Chrome

El panel Rendimiento de las Herramientas para desarrolladores de Chrome ayuda a identificar problemas con el rendimiento web de tu página.

  1. Haz clic en Grabar.
  2. Carga tu página. Las Herramientas para desarrolladores muestran un diagrama de cascada que representa cómo tu sitio invierte su tiempo de carga.
  3. Navega a Bottom-up en la parte inferior del panel Performance.
  4. Haz clic en Agrupar por producto y ordena las secuencias de comandos de terceros de tu página por tiempo de carga.
Panel de rendimiento de Herramientas para desarrolladores que muestra la vista ascendente agrupada por productos (de terceros)
Secuencias de comandos de terceros ordenadas por producto, comenzando por el tiempo de carga más largo.

Para obtener más información sobre cómo usar las Herramientas para desarrolladores de Chrome para analizar el rendimiento de la carga de páginas, consulta Comienza a analizar el rendimiento del tiempo de ejecución.

A continuación, se muestra nuestro flujo de trabajo recomendado para medir el impacto de las secuencias de comandos de terceros:

  1. Usa el panel de redes para medir cuánto tiempo tarda en cargarse tu página.
    • Para emular las condiciones del mundo real, te recomendamos que actives la limitación de la red y la limitación de la CPU. Es poco probable que tus usuarios tengan las conexiones de red rápidas y el hardware de escritorio que reducen el impacto de las secuencias de comandos costosas en condiciones de laboratorio.
  2. Bloquea las URLs o los dominios responsables de las secuencias de comandos de terceros que crees que son un problema (consulta el panel de rendimiento de las Herramientas para desarrolladores de Chrome para obtener orientación sobre cómo identificar secuencias de comandos costosas).
  3. Vuelve a cargar la página y mide el tiempo de carga nuevamente.
    • 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 recursos diferentes en cada carga de página. Para ayudarte con esto, el panel Rendimiento de DevTools admite varias grabaciones.

Mide el impacto de las secuencias de comandos de terceros con WebPageTest

WebPageTest admite el bloqueo de la carga de solicitudes individuales para medir su impacto en Configuración avanzada > Bloquear. Usa esta función para especificar una lista de dominios que se deben bloquear, como los dominios de publicidad.

Configuración avanzada de WebPageTest < Bloquear.
Muestra un área de texto para especificar los dominios que se bloquearán.
En este panel, enumera los dominios que quieres bloquear.

Te recomendamos el siguiente flujo de trabajo para usar esta función:

  1. Prueba una página sin bloquear a terceros.
  2. Repite la prueba con algunos terceros bloqueados.
  3. Selecciona los dos resultados de tu Historial de pruebas.
  4. Haz clic en Comparar.
WebPageTest muestra la opción de comparación,
que te permite comparar dos informes
Selecciona los resultados de la prueba de carga que quieres comparar.

En la siguiente imagen, se muestra la función de tira de película de WebPageTest, que compara las secuencias de carga de las páginas con y sin recursos de terceros activos. Te recomendamos que verifiques esto para realizar pruebas de orígenes de terceros individuales y determinar qué dominios afectan más el rendimiento de tu página.

Tira de película de WebPageTest que muestra el impacto
de cargar un sitio con y sin terceros inhabilitados
El impacto de bloquear recursos de terceros, de Using WebPageTest To Measure The Impact Of Third-Party Tags de Andy Davies.

WebPageTest también admite dos comandos que operan a nivel de DNS para bloquear dominios:

  • blockDomains acepta una lista de dominios que se deben 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 permite simular un tiempo de espera o un error completo para cargar un recurso. A diferencia del bloqueo de dominios, el SPOF agota el tiempo de espera lentamente, lo que puede ser útil para probar cómo se comportan tus páginas cuando los servicios de terceros tienen una carga pesada o no están disponibles temporalmente.

Configuración avanzada de WebPageTest > SPOF > hosts
que fallarán
Usa la función de prueba de SPOF para simular la falla de dominios específicos.

Detecta iframes costosos con tareas largas

Cuando las secuencias de comandos en iframes de terceros tardan mucho tiempo 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 JavaScript PerformanceObserver para observar las entradas de longtask. Estas entradas contienen una propiedad de atribución que puedes usar para determinar qué contexto de marco causó la tarea larga.

El siguiente código registra las entradas de 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 o defer para evitar que se bloquee el análisis del documento.
  • Si el servidor de terceros es lento, considera alojar el guion 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 los 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, pasar la secuencia de comandos 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 continúa analizando el documento HTML. Cuando la secuencia de comandos termina de descargarse, el análisis se bloquea mientras se ejecuta la secuencia de comandos.

  • 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 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 el rendimiento es tu principal preocupación, te recomendamos que esperes para agregar secuencias de comandos asíncronas hasta que se cargue el contenido crítico de tu página. No recomendamos usar async para bibliotecas esenciales, como jQuery.

Algunas secuencias de comandos se deben cargar sin async ni defer, en especial las que son partes fundamentales de tu sitio. Estas incluyen bibliotecas de IU o frameworks de red de distribución de contenidos (CDN) sin los que tu sitio no puede funcionar.

Otras secuencias de comandos simplemente no funcionan si se cargan de forma asíncrona. Consulta la documentación de las secuencias de comandos que usas y reemplaza las que no se puedan cargar de forma asíncrona por alternativas que sí lo permitan. Ten en cuenta que algunos terceros recomiendan ejecutar sus secuencias de comandos de forma síncrona, incluso si funcionan 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 las 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, como búsquedas de DNS y redireccionamientos. Puedes usar sugerencias de recursos como para realizar búsquedas de DNS de 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 con mayor rapidez más adelante:

<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 viajes 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 preconexión 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 bloquea 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 bloquea el evento onload, por lo que debes intentar 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 que un desarrollador inhabilite de forma selectiva el acceso a ciertas funciones del navegador. Puedes usarla para evitar que el contenido de terceros introduzca comportamientos no deseados en un sitio.

Aloja de forma autónoma las secuencias de comandos de terceros

Si quieres tener más control sobre cómo se carga una secuencia de comandos crítica, por ejemplo, para reducir el tiempo de DNS o mejorar los encabezados de almacenamiento en caché HTTP, puedes alojarla tú mismo.

Sin embargo, el hosting propio tiene sus propios problemas, en especial cuando se trata de actualizar secuencias de comandos. Las secuencias de comandos alojadas de forma independiente no recibirán actualizaciones automáticas para los cambios de la API ni las correcciones de seguridad, lo que puede provocar 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é las secuencias de comandos de terceros con service workers para tener más control sobre la frecuencia con la que se recuperan las secuencias de comandos de la red. También puedes usar service workers para crear estrategias de carga que limiten las solicitudes de terceros no esenciales hasta que tu página alcance un momento clave para el usuario.

Realiza pruebas A/B con 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 con el objetivo de analizar la experiencia y el comportamiento de los usuarios. Hace que las versiones de la página estén disponibles para 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 que ejecutes el código que decide qué versión de la página se mostrará en el servidor.

Carga recursos de terceros de forma diferida

Los recursos de terceros incorporados, como los anuncios y los videos, pueden ser factores principales de la velocidad de la página lenta cuando se crean de forma deficiente. La carga diferida se puede usar para cargar recursos incorporados solo cuando sea necesario, por ejemplo, esperar para publicar anuncios en el pie de página hasta que el usuario se desplace lo suficiente para verlos. También puedes cargar de forma diferida el contenido de terceros después de que se cargue el contenido principal de la página, pero antes de que el usuario interactúe con ella.

Una ilustración que muestra los recursos que son fundamentales para la experiencia de la mitad superior de la página y los que son menos importantes y se pueden cargar de forma diferida.
Puedes cargar de forma diferida los recursos que el usuario no verá de inmediato cuando se cargue la página.

Ten cuidado cuando cargues recursos de forma diferida, ya que suele implicar 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 han sido propensos a errores y, a menudo, ralentizan el navegador. Estos métodos ineficientes suelen escuchar eventos de desplazamiento o cambio de tamaño y, luego, usan APIs de DOM, como getBoundingClientRect(), para calcular dónde están los elementos en relación con el viewport.

IntersectionObserver es una API del navegador que permite que los propietarios de páginas detecten de manera eficiente cuando un elemento observado entra o sale del viewport del navegador. LazySizes también tiene compatibilidad opcional con IntersectionObserver.

Carga diferida de Analytics

Si aplazas la carga de tus secuencias de comandos de estadísticas durante demasiado tiempo, puedes perder datos valiosos de estadísticas. Afortunadamente, existen estrategias disponibles para inicializar las estadísticas de forma diferida y, al mismo tiempo, retener los datos de carga de página iniciales.

La entrada de blog de Phil Walton The Google Analytics Setup I Use on Every Site I Build abarca una de esas estrategias para Google Analytics.

Carga secuencias de comandos de terceros de forma segura

En esta sección, se proporcionan instrucciones 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 los 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 forma 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():

Advertencias de la consola de Herramientas para desarrolladores que destacan
los incumplimientos de un elemento incorporado de terceros que usa document.write()
Uso de las marcas de las Herramientas para desarrolladores de Chrome document.write().

Si recibes este error, puedes verificar si tu sitio usa document.write() buscando los encabezados HTTP enviados a tu navegador. Lighthouse también puede destacar cualquier secuencia de comandos de terceros que aún use document.write().

Auditoría de prácticas recomendadas de Lighthouse que marca el uso de document.write()
Un informe de Lighthouse que muestra qué secuencias de comandos usan document.write().

Usa los Tag Manager con cuidado

Una etiqueta es un fragmento de código que permite que los equipos de marketing digital recopilen datos, establezcan cookies o integren 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 tus usuarios se vuelve más difícil a medida que se agregan más etiquetas.

Para que la carga de página sea rápida, 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í durante la carga, reduce la cantidad de llamadas de red que necesita un navegador para ejecutar etiquetas y recopila datos de etiquetas en su IU de la capa de datos.

Riesgos de usar administradores de etiquetas

Aunque los administradores de etiquetas están diseñados para agilizar la carga de páginas, usarlos de forma descuidada puede ralentizarla de las siguientes maneras:

  • La presencia de una cantidad excesiva de etiquetas y objetos de escucha de eventos automáticos en tu Tag Manager hace que el navegador realice más solicitudes de red de las que necesitaría de otro modo 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 que se necesitan para cargar tu página, sino que también puede presentar riesgos de seguridad y otros problemas de rendimiento de las secuencias de comandos innecesarias. Para reducir estos riesgos, te recomendamos limitar el acceso a tu Tag Manager.

Evita las secuencias de comandos que contaminen el alcance global

Las secuencias de comandos de terceros pueden comportarse de todo tipo de formas que dañen tu página de manera inesperada:

  • Las secuencias de comandos que cargan dependencias de JavaScript pueden contaminar el alcance global con código que interactúa de forma incorrecta 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 verificar si hay agentes maliciosos. También puedes implementar la autoprueba, la integridad de subrecursos y la transmisión segura de código de terceros para mantener tu página segura.

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.

  • Entorno 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 las secuencias de comandos entre sitios (XSS).

A continuación, se muestra un ejemplo de cómo usar la directiva script-src de la 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 el código JavaScript de terceros, te recomendamos que leas lo siguiente:

Agradecemos a Kenji Baheux, Jeremy Wagner, Pat Meenan, Philip Walton, Jeff Posnick y Cheney Tsai por sus revisiones.