Vor einigen Tagen hat Google ein neues Feature für alle User ausgerollt: Instant Previews. Google zeigt nun auf Wunsch zu jedem Suchergebnis ein Vorschaubild der Seite an und markiert sogar die Position des Teasertextes.

Wie man es von Google gewohnt ist, wurde auch hier das letzte Quäntchen Performance herausgeholt. Bekommt man beim ersten Klick auf die Lupe bzw. auf den Teasertext noch für einen kurzen Moment ein Nachlade-Icon zu sehen, so ist dieses bei jedem weiteren Suchergebnis dieser Seite nicht mehr der Fall.

Dafür ist eine interessante Prefetching-Technik verantwortlich, die mit dem Laden des ersten Vorschaubildes angestoßen wird. In Firebug sieht das dann etwa so aus:

Es wird für jedes Suchergebnis ein eigener Request abgesetzt und Daten über JSONP nachgeladen.

Wie man sieht, wird das Vorschaubild base64-kodiert im selben Request mitgeliefert, was in Browsern, die diese Technik beherrschen einen HTTP-Request pro Suchergebnis spart. Zusätzlich werden noch zusätzlich einzublendende Informationen mitgeliefert, die zum Beispiel das Hervorheben des Teasertextes steuern.

Nun stellt sich die Frage, warum Google für jedes Bild einen eigenen Request absetzt. Die Antwort ist eigentlich denkbar einfach: man geht davon aus, dass der User die Vorschaubilder von oben nach unten ansieht. Das heißt, dass das nächste Bild relativ schnell verfügbar sein sollte und keine langen Verzögerungen vorhanden sein sollten. Gleiches Prinzip wie bei #newtwitter. Natürlich wäre eine Bündelung in einen Request absolut gesehen schneller. Jedoch könnte das bei langsamen Verbindungen nach hinten losgehen und zu einer einmaligen, größeren Verzögerung kommen – ein K.O.-Kriterium im modernen Web.