Skip to main content
Puede utilizar diversas herramientas de análisis de rendimiento para evaluar la eficiencia de su sitio. Consulte las directrices de Kameleoon a continuación para identificar e implementar las mejoras necesarias en función de sus resultados.

​
Compruebe cuándo se carga el snippet

Compruebe el tiempo de la etiqueta engine.js (anteriormente denominada kameleoon.js) después de recargar la página, como se muestra en la captura de pantalla a continuación. Si la métrica started at supera 1 segundo, sitúe el script de Kameleoon más arriba en la etiqueta <head> y establezca fetchpriority="high". Estos cambios garantizan que el script de Kameleoon se cargue en menos de 1 segundo.
Cuando la página se carga por primera vez, el script de Kameleoon tarda más, normalmente menos de 60 milisegundos, porque el navegador lo descarga directamente del CDN. En recargas posteriores, el navegador carga el script desde la caché.
performance

​
Comprobación de la puntuación de rendimiento mediante la extensión de Kameleoon para Chrome

Según la puntuación de rendimiento mostrada en la extensión (vea la captura de pantalla a continuación), lleve a cabo una o varias de estas acciones:
  • Detenga los experimentos o personalizaciones que lleven funcionando más de 2 meses y transfiera el código al código fuente de su sitio en función del resultado del experimento o personalización.
  • Archive los experimentos o personalizaciones que haya detenido.
  • Elimine los objetivos no utilizados, incluido su código si son objetivos personalizados.
  • Elimine los segmentos no utilizados.
  • Elimine los datos personalizados no utilizados.
  • Optimice el Global Custom Script para eliminar todo el código no utilizado u obsoleto.
Para más detalles, consulte este artículo de ayuda sobre la extensión Kameleoon Debug Assistant.
chrome

​
Seguimiento del rendimiento con PageSpeed Insights

La pestaña Performance de las herramientas para desarrolladores del navegador ayuda a analizar el rendimiento de una página web, registrando y visualizando datos clave como los tiempos de carga, el uso de memoria y el consumo de recursos. Proporciona información detallada sobre los procesos de renderizado, scripting y layout en forma de líneas de tiempo y flame charts. Revisar esta información puede ayudar a identificar cuellos de botella, scripts de carga lenta y otros factores que afectan a la velocidad. Google PageSpeed Insights analiza el contenido de una página web y proporciona información sobre el rendimiento y sugerencias de mejora. Ofrece una puntuación y sugerencias basadas en las Core Web Vitals, como el tiempo de carga, la interactividad y la estabilidad visual. El informe presenta sus resultados con métricas como “FCP”, “LCP”, “INP” y “CLS”.
tab
tab2

​
First Contentful Paint

First Contentful Paint (FCP) mide el tiempo entre el inicio de la carga de la página y el momento en que el navegador muestra el contenido de la página en pantalla.
  • Impacto posible: El anti-flicker podría afectar al FCP, ya que retrasa la visualización del primer elemento de la página.
  • Acción: En la mayoría de los casos, elimine el código anti-flicker y utilice en su lugar la etiqueta asíncrona sin anti-flicker. Sin anti-flicker, los visitantes pueden ver la página original antes de que aparezca una variación, lo que puede reducir la precisión de sus resultados.

​
Largest Contentful Paint

Largest Contentful Paint (LCP) mide la velocidad de carga percibida. Marca el punto en la línea de tiempo de carga de la página en el que es probable que se haya cargado el contenido principal de la página.
  • Impacto posible: El anti-flicker podría afectar al LCP, ya que retrasa la visualización del elemento más grande de la página.
  • Acción: Igual que para el FCP.

​
Interaction to Next Paint

Interaction to Next Paint (INP) mide la capacidad de respuesta de la página. Para ofrecer una experiencia de usuario positiva, procure tener un INP inferior a 200 milisegundos.
  • Impacto posible: Si Kameleoon se carga pronto, no debería haber un impacto negativo. Sin embargo, las pruebas que cambian el comportamiento de una interacción pueden afectar a esta métrica.
  • Acción: Puede utilizar la extensión de Kameleoon para Chrome o el código siguiente en la consola para comprobar cuáles son los experimentos / personalizaciones activos en la página correspondiente y encontrar el posible origen del impacto. El siguiente fragmento de código de ejemplo muestra cómo lograrlo:

​
Cumulative Layout Shift

Cumulative Layout Shift (CLS) mide el mayor cambio de posición de un elemento durante el ciclo de vida de la página. Tenga en cuenta que los cambios de layout solo se producen cuando los elementos existentes cambian su posición inicial. Si un nuevo elemento entra en el DOM, o si un elemento existente cambia de tamaño, esto no cuenta como un cambio de layout, siempre que el cambio no provoque una modificación en la posición inicial de otros elementos visibles.
  • Impacto posible: La etiqueta de Kameleoon no tiene impacto en este índice. Los experimentos / personalizaciones, en cambio, pueden tener un impacto negativo si provocan un cambio en la posición inicial de un elemento.
  • Acción: Igual que para el INP.

