Pourquoi servir de 1x1 pixel GIF (web bugs) des données?

Question

De nombreux travaux analytiques et les outils de suivi sont requérant 1x1 image GIF (web bug, invisible pour l'utilisateur) pour la croix-domaine événement stockage/traitement.

Pourquoi se servir de cette image GIF? Ne serait-il pas plus efficace de simplement retourner un code d'erreur comme 503 Service Temporaire Indisponible ou fichier vide?

Mise à jour: Pour être plus clair, je me demande pourquoi pour servir GIF données d'image lorsque tous les renseignements requis ont déjà été envoyés en-têtes de la requête. Le GIF image elle-même n'a pas de retour de l'information utile.

Answer 1

Doug réponse est assez complet; je pensais que je voudrais ajouter une note supplémentaire (à la demande du commettant, hors de mon commentaire)

Doug réponse explique pourquoi 1x1 pixels espions sont utilisés pour les fins ils sont utilisés pour l'; je pensais que je l'avais aperçu un potentiel approche alternative, qui consiste à utiliser le Code d'État HTTP 204, Pas de Contenu, pour une réponse, et ne pas envoyer une image du corps.

204 Aucun Contenu

Le serveur a satisfait à la demande mais il n'a pas besoin de retourner un entité-corps, et pourrait vouloir retourner mise à jour de la métainformation. La réponse PEUT inclure de nouveaux ou mis à jour meta-information dans le formulaire de de l'entité en-têtes, qui si elle est présente DOIT être associé à la demandé variante.

En gros, le serveur reçoit la requête et décide de ne pas envoyer un corps (dans ce cas, de ne pas envoyer une image). Mais il répond par un code d'informer l'agent que c'était une décision consciente; fondamentalement, c'est juste une façon plus simple de répondre par l'affirmative.

À partir de Google Page Speed de la documentation:

Une façon populaire de la page d'enregistrement points de vue de façon asynchrone est de inclure un extrait de code JavaScript à l' en bas de la page cible (ou d'un gestionnaire d'événement onload), qui notifie l' le serveur d'enregistrement lorsqu'un utilisateur charge la page. La façon la plus courante de le faire c'est pour construire une requête à l' serveur pour un "phare", et coder tous les les données de l'intérêt en tant que paramètres dans l'URL de la balise de ressources. Pour garder la réponse HTTP de très petite taille, un transparent 1x1 pixel de l'image est un bon candidat pour un phare à la demande. Un un peu plus de la balise optimale serait d'utiliser HTTP de la réponse 204 ("aucun contenu") ce qui est légèrement plus petit qu'un 1x1 GIF.

Je n'ai jamais essayé, mais en théorie, il devrait servir le même but, sans exiger de l'gif lui-même être transmises, vous permet d'économiser 35 octets, dans le cas de Google Analytics. (Dans l'ordre des choses, sauf si vous utilisez Google Analytics au service de nombreux milliers de milliards de visites par jour, 35 octets est vraiment rien).

Vous pouvez le tester avec ce code:

var i = new Image(); 
i.src = "http://httpstat.us/204";

Answer 2

Tout d'abord, je suis en désaccord avec les deux précédentes réponses-ni engage la question.

L'un pixel de l'image résout un problème intrinsèque de web analytics apps (comme Google Analytics) lorsque l'on travaille dans le Protocole HTTP--comment transférer (web metrics) des données du client vers le serveur.

La plus simple des méthodes décrites par le Protocole, le plus simple (au moins la méthode la plus simple qui comprend un corps de requête) est la requête GET. Selon ce Protocole de la méthode, les clients de lancer des requêtes à des serveurs pour les ressources, les serveurs de traitement de ces demandes et de retour des réponses appropriées.

Pour un web analytics app, comme GA, cette uni-directionnelle régime est une mauvaise nouvelle, car il ne semble pas permettre à un serveur pour récupérer des données à partir d'un client sur demande, encore une fois, tous les serveurs peuvent faire est de fournir des ressources à ne pas en faire la demande.

Alors quelle est la solution pour le problème de l'obtention des données du client vers le serveur? Dans le contexte HTTP il y a d'autres Protocole des méthodes autres que GET (par exemple, la POSTE), mais c'est une option limitée pour de nombreuses raisons (comme en témoignent ses rares et spécialisées telles que l'envoi des données du formulaire).

Si vous regardez une Requête GET à partir d'un navigateur, vous verrez qu'il est composé de l'URL de la Requête et en-Têtes de Requête (par exemple, le Referer et User-Agent en-Têtes), ce dernier contient des informations sur le client (par exemple, type et version de navigateur, langue du navigateur, système d'exploitation, etc.

Encore une fois, c'est la partie de la Demande que le client envoie au serveur. Donc l'idée qui motive l'un pixel gif est pour le client d'envoyer le web les données de mesures sur le serveur, le tout enveloppé dans un en-Tête de Requête.

Mais alors comment obtenir le client Demande une ressource de sorte qu'il peut être "trompé" en envoyant les données de mesures? Et comment obtenir le client à envoyer les données que le serveur veut?

Google Analytics est un bon exemple: l' ga.js fichier (le fichier de grande taille dont les télécharger vers le client est déclenchée par un petit script dans la page web) comprend quelques lignes de code qui dirige le client demande une ressource à partir d'un serveur en particulier (le GA serveur) et d'envoyer certaines données enveloppé dans l'Entête de la Requête.

Mais étant donné que le but de cette Demande est de ne pas obtenir effectivement une ressource, mais pour envoyer des données au serveur, cette ressource doit être une petite que possible et il ne doit pas être visible au moment du rendu de la page web--d'où la de 1 x 1 pixel gif transparent. La taille est la taille la plus petite possible, et le format (gif) est le plus petit parmi les formats d'image.

Plus précisément, tous les GA de données--chaque élément--est assemblé et emballé dans l' URL de la Demande de la chaîne de requête (tout ce qui est après le '?'). Mais pour que les données du client (où il est créé) à l'AG du serveur (où il est enregistré et agrégées) il doit y avoir une Requête HTTP, de sorte que le ga.js (google analytics script téléchargé, sauf s'il est mis en cache par le client, en tant que résultat d'une fonction appelée lors du chargement de la page) oriente le client pour assembler toutes les données de google analytics--par exemple, les cookies, l'emplacement de bar, des en-têtes de demande, etc.--concaténer dans une chaîne unique et l'ajouter comme une chaîne de requête de l'URL (*http://www.google-analytics.com/__utm.gif*?) et que devient l' URL de la Requête.

Il est facile de le prouver à l'aide de n'importe quel navigateur web qui a permet d'afficher la Requête HTTP de la page web affichée dans votre navigateur (par exemple, de Safari, de l'Inspecteur Web, Firefox/Chrome Firebug, etc.).

Par exemple, j'ai tapé dans l'url valide pour une entreprise de la page d'accueil de mon navigateur la barre d'adresse, ce qui a rendu cette page d'accueil et affiche dans mon navigateur (j'aurais pu choisir n'importe quel site web/la page qui utilise l'une des principales apps google analytics, google analytics, Omniture, Coremetrics, etc.)

Le navigateur que j'ai utilisé était de Safari, donc j'ai cliqué Développer dans la barre de menu, puis Afficher l'Inspecteur Web. Sur la ligne supérieure de l'Inspecteur Web, cliquez sur Ressources, cliquez sur l'utm.gif ressource de la liste de ressources indiqué sur la colonne de gauche, puis cliquez sur les en-Têtes onglet. Qui va vous montrer quelque chose comme ceci:

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

Les principaux points sont les suivants:

1. La Demande était en fait une demande pour l'utm.gif comme en témoigne la la première ligne ci-dessus: *Demande URL:http://www.google-analytics.com/__utm.gif*.

2. Google Analytics paramètres sont clairement visibles dans la chaîne de requête ajouté à l'URL de la Requête: par exemple, utmsr GA est le nom de la variable de référence à l'écran du client la résolution, pour moi, montre une valeur de 1280x800; utmfl est la variable nom de la version de flash, qui a un la valeur de 10,3, etc.

3. L' en-Tête de Réponseappelé Le Type de contenu (envoyé par le serveur vers le client) confirme aussi que la ressource demandée et retourné a une 1x1 pixel gif: Content-Type:image/gif

Ce schéma général pour le transfert de données entre un client et un serveur a été autour pour toujours; il pourrait très bien être une meilleure façon de le faire, mais c'est la seule façon que je connais (qui satisfait les contraintes imposées par un hébergé service d'analyse).

Answer 3

Certains navigateurs peuvent afficher une icône d'erreur si la ressource n'a pas pu charger. Il rend le débogage/surveillance du service peut-être un peu plus compliqué, vous devez assurez-vous que vos outils de surveillance de traiter l'erreur comme un bon résultat.

Otoh, que vous n'avez pas gagner quoi que ce soit. Le message d'erreur renvoyé par le serveur/le cadre est généralement plus grand que l'image de 1x1. Cela signifie que vous augmenter votre réseau de trafic pour quasiment rien.

Answer 4

Parce que ce GIF a connu une présentation dans un navigateur, c'est un seul pixel, période. Autre chose présente un risque de visuellement interférer avec le contenu réel de la page.

HTTP erreurs peuvent apparaître comme surdimensionné cadres de texte d'erreur ou même comme une fenêtre pop-up. Certains navigateurs peuvent également déposer une plainte s'ils reçoivent vide réponses.

En outre, en page les images sont l'un des très rares types de données autorisés par défaut dans tous les broswers. Autre chose peut exiger action explicite de l'utilisateur pour être téléchargé.

Answer 5

C'est pour répondre à l'OP de la question: "pourquoi est - à servir GIF données d'image..."

Certains utilisateurs de mettre un simple img balise pour appeler votre journalisation des événements de service

<img src="http://www.example.com/logger?event_id=1234">

Dans ce cas, si vous ne servez pas d'une image, le navigateur affiche une icône de substitution qui sera moche et donner l'impression que votre service est brisé!

Ce que je fais est de regarder pour l' Accepter champ d'en-tête. Lorsque votre script est appelé par l'intermédiaire d'une img balise comme ceci, vous verrez quelque chose comme suit dans l'en-tête de la demande -

Accept: image/gif, image/*
Accept-Encoding:gzip,deflate
...

Quand il est "image/"* chaîne dans l' Accepter champ d'en-tête, je l'approvisionnement de l'image, sinon je viens de répondre à 204.