Hacker News new | past | comments | ask | show | jobs | submit login
What I'm working on at Google: Making the mobile web fast (matt-welsh.blogspot.com)
91 points by hiteshiitk on June 5, 2011 | hide | past | favorite | 11 comments



This is one thing I love about Google. Most companies will task a group or team with making their website faster -- at Google it's make the web faster.

It reminds me of a post-war vision statement at Sony which was basically be the company that "changes the worldwide poor-quality image of Japanese products." It wasn't just about Sony, it was about the whole country -- that's cool.


What can Google do to help say webOS become faster at mobile web access?


Google's mod_pagespeed (http://code.google.com/speed/page-speed/docs/module.html) is an example of something Google did that can help everyone on all platforms.

He talks a bit about it in the article too: "At a high level we are planning to tackle problems in three broad areas: The mobile devices themselves; the services they connect to; and the networks that connect them. On the device side, we are looking at a wide range of OS, network stack, and browser enhancements to improve performance. On the service side, we are looking at better ways to architect websites for mobile clients, providing tools to help web developers maximize their performance, and automatic optimizations that can be performed by a site or in a proxy service. Finally, at the network layer we are looking at the (sometimes painful) interactions between different layers of the protocol stack and identifying ways to streamline them."


Isn't he greatly understating the significance of mobile browser performance? Isn't it the #1 blocker right now? Mobile browsers parse javascript much slower than on the desktop. Even the iPad can't keep up with a lot of simplistic canvas games. Google needs a team dedicated to fixing this problem.


Improving V8 on mobile would be a start.


The biggest thing Google could do for the mobile web is force carriers onto a quicker Android update cycle.

The implementation of CSS media queries is broken in nearly all shipped handsets making them pointless as an optimization for sending the correct images to browsers. This isn't likely to change for quite a while.

The Android browser really needs to auto-update like the desktop Chrome.


How about independently upgradable system components ? I'd love my Android to support "aptitude dist-upgrade" to upgrade WebKit, the Android Browser…


The phone carriers want control over your phone, they don't want you to be able to easily 'upgrade' without their junk in it; it is in-fact the reason why it takes so long. The situation is helped a bit when users buy phones and plans separately, although it is becoming less popular to do this in my country, I fear. This is what was so good about the Nexus One, Google pushed updates directly.


This argument doesn't stand for OEM devices. And there are many of them with no carrier customization whatsoever (current version of Samsung Galaxy S II), with slow upgrades and no "system components" upgrade.

Google is still pushing updates to the Nexus One and Nexus S, so it's not like it's the past.

By the way what I'm talking about is a limitation of Android itself: it has no package management system (with dependencies, upgrade etc.) for core components. And what I'm proposing would allow certain parts of the system to be upgraded while carrier junk stays there.

Google is actually already doing that for Gmail, Market, Music, Maps and other apps. Why not the browser ? (even if for now it uses a separate libwebkit)


I'm not an Android expert, but I think many libraries (browser, sms, phone, etc.) are basically kernel/baseband dependent (To make an hardware accelerated browser means modified GPU drivers, means new/updated kernel features, etc.), so it's almost impossible to provide an unified build of some apps on current devices (Gtalk video available only on 2.3.4 also comes to mind)


Make the mobile web cheaper would be my first priority - data roaming rates are insane




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

Search: