performance - google analytics academy

¿Google Analytics tiene una sobrecarga de rendimiento? (15)

¿En qué medida afecta Google Analytics el rendimiento?

Estoy buscando lo siguiente:

Puntos de referencia (incluidos tiempos de respuesta / tiempos de carga de página, etc.)
Enlaces o resultados a puntos de referencia similares

Un (posible) método para probar Google Analytics (GA) en su sitio:

Sirve ga.js (el archivo JavaScript de Google Analytics) desde tu propio servidor.
Actualización de Google Daily (prueba 1) y semanal (prueba 2).

Me interesaría ver cómo esto reduce la comunicación entre el servidor web del cliente y el servidor GA.

¿Alguien ha realizado alguna de estas pruebas? Si es así, ¿puedes proporcionar tus resultados? Si no es así, ¿alguien tiene un método mejor para probar el rendimiento alcanzado (o la falta de él) para usar GA?

Bueno, he buscado, investigado y explayado ampliamente en la red. Pero no he encontrado ningún dato estadístico que afirme a favor o en contra de la premisa.

Sin embargo, este extracto de http://www.ga-experts.com afirma que es un mito que GA desacelera su sitio web.

Err, bueno, tal vez un poco, pero estamos hablando de milisegundos. GA funciona mediante el etiquetado de páginas, y cada vez que agrega más contenido a una página web, aumentará los tiempos de carga. Sin embargo, si sigue las mejores prácticas (agregando la etiqueta antes de la etiqueta </body> ), su página se cargará primero. Además, tenga en cuenta que cualquier paquete de análisis web basado en etiquetas de página (que es la mayoría) funcionará de la misma manera

De las respuestas anteriores y de todas las otras fuentes, lo que siento es que cualquiera que sea la ralentización que cause, no será percibida por el usuario, ya que el Script se incluye en la parte inferior de la página. Pero si hablamos de cargas de página completas podríamos decir que ralentiza el tiempo de carga de la página.

Por favor, publique más información si tiene y DATOS si tiene alguno.

Cargar cualquier javascript adicional en su página aumentará el tiempo de descarga desde la perspectiva del cliente. Puede mejorar esto al cargarlo en la parte inferior de la página para que su página se represente aunque GA no esté cargado. Evitaría el almacenamiento en caché porque perdería la ventaja de la caché del cliente para su página. Si el cliente lo almacena en caché desde alguna otra página, la solicitud de su página se completará desde el propio cliente. Si lo cambia para cargar desde su sitio, requerirá una descarga incluso si el cliente ya tiene el código (lo cual es probable). Agregar una tarea a sus procesos de software para evitar cargar el archivo de Google parece injustificado para lo que puede ser una optimización innecesaria. Sería difícil probar esto, ya que siempre funcionaría más rápido a nivel local, pero lo que realmente importa es qué tan rápido funcione para sus clientes. Si decide evaluar el mantenimiento local, asegúrese de probarlo desde la conexión a Internet de su hogar, no de la máquina que se encuentra junto al servidor en su rack.

Desde mi propia experiencia, ha agregado que Google-Analytics no ha cambiado los tiempos de carga.

Según FireBug, se carga en menos de un segundo (648MS avg), y de acuerdo con eso, parte de mi otra prueba ~ 60% - 80% de ese tiempo fue la transferencia de datos desde el servidor, que por supuesto variará de un usuario a otro.

No creo de manera preliminar que el almacenamiento en caché del código analítico localmente cambie los tiempos de carga mucho, por las razones anteriores.

Utilizo Google-Analytics en más de 40 sitios web sin que sea la causa de ninguna, incluso pequeña, desaceleración, la mayor cantidad de tiempo dedicado a obtener las imágenes que, debido a sus tamaños típicos, es comprensible.

Hay algunas excelentes diapositivas de Steve Souders (experto en rendimiento del lado del cliente) sobre:

Diferentes técnicas para cargar archivos JavaScript externos en paralelo
su efecto sobre el tiempo de carga y la representación de la página
qué tipo de indicadores "en progreso" muestra el navegador (por ejemplo, "cargando" en la barra de estado, cursor del reloj de arena).

