bookmarklets for mobile: Mobile Perf and Page Resources
As I announced yesterday, I’m now focusing on mobile performance. Not surprisingly, I’ve laid claim to MobilePerf.com and MobilePerf.org. Right now they just redirect to my Mobile Perf home page. Step 1 is complete.
So – what should we do next?
I’m on my Nexus S and iPhone all the time and find surfing the Web to be agonizingly slow. That’s not a huge surprise – hence my current job as a performance wonk. (Oooo – that’s a good name – perfwonk.com and perfwonk.org booked.) Being a performance wonk I always wonder why the sites I visit are slow on mobile. To figure that out I need some visibility into mobile browsers.
The problem is the browser tools we use on our desktop (Firebug, Page Speed, YSlow, Dynatrace, Speed Tracer, etc.) don’t work on mobile devices. Many of these are browser add-ons which aren’t (yet) supported on mobile. Others are executables that are limited to specific OSes which don’t include any mobile OS.
I’ve built a bunch of browser tools. Before I start coding a new one I pause and ask myself, “Bookmarklet, Greasemonkey script, or add-on?” in that order. Here’s the high-level trade off analysis:
- Bookmarklets generally work across all browsers. They’re plain JavaScript which I know pretty well. But they have no special privileges, so things like same domain restrictions still apply.
- Greasemonkey scripts work across several of the major browsers. They’re mostly JavaScript with a small API that unfortunately varies by browser, so they’re slightly more complex to build than bookmarklets. The benefit over bookmarklets is they have greater functionality including automatic launching and cross-site XHR.
- Browser add-ons are the most powerful, but they’re also the most complex to build. The development stack is different in each browser, and most non-major browsers don’t support add-ons.
For mobile our hands are tied – bookmarklets are really the only choice right now. Over the weekend I wanted to start analyzing mobile browsers so I found some useful bookmarklets to do that: Firebug Lite, DOM Monster, SpriteMe, CSSess, and Zoompf. I also built a new one: Page Resources.
Setting up bookmarklets in a desktop browser is easy, but it’s more painful in mobile browsers. I wasn’t looking forward to setting up each of these bookmarklets on multiple devices, let alone evangelizing that to other mobile developers. In email with Thomas Fuchs about making DOM Monster open to the public (which he nicely did) he suggested I create a meta-bookmarklet that linked to these other bookmarklets. So I did!
Now you can install the Mobile Perf bookmarket and get access to a variety of other bookmarklets through a simple popup menu. One stop shopping for bookmarklets! This works equally well in desktop browsers, but it’s especially helpful on mobile where setting up bookmarklets is more time-consuming. (Checkout the step-by-step mobile installation instructions – quite a bit more complex than a simple drag-and-drop.)
You can see screenshots of each bookmarklet on the Mobile Perf bookmarket home page. As usual I could use help with the UI. (You can see mobileperfbkm.js and pageresources.js, so just send me patches.) Certainly send me bugs and suggestions for other bookmarklets you think should be added. Before sending a suggestion please test it on some mobile devices and make sure it works well.
Next I’ll be analyzing a bunch of websites and seeing if I can find some core issues. Plus I’ll be enhancing these tools and trying pcapperf with my new 13″ MackBook Air to generate HTTP waterfall charts and Page Speed reports.
Maximiliano Firtman | 11-Jan-11 at 1:19 pm | Permalink |
Excellent Steve. I will look forward for your conclusions. Mobile Perf meta-bookmarklet is a great idea. Take a look at ad.ag/dptdgj (from iOS) to see a nice bookmarklet installation instructions.
Dave Hulbert | 11-Jan-11 at 3:03 pm | Permalink |
Excellent work. If it’s any help, Nokia’s MicroB browser as used on their N900 supportes extensions and has Greasemonkey.
John Clegg | 11-Jan-11 at 3:44 pm | Permalink |
Hi Steve,
Thats fantastic work.
Is there anything that can test the cacheability of a page on the mobile device?
John
James Abley | 12-Jan-11 at 1:03 am | Permalink |
Steve, great news and I’m very glad that you’re focusing on this area. I’ve often wished for various Firefox / Chrome extensions when working on mobile, but the proliferation of devices and browsers has stopped me trying to work out a better way. I should stop being so lazy!
John,
I’ve used this approach in the past. http://eternusuk.blogspot.com/2010/07/capturing-mobile-network-traffic-on-os.html
Charles proxy is also a good option and is a more focused tool for HTTP than Wireshark.
From the network traffic, you can see which resources are being served in such a way that a device _can_ cache them, and also see whether the device is actually capable of caching the content; i.e. understands caching directives, has it enabled, has space in the cache, etc.
Steve Souders | 12-Jan-11 at 10:14 am | Permalink |
@Maximiliano: Thanks for that link wrapper. I’ll check it out and get back to you.
@John: I’m not sure if you’re asking do browsers respect caching headers, or what is the behavior in the browser’s cache wrt size and purging. For headers, take a look at Browserscope’s Network tests. For size & purging – this is very hard to test. I’ve written tests that fill caches and reverse engineer purging, but you have to download a lot of data and run it over a long period of time.
@James: I recommend you then take the pcap file from Wireshark and run it through pcapperf to generate a HAR file that is easy to use with well known tools.
rouli | 13-Jan-11 at 6:03 am | Permalink |
If there’s anything I can do to help (as in helping in developing tools), I’ll be happy to do so.
Just a word of warning against using proxies in order to monitor mobile web traffic. It might be obvious, but from my experience, on the iPhone this cancels out any benefit gained by domain sharding. When a proxy is configured, mobile safari limits the number of connections it opens concurrently, as though as it was accessing one domain.
Steve Souders | 13-Jan-11 at 8:46 am | Permalink |
@rouli: You could work on pageresources.js. Initially all I gathered from the resource’s DOM element was the URL. For images I collect the width & height. What else could be gathered that would be of interest? If you could get script.text.length then we’d have the size. (I tried this but couldn’t access the .text property.) Could we do the same for stylesheets? Anyway, that’s one specific area – enhancing the information reported for resources by pageresources.js.
Aaron Peters | 14-Jan-11 at 3:48 am | Permalink |
hi Steve,
I tried to install the bookmarklet on my HTC Hero (Android) today and it fails. I get an “URL is invalid” message when pasting the JS in the URL field for the bookmark.
Can you please talk to your smart Android colleagues and post a how-to if you have a solution? Txs.
rouli | 17-Jan-11 at 5:18 am | Permalink |
Steve, the .text and .innterHTML properties of a given script seem to be unavailable to scripts not on the same domain.
Firebug Lite gets the text by making another Ajax call. I’ve taken Firebug’s Ajax code and incorporated it into pageresources just as a proof of concept, and it works fine for me on firefox and iphone. The code can be found here:
http://pastebin.com/ADemJVgB
Anyhow, there are many problems with that method (not taking compression under consideration, for example). I wish there was a better way …
Steve Souders | 17-Jan-11 at 9:23 am | Permalink |
@Aaron: I’ll look into the Android.
@rouli: The Ajax call would only work for scripts on the same domain.
rouli | 18-Jan-11 at 12:58 am | Permalink |
Yes, and then even the mighty lite firebug fails. Do you see any way to bypass it (without using some third party server)?
Steve Souders | 18-Jan-11 at 3:21 pm | Permalink |
@Aaron: On my Nexus S I had to replace “%20″ with ” ” in the bookmarklet URL. Does that work for you?
Patrick Mueller | 24-Jan-11 at 10:16 am | Permalink |
If the only issue between iOS and Android bookmarklets is the space/%20, then get rid of it. The only place you have a space is after “var”. Instead of var’ing that variable, pass it in as a parameter to the function you define and then invoke. Just tried this myself and it seemed to work fine.
Steve Clay | 24-Jan-11 at 5:19 pm | Permalink |
You probably know about this, but Opera Mobile can be connected to the desktop Opera’s Dragonfly debugger. tutorial and video demo
Steve Souders | 29-Jan-11 at 10:41 pm | Permalink |
Someone tweeted about Quix – a bookmarklet that a commandline that supports ~100 commands including Firebug Lite, SpriteMe, and view source.