Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Weird...when I was at Google, very significant engineering effort was expended (we're talking man-years) to prevent exactly this case, and it was a major design constraint on the features we could launch. Something must've changed in the thinking of the higher-ups.

I also wonder why they don't just use pushState, which was proposed as a solution way back in 2010 but didn't have the browser support necessary. Now it's got the browser support:

http://caniuse.com/#search=pushState



There was a thread a few weeks back about something Google-related and an ex-Googler was saying how many hours they spent making the home page and search results pages as light as possible, but that recently they stopped caring about that.


You mean this one?

https://news.ycombinator.com/item?id=10395008

That ex-Googler was me. :-)

I'm not actually sure whether they don't care about it, BTW - the SRP is about 1/3 as heavy as it was when I left, so it looks like someone's been cleaning it up. These things tend to move in cycles - I was hired at the very end of a "latency & performance" cycle, then spent most of my career there during a "moar featurez!" cycle, and it wouldn't surprise me if the focus is again latency and performance.


Doesn't that bring in to question all the research that says the faster your page loads the more money you make?

If Google can swing between adding a load to the page load and then whittling it down making it faster, the money difference involved must be fairly trivial.


Not exactly. It's more that making the page faster is fairly predictably going to get you $X in additional revenue. Adding a new feature is going to get you anywhere from $0 to $Y in revenue, but you can't know what $Y is until you've launched it and given users some time to learn about it. So the only way to avoid getting stuck in a local maxima - your current feature set, as optimized as possible - is to periodically try to shake up the page, add some new features, and measure their effects. After a couple years or so, the features for which $Y < their cost in latency & developer maintenance are killed, and a new round of optimization & code cleanup starts based on the current feature set.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: