When I joined Google in 2009, we were on the tail-end of a latency optimization kick that Larry had started in 2007. At the time, we had a budget of 20K gzipped for the entire search results page. I remember working on the visual redesign of 2010, where we had increased the page weight from 16K to 19K and there was much handwringing at the higher levels about how we were going to blow our entire latency budget on one change.
We did some crazy stuff to squeeze everything in. We would literally count bytes on every change - one engineer wrote a tool that would run against your changelist demo server and output the difference in gzipped size of it. We used 'for(var i=0,e;e=arr[i++];) { ... }' as our default foreach loop because it was one character shorter than explicitly incrementing the loop counter. All HTML tags that could be left unterminated were, and all attributes that could be unquoted were. CSS classnames were manually named with 1-3 character abbreviations, with a dictionary elsewhere, to save on bytesize. I ran an experiment to see if we could use JQuery on the SRP (everything was done in raw vanilla JS), and the results were that it doubled the byte size and latency of the SRP, so that was a complete non-starter. At one point I had to do a CSS transition on an element that didn't exist in the HTML, because it was too heavy and so we had to pull it over via AJAX, so I had to do all sorts of crazy contortions to predict the height and position of revealed elements before the code for them actually existed on the client.
A lot of these convolutions should've been done by compiler, and indeed, a lot were moved to one when we got an HTML-aware templating language. But it gave me a real appreciation for how to write tight, efficient code under constraints - real engineering, not just slapping libraries together.
Alas, when I left the SRP was about 350K, which is atrocious. It looks like it's since been whittled down under 100K, but I still sometimes yearn for the era when Google loaded instantaneously.
Way back when Google first got VC, before they invented AdWords and got profitable, they explored a lot of custom business partner opportunities. So there were a number of specialized Google search endpoints like /linux, /bsd, /unclesam (search over Federal government websites). These were maintained until about 2013 - they go through a different rendering path than the one that serves mainstream Google Search. /linux, /bsd, /unclesam, and a few others were decomissioned in 2013, soon before I left Google, but it looks like /custom got a reprieve for whatever reason. It's actually been deprecated by the Custom Search Engine functionality linked above, but nobody's gotten around to removing it.
Incidentally, you can also get a similar page (slightly different, its last update was around 2007 and it shows no ads) by setting your user agent to "Mozilla 3.0".
But, the advantage of /custom: It uses less personalized results, and it returns exactly 20KiB of data – which is why it still loads so fast.
There was a day when I just wrote a small script to open all sites mentioned in Google’s robots.txt (which did not return 404) in a separate tab. That’s how I found it.
As far as I know, some partners actually still embed /custom (I’ve only seen it at a newspaper a few months ago), so removing it might be problematic.
> As far as I know, some partners actually still embed
> /custom (I’ve only seen it at a newspaper a few months
> ago), so removing it might be problematic.
I see it every so often if a domain doesn't get resolved - they'll hijack the request and show you their own page. I was pretty surprised that that still happens.
Ahh, heirloom. (That's the name of the system that renders Google for ancient user-agents). Takes me back. It actually got a small set of updates in 2010 when we wrote Heirloom+ and it appears that someone has collapsed the two systems into one since I left in 2011. I'm strangely gratified to see that no one has come up with a better layout solution than putting the results in a table.
- It’s 20k vs 190k for the same results page (loads faster, especially useful when on throttled 3G),
- It’s non-personalized – meaning you get less filter-bubble effect, which is useful when researching topics where you want to see opinions that oppose your own
For me, only the first page load is faster but the actual search is slower compared to the full version with AJAX for the instant search (around 400 ms for /custom vs. 80 ms ajax response).
Yeah. The issue was that there were two other constraints that had to be satisfied at the same time: CPU time to render the page couldn't go up appreciably (or we'd run out of machines), and there was a lot of legacy HTML and JS to update. Google actually had a CSS compiler at the time (since open-sourced as Closure Stylesheets), but it required that you run every JS reference of a classname through goog.getCssName (which was prohibitive because we couldn't use Closure in the JS for bytesize reasons), and that you post-process the HTML (which was prohibitive both for CPU reasons and because Closure Compiler is written in Java while the HTML for Google Search, at the time, was generated in C++).
I'm not op, but I think this would be like xhp or jsx. Really it's any templating language that works closer to the DOM level and can perfom optimizations like understanding which close tags don't need to be output
It wasn't Closure Templates - those are what's used on the Apps side of Google (GMail, Google+, Docs, etc.). The technology in question lies in a grey area as far as confidentiality goes...it's been mentioned once in a recruiting presentation and there are references to it in other Google open-source projects...but I figure I would be safer by not naming it.
I think the community moderation has done its job here, and the negatives from preventing new accounts from commenting wouldn't be worth the advantage.
We did some crazy stuff to squeeze everything in. We would literally count bytes on every change - one engineer wrote a tool that would run against your changelist demo server and output the difference in gzipped size of it. We used 'for(var i=0,e;e=arr[i++];) { ... }' as our default foreach loop because it was one character shorter than explicitly incrementing the loop counter. All HTML tags that could be left unterminated were, and all attributes that could be unquoted were. CSS classnames were manually named with 1-3 character abbreviations, with a dictionary elsewhere, to save on bytesize. I ran an experiment to see if we could use JQuery on the SRP (everything was done in raw vanilla JS), and the results were that it doubled the byte size and latency of the SRP, so that was a complete non-starter. At one point I had to do a CSS transition on an element that didn't exist in the HTML, because it was too heavy and so we had to pull it over via AJAX, so I had to do all sorts of crazy contortions to predict the height and position of revealed elements before the code for them actually existed on the client.
A lot of these convolutions should've been done by compiler, and indeed, a lot were moved to one when we got an HTML-aware templating language. But it gave me a real appreciation for how to write tight, efficient code under constraints - real engineering, not just slapping libraries together.
Alas, when I left the SRP was about 350K, which is atrocious. It looks like it's since been whittled down under 100K, but I still sometimes yearn for the era when Google loaded instantaneously.