javascript - ein - pixel tags wiki
¿Por qué servir datos GIF(bugs web) de 1x1 píxeles en absoluto? (6)
Muchas herramientas analíticas y de seguimiento están solicitando una imagen 1x1 GIF (error de la web, invisible para el usuario) para el almacenamiento / procesamiento de eventos entre dominios.
¿Por qué servir esta imagen GIF en absoluto? ¿No sería más eficiente simplemente devolver algún código de error como 503 Service Temporary Unavailable o un archivo vacío?
Actualización: Para ser más claro, estoy preguntando por qué para servir datos de imágenes GIF cuando toda la información requerida ya ha sido enviada en los encabezados de solicitud. La imagen GIF en sí misma no devuelve ninguna información útil.
Algunos navegadores pueden mostrar un ícono de error si el recurso no se pudo cargar. Hace que la depuración / supervisión del servicio también sea un poco más complicada, debe asegurarse de que sus herramientas de supervisión traten el error como un buen resultado.
OTOH no ganas nada. El mensaje de error devuelto por el servidor / framework suele ser más grande que la imagen 1x1. Esto significa que aumenta el tráfico de su red básicamente por nada.
Bueno, la razón principal es adjuntar la cookie, así que si los usuarios van de un lado a otro, todavía tenemos el mismo elemento para adjuntar la cookie.
Debido a que dicho GIF tiene una presentación conocida en un navegador, es un solo píxel, punto. Cualquier otra cosa presenta un riesgo de interferir visualmente con el contenido real de la página.
Los errores de HTTP podrían aparecer como marcos de texto de error de gran tamaño o incluso como una ventana emergente. Algunos navegadores también pueden quejarse si reciben respuestas vacías.
Además, las imágenes in-page son uno de los pocos tipos de datos permitidos por defecto en todos los broswers. Cualquier otra cosa puede requerir la acción explícita del usuario para descargar.
En primer lugar, estoy en desacuerdo con las dos respuestas anteriores; ninguna de las dos aborda la pregunta.
La imagen de un píxel soluciona un problema intrínseco para las aplicaciones de análisis basadas en la web (como Google Analytics) cuando se trabaja en el protocolo HTTP: cómo transferir datos (métricas web) del cliente al servidor .
El más simple de los métodos descritos por el Protocolo, el más simple (al menos el método más simple que incluye un cuerpo de solicitud) es la solicitud GET . De acuerdo con este método de protocolo, los clientes inician solicitudes de recursos a los servidores; los servidores procesan esas solicitudes y devuelven las respuestas apropiadas.
Para una aplicación analítica basada en web, como GA, este esquema unidireccional es una mala noticia, ya que no parece permitir que un servidor recupere datos de un cliente a pedido. De nuevo, todos los servidores pueden hacer es proporcionar recursos no solicitarlos
Entonces, ¿cuál es la solución al problema de volver a enviar los datos del cliente al servidor? Dentro del contexto HTTP hay otros métodos de protocolo además de GET (por ejemplo, POST), pero esa es una opción limitada por muchas razones (como lo demuestra su uso poco frecuente y especializado, como la presentación de datos de formularios).
Si observa una solicitud GET desde un navegador, verá que está compuesta por una URL de solicitud y encabezados de solicitud (p. Ej., Encabezado de Referer y User-Agent), esta última contiene información sobre el cliente, por ejemplo, tipo de navegador y versión, idioma del navegador, sistema operativo, etc.
Nuevamente, esto es parte de la Solicitud que el cliente envía al servidor. De modo que la idea que motiva el gif de un píxel es que el cliente envíe los datos de las métricas web al servidor, dentro de un Encabezado de solicitud.
Pero, ¿cómo lograr que el cliente solicite un recurso para que pueda ser "engañado" para que envíe los datos de las métricas? ¿Y cómo lograr que el cliente envíe los datos reales que el servidor quiere?
Google Analytics es un buen ejemplo: el archivo ga.js (el archivo grande cuya descarga al cliente se desencadena mediante un pequeño script en la página web) incluye unas pocas líneas de código que le indica al cliente que solicite un recurso particular de un determinado servidor (el servidor GA) y para enviar ciertos datos envueltos en el Encabezado de la solicitud.
Pero dado que el propósito de esta Solicitud no es obtener un recurso sino enviar datos al servidor, este recurso debería ser lo más pequeño posible y no debería estar visible cuando se represente en la página web, por lo tanto, el 1 x 1 pixel transparente gif. El tamaño es el tamaño más pequeño posible, y el formato (gif) es el más pequeño entre los formatos de imagen.
Más precisamente, todos los datos de GA, cada elemento individual, se ensamblan y empaquetan en la cadena de consulta de la URL de solicitud (todo después del ''?''). Pero para que los datos vayan del cliente (donde se crea) al servidor GA (donde se registra y agrega) debe haber una solicitud HTTP, por lo que el script ga.js (google analytics que se descarga, a menos que sea en caché, por el cliente, como resultado de una función llamada cuando se carga la página) ordena al cliente que ensamble todos los datos de análisis, por ejemplo, cookies, barra de ubicación, encabezados de solicitud, etc., concatenarlo en una sola cadena y anexarlo como una cadena de consulta a una URL ( * http: //www.google-analytics.com/__utm.gif* ?) y se convierte en la URL de solicitud .
Es fácil probarlo usando cualquier navegador web que le permita ver la Solicitud HTTP para la página web que se muestra en su navegador (por ejemplo, Safari''s Web Inspector , Firefox / Chrome Firebug , etc.).
Por ejemplo, escribí una URL válida en una página de inicio corporativa en la barra de direcciones de mi navegador, que me devolvió esa página y la visualicé en mi navegador (podría haber elegido cualquier sitio / página web que use una de las principales aplicaciones de análisis, GA , Omniture, Coremetrics, etc.)
El navegador que utilicé fue Safari, así que hice clic en Desarrollar en la barra de menú y luego Mostrar el Inspector web . En la fila superior del Inspector web, haga clic en Recursos , busque y haga clic en el recurso utm.gif de la lista de recursos que se muestra en la columna de la izquierda, luego haga clic en la pestaña Encabezados . Eso te mostrará algo como esto:
Request URL:http://www.google-analytics.com/__utm.gif?
utmwv=1&utmn=1520570865&
utmcs=UTF-8&
utmsr=1280x800&
utmsc=24-bit&
utmul=enus&
utmje=1&
utmfl=10.3%20r181&
Request Method:GET
Status Code:200 OK
Request Headers
User-Agent:Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; en-us) AppleWebKit/533.21.1
(KHTML, like Gecko) Version/5.0.5 Safari/533.21.1
Response Headers
Cache-Control:private, no-cache, no-cache=Set-Cookie, proxy-revalidate
Content-Length:35
Content-Type:image/gif
Date:Wed, 06 Jul 2011 21:31:28 GMT
Los puntos clave para notar son:
De hecho, la Solicitud fue una solicitud de utm.gif, como se evidencia en la primera línea anterior: * URL de solicitud: http: //www.google-analytics.com/__utm.gif*.
Los parámetros de Google Analytics son claramente visibles en la cadena de consulta adjuntada a la URL de solicitud : por ejemplo, utmsr es el nombre de variable de GA para referirse a la resolución de pantalla del cliente, para mí, muestra un valor de 1280x800; utmfl es el nombre de la variable para la versión flash, que tiene un valor de 10.3, etc.
El encabezado de respuesta llamado Content-Type (enviado por el servidor de vuelta al cliente) también confirma que el recurso solicitado y devuelto era un gif de 1x1 píxeles: Content-Type: image / gif
Este esquema general para transferir datos entre un cliente y un servidor ha existido por siempre; podría haber una forma mejor de hacerlo, pero es la única forma que conozco (que satisface las restricciones impuestas por un servicio de análisis alojado).
Esto es para responder a la pregunta del OP: "por qué enviar datos de imágenes GIF ..."
Algunos usuarios pondrán una simple etiqueta img para llamar a su servicio de registro de eventos:
<img src="http://www.example.com/logger?event_id=1234">
En este caso, si no se publica una imagen, el navegador mostrará un ícono de marcador de posición que se verá feo y dará la impresión de que su servicio está dañado.
Lo que hago es buscar el campo de encabezado Aceptar . Cuando se llama a su secuencia de comandos a través de una etiqueta img como esta, verá algo así como seguir en el encabezado de la solicitud -
Accept: image/gif, image/*
Accept-Encoding:gzip,deflate
...
Cuando hay una cadena "image / " * en el campo de encabezado Accept , proporciono la imagen; de lo contrario, solo respondo con 204.
La respuesta de Doug es bastante completa; Pensé que agregaría una nota adicional (a petición del OP, fuera de mi comentario)
La respuesta de Doug explica por qué las balizas de 1x1 píxeles se utilizan para el propósito para el que se utilizan; Pensé en esbozar un posible enfoque alternativo, que es usar el código de estado HTTP 204, Sin contenido, para obtener una respuesta, y no enviar un cuerpo de imagen.
204 Sin contenido
El servidor ha cumplido la solicitud pero no necesita devolver un cuerpo de entidad, y puede querer devolver metainformación actualizada. La respuesta PUEDE incluir metainformación nueva o actualizada en forma de encabezados de entidad, que de estar presentes DEBERÍAN asociarse con la variante solicitada.
Básicamente, el servidor recibe la solicitud y decide no enviar un cuerpo (en este caso, para no enviar una imagen). Pero responde con un código para informar al agente que esta fue una decisión consciente; Básicamente, es solo una forma más corta de responder afirmativamente.
De la documentación de Google Page Page :
Una manera popular de registrar visitas de página de manera asincrónica es incluir un fragmento de JavaScript en la parte inferior de la página de destino (o como un controlador de eventos de onload), que notifica a un servidor de registro cuando un usuario carga la página. La forma más común de hacerlo es construir una solicitud al servidor para un "faro" y codificar todos los datos de interés como parámetros en la URL del recurso de la baliza. Para mantener la respuesta HTTP muy pequeña, una imagen transparente de 1x1 píxeles es un buen candidato para una solicitud de baliza. Una baliza un poco más óptima usaría una respuesta HTTP 204 ("sin contenido") que es marginalmente más pequeña que un GIF 1x1.
Nunca lo intenté, pero en teoría debería servir para el mismo propósito sin requerir que se transmita el gif, ahorrándote 35 bytes, en el caso de Google Analytics. (En el esquema de las cosas, a menos que sea Google Analytics que sirve muchos trillones de visitas por día, 35 bytes realmente no es nada).
Puedes probarlo con este código:
var i = new Image();
i.src = "http://httpstat.us/204";