Si optimizaste tu código, pero el sitio todavía se carga demasiado lento, es probable que sea culpa 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 más interconectada. Algunas de ellas incluso pueden ser cruciales para el funcionamiento de tu sitio web o tu flujo de ingresos. Sin embargo, usarlos 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 imprevistas.
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, revisaremos 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?
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 contenido en redes sociales (Facebook, X, LinkedIn, Mastodon)
Incorporaciones del reproductor 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 formato de fecha, animación o bibliotecas funcionales
![ejemplo de un video incorporado de YouTube](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/example-a-youtube-video-c78967c85a13b.jpeg?authuser=7&hl=es-419)
<iframe
width="560"
height="315"
src="https://www.youtube.com/embed/mo8thg5XGV0"
frameborder="0"
allow="autoplay; encrypted-media"
allowfullscreen
>
</iframe>
Lamentablemente, la incorporación de secuencias de comandos de terceros implica que, a menudo, dependemos de que se ejecuten con rapidez y no retrasen nuestras páginas. Las secuencias de comandos de terceros son una causa común de las demoras en el rendimiento causadas por recursos fuera del control del propietario del sitio, incluidos los siguientes problemas:
Activa demasiadas solicitudes de red a varios servidores. Cuantas más solicitudes tenga que hacer un sitio, más tiempo tardará en cargarse.
Enviar demasiado JavaScript que mantiene ocupado el subproceso principal. El exceso de 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 hacen un uso intensivo de la CPU pueden retrasar la interacción del usuario y provocar un agotamiento de la batería.
El envío de videos o archivos de imagen no optimizados de gran tamaño puede consumir datos y costarles 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 compresión de servidores suficiente hace que los recursos se carguen lentamente.
Se bloqueará la visualización de contenido hasta que se complete el procesamiento. Esto también puede ser así para las secuencias de comandos de pruebas A/B asíncronas.
El uso de APIs heredadas conocidas por dañar la experiencia del usuario, como document.write()
Demasiados elementos DOM o selectores CSS costosos.
La inclusión de varias incorporaciones de terceros puede generar que varios frameworks y bibliotecas se extraigan varias veces, desperdiciar recursos y empeorar los problemas de rendimiento existentes.
Las secuencias de comandos de terceros a menudo usan técnicas de incorporación que pueden bloquear window.onload si sus servidores responden con lentitud, incluso si la incorporación usa la función asíncrona o aplazada.
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. Afortunadamente, existen varias soluciones y herramientas para encontrar y corregir problemas con recursos de terceros.
¿Cómo se identifican las secuencias 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. Recomendamos usar herramientas gratuitas de prueba de velocidad web, como las Herramientas para desarrolladores de Chrome, PageSpeed Insights y WebPageTest, para identificar secuencias de comandos costosas. Estas herramientas muestran información de diagnóstico detallada 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 pagetest que muestra
un sitio web real frente a la cantidad de tiempo empleado en cargar](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/waterfall-view-webpagete-35c332733c4dc.jpeg?authuser=7&hl=es-419)
El desglose del dominio de WebPageTest también puede ser útil para visualizar la cantidad de contenido que proviene de orígenes externos. Se desglosa por bytes totales y por cantidad de solicitudes:
![Es el desglose de contenido por dominio (primera vista).
Muestra el porcentaje de solicitudes y bytes para cada servicio de terceros.](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/content-breakdown-domain-f79c0ab40182d.png?authuser=7&hl=es-419)
¿Cómo mido 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 la secuencia de comandos y determina si el 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 rendimiento o participación del usuario.
Auditoría de tiempo de arranque de Lighthouse
La auditoría de tiempo de inicio de JavaScript de Lighthouse destaca las secuencias de comandos que tienen un tiempo costoso de análisis, compilación o evaluación de secuencias de comandos. Esto puede ayudarte a identificar secuencias de comandos de terceros que requieren mucha CPU.
![Lighthouse que muestra compatibilidad con la evaluación
y análisis de secuencias de comandos](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/lighthouse-showing-suppor-8af1a01ba2c3e.png?authuser=7&hl=es-419)
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 que esperan en datos móviles.
![Lighthouse que muestra compatibilidad con cargas útiles
de redes grandes](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/lighthouse-showing-suppor-63ad35702fbc3.png?authuser=7&hl=es-419)
Bloqueo de solicitudes de red de Herramientas para desarrolladores de Chrome
Las Herramientas para desarrolladores de Chrome te permiten ver el comportamiento de tu página cuando una secuencia de comandos, una hoja de estilo o algún otro recurso especificados no están disponibles. Para ello, se usa 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 Red y selecciona Bloquear la URL de solicitud. 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 Herramientas para desarrolladores](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/block-request-urls-the-d-66fa36ce9b253.png?authuser=7&hl=es-419)
Panel de rendimiento de las Herramientas para desarrolladores de Chrome
El panel de rendimiento de las Herramientas para desarrolladores de Chrome ayuda a identificar problemas con el rendimiento web de tu página.
- Haz clic en Grabar.
- Carga tu página. Las Herramientas para desarrolladores muestran un diagrama de cascada que representa cómo tarda tu sitio en cargarse.
- Navega a Bottom-up 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 según el tiempo de carga.
![El panel Performance de Herramientas para desarrolladores muestra la
vista ascendente agrupada por productos (de terceros)](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/devtools-performance-pane-76e2e3248ed5f.png?authuser=7&hl=es-419)
Si deseas obtener más información sobre el uso de las Herramientas para desarrolladores de Chrome para analizar el rendimiento de carga de páginas, consulta Cómo comenzar 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:
- Usa el panel Network para medir cuánto tiempo tarda tu página en cargarse.
- Para emular condiciones reales, te recomendamos activar la regulación de la red y la regulación de la CPU. Es poco probable que los usuarios tengan conexiones de red rápidas y hardware de escritorio que reducen el impacto de secuencias de comandos costosas en condiciones de lab.
- 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 Herramientas para desarrolladores de Chrome para obtener orientación sobre cómo identificar secuencias de comandos costosas).
- Vuelve a cargar la página y mide el tiempo de carga nuevamente.
- Para obtener datos más precisos, se recomienda medir el tiempo de carga al menos tres veces. Esto explica algunas secuencias de comandos de terceros que recuperan diferentes recursos en cada carga de página. Para ayudarte con esto, el Panel de rendimiento de Herramientas para desarrolladores admite varias grabaciones.
Mide el impacto de las secuencias de comandos de terceros con WebPageTest
WebPageTest permite bloquear 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.](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/webpagetest-advanced-sett-e8803075edd46.png?authuser=7&hl=es-419)
Recomendamos el siguiente flujo de trabajo para usar esta función:
- Probar una página sin bloquear a terceros
- Repite la prueba con algunos terceros bloqueados.
- Selecciona los dos resultados de tu Historial de pruebas.
- Haz clic en Comparar.
![WebPageTest muestra la opción Comparar,
lo que te permite comparar dos informes](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/webpagetest-displaying-c-f6c3f4461ff9b.png?authuser=7&hl=es-419)
En la siguiente imagen, se muestra la función de tira de película de WebPageTest en la que se comparan las secuencias de carga para páginas con y sin recursos activos de terceros. Te recomendamos que verifiques esta opción para realizar pruebas de orígenes individuales de terceros a fin de determinar qué dominios tienen un mayor impacto en el rendimiento de tu página.
![Tira de película WebPageTest que muestra el impacto
de cargar un sitio con y sin terceros inhabilitados](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/webpagetest-filmstrip-dis-c4ad9edb942af.png?authuser=7&hl=es-419)
WebPageTest también admite dos comandos que operan en el nivel del DNS para bloquear dominios:
blockDomains
toma 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 una falla completa para cargar un recurso. A diferencia del bloqueo de dominio, el tiempo de espera de SPOF se agota lentamente, lo que puede ser útil para probar el comportamiento de sus páginas cuando los servicios de terceros se encuentran muy cargados o no están disponibles temporalmente.
![Configuración avanzada de WebPageTest > SPOF > hosts que fallan](/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/webpagetest-advanced-sett-698d1c0664b84.png)
Cómo detectar iframes costosos con tareas largas
Cuando las secuencias de comandos de 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 lentamente o que disminuyan los 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 entradas 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 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 carga la 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 del documento. - 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 las 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 se analiza el documento HTML. Cuando se termina de descargar la secuencia de comandos, se bloquea el análisis mientras se ejecuta.defer
hace que el navegador descargue la secuencia de comandos de forma asíncrona mientras se analiza el documento HTML y, luego, espera ejecutar la secuencia de comandos hasta que se complete el análisis del documento.
Usa siempre async
o defer
para 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 para algunas secuencias de comandos estadísticas. Usa defer
para recursos menos críticos, como los videos que se renderizan en un nivel más bajo en la página que el que el usuario verá inicialmente.
Si el rendimiento es tu preocupación principal, te recomendamos que esperes para agregar secuencias de comandos asíncronas hasta después de 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
ni defer
, en especial aquellas que son partes fundamentales del sitio. Esto incluye bibliotecas de IU o frameworks de red de distribución de contenidos (CDN) que tu sitio no puede funcionar sin ellos.
Otras secuencias de comandos simplemente no funcionan si se cargan de forma asíncrona. Consulta la documentación de las secuencias de comandos que utilices y reemplaza las secuencias de comandos que no se puedan cargar de forma asíncrona por alternativas que sí. Ten en cuenta que algunos terceros recomiendan ejecutar sus secuencias de comandos de forma síncrona, incluso si funcionarían de forma igualitaria 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 se ralentice la carga de la página.
Usa las sugerencias de recursos para reducir el tiempo de configuración de la conexión
Establecer conexiones a orígenes de terceros puede llevar mucho tiempo, en especial en redes lentas, porque las solicitudes de red tienen varios componentes complejos, incluidos los redireccionamientos y las búsquedas de DNS. Puedes usar Resource Hints, como , para realizar búsquedas de DNS en 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 más 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 ida y vuelta de TCP y controla las negociaciones de TLS. Estos otros pasos pueden ser muy lentos, ya que requieren la verificación de 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 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
, así que no intentes adjuntar funciones críticas a onload
.
Chrome también es compatible con la Política de Permisos (anteriormente, Política de Funciones), un conjunto de políticas que permiten inhabilitar 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 por cuenta propia 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, quizás puedas alojarla por tu cuenta.
Sin embargo, el hosting propio presenta algunos problemas, en especial cuando se trata de actualizar secuencias de comandos. Las secuencias de comandos autoalojadas no recibirán actualizaciones automáticas para los cambios de API ni las correcciones de seguridad, lo que puede provocar pérdidas de ingresos o problemas de seguridad hasta que puedas actualizar tu secuencia de comandos de forma manual.
Como alternativa, puedes almacenar en caché secuencias de comandos de terceros con service worker 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 llegue a un momento clave del usuario.
Realiza pruebas A/B con muestras más pequeñas de usuarios
Las pruebas A/B (o pruebas A/B) son una técnica que permite experimentar con dos versiones de una página para analizar la experiencia y el comportamiento del usuario. Permite 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 Analytics qué versión proporciona un mejor porcentaje de conversiones.
Sin embargo, de forma intencional, las pruebas A/B retrasan la renderización para decidir qué experimento debe estar activo. A menudo, JavaScript se usa 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 el procesamiento de la página, te recomendamos enviar tus secuencias de comandos de pruebas A/B a una muestra más pequeña de tu base de usuarios y ejecutar el código que decide qué versión de la página se mostrará en el servidor.
Recursos de terceros de carga diferida
Los recursos de terceros incorporados, como anuncios y videos, pueden contribuir en gran medida a una velocidad de 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 a que se publiquen anuncios en el pie de página hasta que el usuario se desplace lo suficiente 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.
![Una ilustración en la que se muestran los recursos que son fundamentales para la experiencia de la mitad superior de la página y aquellos que son menos críticos y que se pueden cargar de forma diferida](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/an-illustration-showing-a-f0d6b6d27f361.png?authuser=7&hl=es-419)
Ten cuidado con la carga diferida de recursos, ya que, a menudo, involucra código JavaScript que puede verse afectado por conexiones de red inestables.
En su documentación oficial, DoubleClick puede encontrar orientación sobre la carga diferida de anuncios.
Carga diferida eficiente con Intersection Observer
Históricamente, los métodos para detectar si un elemento es visible en el viewport con fines de carga diferida han sido propensos a errores y, a menudo, ralentizan el navegador. Estos métodos ineficientes suelen detectar eventos de desplazamiento o resize y, luego, usan las APIs de DOM como getBoundingClientRect() para calcular dónde están relacionados los elementos con el viewport.
IntersectionObserver es una API de 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 compatibilidad opcional con IntersectionObserver.
Análisis de carga diferida
Si aplazas la carga de tus secuencias de comandos de Analytics durante demasiado tiempo, es posible que pierdas datos valiosos de estadísticas. Por suerte, hay estrategias disponibles para inicializar el análisis de forma diferida mientras se retienen los datos iniciales de carga de la página.
En la entrada de blog de Phil Walton, The Google Analytics Setup I Use on Every Site I Build, se aborda 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 manera 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 manera inconsistente y sus fallas son difíciles de depurar.
La solución de 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 para problemas de uso de document.write()
:
![Advertencias de la consola de Herramientas para desarrolladores en las que se destacan los incumplimientos de una incorporación de terceros con document.write()](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/devtools-console-warnings-8a4bc282f4492.png?authuser=7&hl=es-419)
document.write()
.Si recibes este error, puedes verificar el uso de document.write()
en tu sitio. Para ello, busca encabezados HTTP enviados a tu navegador.
Lighthouse también puede destacar cualquier secuencia de comandos de terceros que todavía usando document.write()
.
![Prácticas recomendadas de Lighthouse para marcar el uso
de document.write()](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/lighthouse-best-practices-bc22b2c90d6af.png?authuser=7&hl=es-419)
document.write()
.Utiliza Tag Manager 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 con rapidez, te recomendamos que uses un administrador de etiquetas, como Google Tag Manager (GTM). GTM te permite implementar etiquetas de manera asíncrona para que no se bloqueen la carga entre sí, reduce la cantidad de llamadas de red que un navegador necesita para ejecutar etiquetas y recopila datos de etiquetas en su IU de capa de datos.
Riesgos del uso de administradores de etiquetas
Si bien los administradores de etiquetas están diseñados para optimizar la carga de páginas, usarlos sin cuidado 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 del código para responder a los eventos rápidamente.
- Cualquier persona con credenciales y acceso puede agregar JavaScript a tu Administrador de etiquetas. Esto no solo puede aumentar la cantidad de costosas solicitudes de red necesarias para cargar tu página, sino que también puede presentar riesgos de seguridad y otros problemas de rendimiento derivados de 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 diversas maneras para dañar 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 deficientemente con tu código.
- Las actualizaciones inesperadas pueden causar cambios rotundos.
- El código de terceros se puede modificar durante el envío para que se comporte de manera diferente entre las pruebas y la implementación de tu página.
Recomendamos realizar auditorías frecuentes de las secuencias de comandos de terceros que cargues para verificar la existencia de personas que actúan de mala fe. También puedes implementar autopruebas, integridad de subrecursos y 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 utilicen 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 confiables de secuencias de comandos en tu sitio, y detectar y mitigar los efectos de algunos ataques, como la secuencia 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 JavaScript de terceros, te recomendamos que leas lo siguiente:
- Rendimiento y resiliencia: terceros que realizan pruebas de estrés
- Cómo agregar interactividad con JavaScript
- Posibles peligros con secuencias de comandos de terceros
- Cómo las secuencias de comandos de terceros pueden tener un buen rendimiento en la Web
- Por qué es importante que sea rápido: Magia de los CSS
- La paradoja de la cadena de suministro de JavaScript: SRI, CSP y confianza en las bibliotecas de terceros
- El CSS de terceros no es seguro
Gracias a Kenji Baheux, Jeremy Wagner, Pat Meenan, Philip Walton, Jeff Posnick y Cheney Tsai por sus opiniones.