The limiting factor in end-user browser latency is almost always download time. The cost of JQuery is primarily the cost of downloading JQuery. The advantage of doing everything sans libraries is that you ship only the code you actually need to use to the browser.
(It's the same reason why Google uses browser-sniffing instead of feature detection in its JS. It lets us avoid shipping IE-only hacks to W3C browsers, or W3C code to IE.)
There're secondary issues with browser CPU time, and you eventually learn to avoid CSS or JS constructs that tend to peg the browser CPU. Anything that causes a reflow is expensive, and certain selector engine constructs require JQuery to traverse the whole page. But this is typically secondary to download time unless you're doing a complex animation or mousemove handler.
G+ performs badly on the phone because it does a lot. G+ has so far prioritized features over latency, so they optimize for development time. The result often isn't the tightest code. They operate under very different constraints from websearch, though - typically, people open up G+ and then leave it open for a while, but they run a search and then hopefully immediately bounce off the SRP.
It does, and it works as well as the compiler can prove that the code is unused. For some stuff (like functions that are never syntactically referenced), that's trivial. In the general case, it's impossible, because of the halting problem.
G+ is a heavy user of Closure Compiler (websearch is too, actually, but we use it differently), and Google's JS coding conventions actually are designed with the compiler in mind. The thing is, most of this bloat isn't functions that are never used, it's functions that are rarely used. G+ is big because you can do a lot with it.
(It's the same reason why Google uses browser-sniffing instead of feature detection in its JS. It lets us avoid shipping IE-only hacks to W3C browsers, or W3C code to IE.)
There're secondary issues with browser CPU time, and you eventually learn to avoid CSS or JS constructs that tend to peg the browser CPU. Anything that causes a reflow is expensive, and certain selector engine constructs require JQuery to traverse the whole page. But this is typically secondary to download time unless you're doing a complex animation or mousemove handler.
G+ performs badly on the phone because it does a lot. G+ has so far prioritized features over latency, so they optimize for development time. The result often isn't the tightest code. They operate under very different constraints from websearch, though - typically, people open up G+ and then leave it open for a while, but they run a search and then hopefully immediately bounce off the SRP.