Hay dos aspectos en esto.

Descarga de scripts de Analytics (y un gif)
Ejecución de scripts descargados

El tiempo de descarga es casi siempre inferior a 100 ms, lo cual es aceptable.

Aquí viene el giro.

la ejecución de analytics.js 250ms
remarketing (si está habilitado) 300ms
demográfico (si está habilitado) 200ms

Entonces, la analítica con remarketing toma en promedio 750 ms. Siento que este es un gran número cuando se trata de gastos generales de rendimiento.

La forma común de implementar GA es poner el JS en la parte inferior de la página. Esto significa que el resto de su DOM puede cargarse antes de que el navegador siquiera piense en acceder a Google. Esto debería mantener las cosas ágiles.

No recomendaría el almacenamiento en caché del archivo JS.

Puede que ya esté en la caché de los usuarios (una probabilidad bastante alta si usan mucho Internet).
Co-hosting significaría que su servidor necesitará innecesariamente muchas más solicitudes, lo que podría ralentizar sus sistemas principales.
Los navegadores están limitados en la cantidad de solicitudes que enviarán a un servidor a la vez, por lo que si usa GA JS en su dominio, probablemente le tome más tiempo procesarlo.
Los servidores de Google son mejores que los tuyos.

La pregunta es si Google Analytics hará que su sitio se desacelere y la respuesta es sí. En este momento, al momento de escribir este artículo, Google-Analytics.com no funciona, por lo que los sitios que lo tienen en sus páginas no cargarán las páginas, así que sí, puede disminuir la velocidad y hacer que su sitio ni siquiera se cargue. No es común que google-analytics.com tenga un tiempo tan largo que en este momento ha sido de más de 10 minutos, pero solo muestra que es posible.

Nada notable.

La llamada a Google (incluida la búsqueda de DNS, cargando el Javascript si aún no está almacenado en la memoria caché y las propias llamadas del rastreador) debería ser realizada por el navegador del cliente en un hilo separado para cargar su página. Ciertamente, la búsqueda DNS será realizada por el sistema subyacente y, hasta donde lo conozco, no contará como una búsqueda dentro del navegador (los navegadores tienen un límite en el número de hilos de solicitud que usarán por sitio).

Más allá de eso, el navegador cargará el script de Google en paralelo junto con todos los demás recursos integrados, por lo que es posible que obtengas un aumento extremadamente leve en el tiempo que se tarda en descargar todo, en el peor de los casos (estamos hablando del orden de milisegundos, inadmisible. Si el navegador carga la secuencia de comandos de Google, o no tiene muchos recursos externos en su página, o si el navegador almacena los recursos externos de su página, o si el navegador almacena la secuencia de comandos de Google ( muy probable) entonces no verá ninguna diferencia. Es absolutamente trivial en general, el mismo efecto que pegar una imagen extra pequeña en su página, hablando en términos generales.

Casi el único momento en que podría hacer una diferencia concreta es si tiene algún comportamiento que active el evento onLoad (que espera a que se carguen los recursos externos) y que los servidores de Google estén inactivos / lentos. Es poco probable que esto último ocurra a menudo, pero si este fuera el caso, entonces el onLoad incluso no se disparará hasta que se descargue el script. Puede solucionar esto de todos modos mediante el uso de varios eventos "cuando DOM cargado", que generalmente son más receptivos ya que no tiene que esperar a que sus propios scripts / imágenes se carguen de esta manera tampoco.

Si realmente te preocupan los efectos sobre el tiempo de carga de la página, eche un vistazo a la sección "Velocidad neta" de Firebug , que cuantificará esto y le dibujará un gráfico bonito. Te animo a que hagas esto por ti mismo de todos modos, ya que incluso si otras personas te dan las cifras y puntos de referencia que solicitas, será completamente diferente para tu propio sitio.

No creo que esto sea lo que estás buscando, pero ¿para qué te preocupa el rendimiento?

Si es su servidor ... obviamente no hay impacto, ya que reside en los servidores de Google.

Si son tus usuarios los que te preocupan entonces tampoco hay impacto. Siempre que lo coloque justo encima de la etiqueta del cuerpo, sus usuarios no recibirán nada más lento de lo que harían antes ... el script se carga por última vez y no tiene ningún efecto en la apariencia del usuario. Por lo tanto, esencialmente no espera nada e incluso continúa navegando por la página sin darse cuenta de que todavía se está cargando.

No hay / sobrecarga de sitio mínima en el lado del servidor.

El HTML para Google Analytics es tres líneas de javascript que coloca en la parte inferior de su página web. No es nada en realidad, y no consume más recursos del servidor que un aviso de copyright.

En el lado del cliente, la página puede demorar un poco (hasta un par de segundos) en terminar de mostrar una página. Sin embargo, en mi experiencia, la única parte de la página que no se carga es Google, por lo que los usuarios pueden ver su página perfectamente bien. Usted acaba de palpitar por un poco más de tiempo en la parte superior de la página.

(Nota: debe colocar su bloque de código de Google Analytics en la parte inferior de las páginas servidas para que así sea. No sé qué sucede si el bloque de código se coloca en la parte superior de su HTML)

No he hecho ninguna prueba automática sofisticada o un crucigrama de números programáticos, pero usando Firefox viejo y bueno con el plugin Firebug y un par de variables JS para contar la diferencia de tiempo antes y después de ejecutar todo el código GA, esto es lo que encontré.

Se descargan dos cosas:

ga.js es el archivo JavaScript que contiene el código. Esto es de 9 kb, por lo que la descarga inicial es insignificante y el nombre del archivo no es dinámico, por lo que se almacena en caché después de la primera solicitud.
un archivo gif de 35 bytes con una URL dinámica (a través de args de cadena de consulta), por lo que se solicita siempre. 35 bytes es una descarga despreciable también (Firebug dice que me llevó 70ms dl).

En cuanto al tiempo de ejecución, mi primera solicitud con una memoria caché limpia del navegador fue de aproximadamente 330ms cada vez y las solicitudes posteriores estuvieron entre 35 y 130 ms.

Puede alojar ga.js en sus servidores sin ningún problema, pero la idea es que los usuarios tengan el archivo ga.js en la memoria caché de algún otro sitio que hayan visitado. Así que la descarga de ga.js, porque es muy popular, agrega muy poca sobrecarga en muchos casos (es decir, ya ha sido almacenada en la memoria caché).

Además, las búsquedas de DNS no cuestan lo mismo en diferentes lugares debido a la topología de red. El comportamiento de almacenamiento en caché cambiará según si los usuarios usan otros sitios que incluyen ga.js o no.

Una vez que se ha cargado el javascript, el ga.js se comunica con los servidores de Google, pero ese es un proceso asincrónico.

Espero que esto ayude.

Realmente depende del día. Solo estoy agregando esto a un blog. Estoy en California, muy cerca de sus centros de datos principales, en un DSL de negocios de latencia rápida y rápida, en un i5 overclockeado con mucha memoria RAM con un kernel de Linux reciente y Firefox estable.

aquí hay una carga de página de muestra:

google-analytics solo agregó 5 segundos solo de tiempo de descarga de red ... ¡para obtener 15Kb!

Puedes ver que blogger.com recibió 34 Kb en 300 milisegundos. ¡Eso es 32 veces más rápido!

Además, observe cómo la línea roja (que representa el evento onLoad, es decir, no hay más secuencias de comandos ejecutándose en la página y el navegador puede detener los indicadores de carga / spinings / etc.) ... mire qué tan a la derecha está es. eso es probablemente 3 segundos de procesamiento de basura javascript que sucedió allí. Es muy raro que esa línea esté muy lejos del final de las barras de descarga de recursos. He terminado de depurar esto y es 1/3 error de análisis, 2/3 error de blogger. ... uno pensaría que las cosas de Google fueron rápidas.

Editar:

Algunos datos más. Aquí hay una solicitud con todo en caché. el de arriba fue la primera visita.

He eliminado la mierda de googleplus de arriba por dos razones, estaba intentando ver si estaban jugando un papel en el evento lento onLoad (no lo son) y porque es en su mayoría inútil.

Entonces, con esto podemos ver que el tiempo de red es la menor de tus preocupaciones. Incluso en una computadora veloz con software moderno, el peaje que google analytics + blogger toma en el tiempo de procesamiento seguirá volcando la carga de su página después de 7s. Sin el blogger, solo revisa este sitio, estoy viendo 0,5 segundos de retraso después de que se cargan los recursos y se activa la línea roja.

Use FireBug e YSlow para verificarlo usted mismo. Sin embargo, lo que descubrirá es que GA tiene un tamaño de aproximadamente 9 KB (que en realidad es bastante para lo que hace) y que a veces NO se carga demasiado rápido (por lo que no sé, creo que podría ser el servidores "asfixiando" a veces)

Lo eliminamos debido a problemas de rendimiento en nuestras muestras de Ajax , pero una vez más, para nosotros, ser extremadamente rápidos y receptivos fue la prioridad 1, 2 y 3

Las instrucciones tradicionales de Google sobre cómo incluir ga.js usan document.write() . Por lo tanto, incluso si un navegador cargara asíncronamente bibliotecas de JavaScript externas hasta que se ejecute realmente algún código, document.write() aún bloquearía la carga de la página. Las últimas instrucciones asincrónicas no usan document.write() directamente, pero ¿quizás insertBefore también bloquea la carga de la página?

Sin embargo, Google establece la max-age la memoria caché en 86,400 segundos (es de 1 día, e incluso se establece para ser pública , por lo que también se aplica a los proxies). Por lo tanto, como muchos sitios cargan el mismo script de Google, a menudo se buscará el JavaScript desde el caché. Aún así, incluso cuando ga.js se almacena en caché, simplemente haciendo clic en el botón de recarga a menudo hará que un navegador pregunte a Google sobre cualquier cambio . Y luego, al igual que cuando ga.js aún no estaba en la ga.js caché, el navegador debe esperar la respuesta antes de continuar:

GET /ga.js HTTP/1.1 Host: www.google-analytics.com ... If-Modified-Since: Mon, 22 Jun 2009 20:00:33 GMT Cache-Control: max-age=0 HTTP/1.x 304 Not Modified Last-Modified: Mon, 22 Jun 2009 20:00:33 GMT Date: Sun, 26 Jul 2009 12:08:27 GMT Cache-Control: max-age=604800, public Server: Golfe

Tenga en cuenta que muchos usuarios hacen clic en volver a cargar para sitios de noticias, foros y blogs que ya tienen abiertos en una ventana del navegador, lo que hace que muchos navegadores bloqueen hasta que se reciba una respuesta de Google . ¿Con qué frecuencia recarga la página de inicio de SO? Cuando la respuesta de Google Analytics es lenta, dichos usuarios se darán cuenta enseguida. (Hay muchas soluciones publicadas en la red para cargar asincrónicamente el script ga.js , especialmente útil para este tipo de sitios, pero quizás no sea mejor que las instrucciones actualizadas de Google).

Una vez que el JavaScript se haya cargado y ejecutado, la carga real del error web (la imagen de seguimiento) debe ser asincrónica. Por lo tanto, la carga de la imagen de seguimiento no debe bloquear nada más, a menos que la página use body.onload() . En este caso, si el error web no se carga rápidamente, entonces hacer clic en recargar en realidad empeora las cosas ya que al hacer clic en recargar también hará que el navegador solicite el script nuevamente, con If-Modified-Since descrito anteriormente. Antes de volver a cargar, el navegador solo estaba esperando el error web, mientras que después de hacer clic en recargar también necesita la respuesta para el script ga.js

Por lo tanto, los sitios que usan Google Analytics no deben usar body.onload() . En su lugar, uno debe usar algo como jQuery''s $(document).ready() o el evento domready de MooTools.

Consulte también Descripción general funcional de Google, donde se explica cómo recopila datos Google Analytics. , incluido cómo funciona el código de seguimiento . (Esto también hace que sea oficial que Google recopile los contenidos de las cookies de origen. Es decir: las cookies del sitio que está visitando).

Actualización: en diciembre de 2009 , Google lanzó una versión asíncrona . Lo anterior debería decirle a todos que actualicen solo para estar seguros, aunque la actualización no resuelve todo .