​
Speed Index (métrica de ContentSquare)

Speed Index mide el tiempo en el que el navegador muestra la mayoría de los elementos gráficos en el viewport inicial.
  • Impacto posible: El anti-flicker podría afectar al Speed Index, ya que puede retrasar la visualización de los elementos en el viewport inicial. Además, si ejecuta experimentos/personalizaciones que realizan cambios en la parte superior de la página, el Speed Index se verá afectado negativamente (aumentará).
  • Acciones: Igual que para el FCP y el INP.

​
Características del script de Kameleoon en un vistazo

  • Snippet asíncrono: Kameleoon carga su script de forma asíncrona desde un CDN fiable (Cloudflare) para garantizar una primera carga de página no bloqueante y utiliza la caché del navegador para acelerar las cargas de página posteriores. Kameleoon mantiene un Service Level Agreement (SLA) superior al 99,99 %.
Asegúrese de tener el atributo async en el script de Kameleoon instalado en su sitio. Consulte el snippet a continuación:
  • Tamaño de script reducido: El archivo de aplicación de Kameleoon, creado con TypeScript, tiene un tamaño de solo 29 KB (comprimido con Brotli), lo que minimiza el tiempo de carga en la primera página.
  • Enfoque de preprocesamiento: Kameleoon genera el script únicamente a partir de los componentes necesarios para su configuración específica, en función de las funcionalidades y opciones que esté utilizando.
  • Motor anti-flickering único: El motor de Kameleoon captura los eventos del DOM en tiempo real y modifica la visualización de los componentes implicados en una variación del experimento antes de que se rendericen por completo.
  • Llamadas de red reducidas: Kameleoon agrupa múltiples eventos de seguimiento en una única llamada beacon, lo que disminuye significativamente el número total de llamadas de red necesarias.
  • Carga de un único script: A diferencia de otras plataformas que requieren múltiples archivos, Kameleoon carga un único script consolidado, lo que reduce el número de solicitudes HTTP.
  • Carga aplazada de experimentos: Kameleoon le permite seleccionar qué experimentos se incluyen en el archivo de aplicación, engine.js (anteriormente denominado kameleoon.js), en el momento de la carga inicial de la página, caso por caso, y aplazar los experimentos no esenciales después de la primera carga.
  • Actualización en tiempo real: Para proporcionar actualizaciones más frecuentes sin que la caché del navegador lo obstaculice, la función Live Update Experiments de Kameleoon actualiza cualquier experimento etiquetado como “LIVE-UPDATE” en menos de un minuto.

​
Mejores prácticas para un rendimiento a largo plazo

Más allá del análisis del rendimiento, se recomienda seguir las mejores prácticas de Kameleoon para garantizar experimentos sostenibles y escalables:

​
FAQ

No. El script de Kameleoon utiliza tecnología de vanguardia para ejecutarse de forma asíncrona (cuando se usa el snippet de instalación asíncrono) y permanece totalmente en caché del navegador durante 90 minutos. Nunca bloquea la carga de la página, ni siquiera durante los raros incidentes de la CDN (99,99% de uptime). De media, el script se carga en menos de 70 ms con una conexión 4G o en condiciones de red más rápidas.Kameleoon reduce aún más el impacto mediante técnicas avanzadas de compresión, combinando TypeScript y Brotli, lo que da como resultado un tamaño base del script de solo 28,4 KB.

​
Entrega por CDN y escalabilidad

El script engine.js se sirve a través de la CDN de Cloudflare, lo que significa que escala automáticamente sin importar el volumen de tráfico de su sitio web. No hay problemas de carga ni de lentitud en ningún nivel de tráfico: la red global de Cloudflare gestiona la entrega, por lo que ni los picos ni el tráfico alto sostenido afectan al rendimiento del script para sus visitantes.

​
Caché

Por defecto, el navegador almacena engine.js en caché durante 90 minutos, lo que minimiza los tiempos de carga repetidos para los visitantes que regresan. Si su caso de uso requiere una duración de caché más corta, puede reducirse hasta tan solo 1 minuto, previa solicitud. Contacte con el soporte de Kameleoon para ajustar esta configuración en su cuenta.

​
Consideraciones importantes

El tamaño del script puede aumentar en función del número de experimentos que ejecute y de su contenido (CSS/JavaScript).Para experimentos o campañas de personalización que no necesiten cargarse de inmediato, use el tag “DELAYED”. Esto retrasa la carga de los experimentos no esenciales hasta después de la primera carga de página. Kameleoon los gestiona de forma inteligente: solo descarga la configuración tras 10 segundos de inactividad o cuando un visitante está segmentado y se le asigna una variación distinta del control. Este enfoque garantiza un impacto mínimo en el rendimiento de carga, a la vez que ofrece toda la funcionalidad para los experimentos priorizados.

