Hvis du har brugt Google Search for nylig, har du måske bemærket en ny funktion, som vi kalder Instant Previews. Ved at klikke på (sprited) ikonet med forstørrelsesglasset ud for et søgeresultat du se et eksempel på denne side, ofte med det relevante indhold fremhævet. Når aktiveret, kan du musen hen over resten af resultaterne og hurtigt (instantly!) se previews af disse søgeresultater, også.
Tilføje denne funktion til at Google Search involverede en masse klient-side JavaScript. Være Google, vi var nødt til at sikre, at vi kunne levere denne funktion uden at bremse ned på siden. Vi kender vores brugere ønsker, at deres resultater hurtigt. Så vi troede, vi ville dele nogle teknikker, der er involveret i at gøre denne nye funktion hurtigt.
JavaScript kompileringDet er ikke noget nyt for Google-søgning: alle vores Javascript er udarbejdet for at gøre det så lille som muligt. Vi bruger den open source Lukning Compiler. Ud over at minimere Javascript-kode, også det re-skriver udtryk, genbruger variabler, og svesker ud kode, der ikke bliver brugt. Javascript på søgeresultatsiden er udskudt, og også cachelagrede meget aggressivt på klientsiden, så det ikke er downloadet mere end en gang pr version.
On-demand JSONPNår du aktiverer Instant Previews, resultat previews de ønskede af din webbrowser. Der er flere måder at hente de data vi har brug for hjælp Javascript. De mest populære teknikker er XMLHttpRequest (XHR) og JSONP. XHR generelt giver dig bedre kontrol og fejl-håndtering, men det har to ulemper: browsere caching tendens til at være mindre pålidelig, og kun af samme oprindelse anmodninger er tilladt (dette er begyndt at ændre sig med moderne browsere og på tværs af oprindelse ressourcedeling, selv om ). Med JSONP, på den anden side objekt den anmodede scriptet returnerer de ønskede data som en JSON svøbt i en Javascript callback funktion, hvilket i vores tilfælde ser noget lignende
google.vs.r ({\ "dim \": [302.585], \ "url \": \ "http://example.com \", ssegs :[...]}).
Selv om fejlhåndtering med JSONP er en smule sværere at gøre i forhold til XHR (ikke alle browsere understøtter onerror hændelser), kan JSONP være cached aggressivt af browseren, og er ikke underlagt samme oprindelse restriktioner. Dette sidste punkt er vigtigt for Instant Previews fordi webbrowsere begrænse antallet af samtidige anmoder om, at de sender til nogen vært. Brug af en anden vært for preview anmodninger betyder, at vi ikke blokere andre anmodninger i siden.
Der er et par tricks, når du bruger JSONP, der er værd at bemærke: Hvis du indsætter scriptet tag direkte, fx ved hjælp af document.createElement, vil nogle browsere viser siden som stadig "loading" indtil alle script anmodninger er færdig. For at undgå, at gøre din DOM opkald for at indsætte script-tag inde i en window.setTimeout call.After dine ønsker at komme tilbage og dine noteringer er færdig, er det en god idé at indstille din script src til null, og fjern tag. På nogle browsere, der giver mulighed for mange script tags til at ophobe sig med tiden kan bremse alt ned.
Data URI'erPå dette tidspunkt er du sikkert spændt på, hvad vi tilbage i vores JSONP opkald, og i særdeleshed, hvorfor vi bruger JSON og ikke bare almindelig billeder. Måske har du endda brugt Firebug eller din browser Developer Tools til at undersøge Instant Previews anmodninger. Hvis det er tilfældet, vil du have bemærket, at vi sender tilbage billeddata som datasæt URI'er. Data URI'er er base64 kodninger af billeddata, at moderne browsere (IE8 +, Chrome, Safari, Firefox, Opera, etc.) kan bruge til at vise billeder, i stedet for at laste dem fra en server som sædvanlig.
For at vise previews, vi har brug for billedet, og det relevante indhold på siden for den pågældende forespørgsel, med afgrænsningsrammer at vi trækker på toppen af billedet for at vise, hvor dette indhold vises på siden. Hvis vi brugte statiske billeder, vil vi nødt til at gøre en anmodning om indhold og en anmodning om billedet, ved hjælp af JSONP med data URI'er, vi laver bare en anmodning. Data URI'er er begrænset til 32K på IE8, så sender vi "skiver", der alle er under denne grænse, og derefter bruge Javascript for at generere de nødvendige billedet tags til at vise dem. Og selvom base64-kodning lægger omkring 33% til størrelsen af billedet, vores test viste, at gzip-komprimeret data URI'er er sammenlignelige i størrelse til den oprindelige JPEG.
Vi bruger caching hele vores implementering, men det er vigtigt ikke at glemme klient-side caching så godt. Ved at bruge JSONP og data webadresser, begrænser vi antallet af anmodninger, og også sørge for, at browseren vil cache de data, så hvis du opdaterer en side eller genskab en forespørgsel, bør du få previews, godt ... det samme!
Af Matías Pelenur, Instant Previews team

