First Google (your reference) is all about lowering the burden from within a web browser or an application that encapsulates HTML or a plugin. And I HTML relies on the the underlying protocols to handle congestion, delays and re-transmissions. So all you need to to is learn about TCP and sliding windows, but I think that's not your answer
If you were to strip out all the Google extras it may run faster, but what kind of UX would the customer have? So its a trade off between the available network latency and the UX you want to provide customers.
Do you want to do research on mobile web applications or applications developed for mobile platforms? There is a huge difference.
For example: In YouTube you can select the quality such as SD,360p,480P,720P or Auto. What you need to investigate is how the 'Auto' option works, be sure to be using flash video where 'Auto' option is available, YouTube HTML5 video does not have the 'auto' option?
Maybe Flash has a network performance protocol included where HTML5 may not? It's worth you looking at Flash to see how they negotiate the available link latency.
But of course a web browser is just another mobile application, like most others. But a closed mobile application can rely on TCP or opt for UDP and create their own methods.
A few hints;
Signal strength is not the capable (by itself) of determining end-to-end network speed and reliability. it changes constantly when standing still, it's a best guess and a good starting point. Developers have to create other methods.
Best to use a small MTU to reduce re-transmissions due to dropped packets. Also larger packets are statistically more likely to have CRC errors when being transmitted over a wireless physical layer.
Get your developers to test on devices only capable of EDGE. This concentrates the developers mind for efficient network performance.