​
Solicitudes de tracking y límites de frecuencia

Kameleoon agrupa los eventos de tracking en una única solicitud en lugar de enviar una solicitud por evento, lo que mantiene bajo el número de llamadas de red. Para saber cómo engine.js pone en cola y envía los eventos, consulte Flujo del código: seguimiento. Para saber cómo los SDK agrupan las solicitudes y cómo la Data API aplica los límites de frecuencia, consulte Rate limits.

​
Límites de frecuencia de la Data API

Kameleoon aplica límites de frecuencia a la Data API para proteger la fiabilidad del servicio. Los límites se basan en sus visitantes únicos mensuales (MUV) contractuales y la dirección IP del solicitante. Si supera esos límites, la API devuelve HTTP 429.Estos límites se aplican a todas las solicitudes que llegan a la Data API, incluidas las llamadas de seguimiento que engine.js envía automáticamente y las solicitudes de seguimiento agrupadas que los SDK de Feature Experimentation envían. En entornos donde muchos visitantes comparten una única dirección IP (como oficinas o redes corporativas), los límites basados en IP pueden aplicarse incluso cuando sus MUV totales se mantienen dentro del contrato.Kameleoon detecta automáticamente el tráfico de bots conocidos y lo excluye del cálculo de estos rate limits. Las solicitudes identificadas como procedentes de bots no cuentan para los límites descritos anteriormente.Para integraciones del lado del servidor, puede eliminar los límites basados en IP autenticando sus solicitudes. Si su caso de uso requiere límites más altos, contacte con el soporte de Kameleoon para discutir las opciones.Los límites de frecuencia se aplican a toda su cuenta de cliente, no a proyectos individuales. Si un proyecto genera un número excesivo de solicitudes (por ejemplo, porque una implementación defectuosa crea un bucle que envía eventos de datos personalizados repetidamente), ese proyecto consume el límite compartido de la cuenta y puede causar errores HTTP 429 en todos sus otros proyectos.Para identificar qué proyecto está generando tráfico inesperado, use la página Live events (Insights > Live events). Seleccione cada proyecto por turnos y compare el recuento de eventos de la última hora o de las últimas 24 horas con el volumen esperado. Un proyecto que genera muchos más eventos de los que justifica su volumen de visitantes (por ejemplo, decenas de millones de eventos con un contrato de 100.000 MUV) es probablemente la fuente del problema. Filtre los eventos por tipo para identificar la causa: los eventos de datos personalizados son los más frecuentes, a menudo porque un bucle mal configurado envía la misma variable de datos personalizados, o todas las variables de datos personalizados, en cada carga de página.

​
Escalabilidad de la plataforma

La plataforma de Kameleoon utiliza escalado horizontal, infraestructura con auto-scaling, balanceo de carga y pruebas de carga y estrés periódicas. Para más detalles, consulte ¿Cómo soporta la plataforma de Kameleoon la escalabilidad y la elasticidad?.
Sí, puede retrasar los experimentos no esenciales hasta después de la primera carga de página. Para retrasar un experimento, añada el tag DELAYED a los experimentos que desee diferir. Para más información, consulte la documentación sobre gestión de tags.Kameleoon gestiona de forma inteligente los experimentos etiquetados como “DELAYED”. Solo descarga la configuración tras 10 segundos de inactividad o cuando el visitante está segmentado y se le asigna una variación distinta del control. Céntrese en ofrecer la mejor experiencia de usuario aplazando los tests que consumen muchos recursos.
La plataforma de Kameleoon ofrece alta escalabilidad y elasticidad, garantizando un rendimiento óptimo a medida que crecen los volúmenes de datos. La plataforma gestiona una carga media de 20.000 consultas por segundo con picos de hasta 100.000 consultas. Los factores clave incluyen:
  • Arquitectura escalable: una arquitectura distribuida y modular permite el escalado horizontal.
  • Infraestructura con auto-scaling: la infraestructura basada en la nube escala automáticamente los recursos computacionales.
  • Balanceo de carga: técnicas avanzadas distribuyen el tráfico de forma equitativa entre los servidores.
  • Ingesta y procesamiento de datos: APIs robustas y un data broker gestionan grandes volúmenes de datos de forma eficiente.
  • Tests de escalabilidad: tests de carga y estrés periódicos garantizan que el sistema soporte condiciones extremas.
  • Almacenamiento de datos elástico: el almacenamiento multinivel permite un acceso rápido a los datos y una escalabilidad a largo plazo.