Show HN: Chrome Remote Debugging Protocol interface

Show HN: Chrome Remote Debugging Protocol interface(github.com)

38 points by cyrusand 9 years ago | 7 comments

wslh 9 years ago |

A few years ago I used the Chrome remote interface and was very slow comparing to embedding a web control object for automation. How does it work now?

cyrusand 9 years ago | |

Actually I didn't notice such thing when I used it extensively around 2013 for instrumenting some page loads. Which part was slow in your experience?

wslh 9 years ago | | |

If I remember well was slower than using HTMLUnit (http://htmlunit.sourceforge.net/) that is written in Java, and it was much slower than writing a browser extension to achieve the same task.

pault 9 years ago |

What is the use case for this? Testing? Scraping?

paulirish 9 years ago | |

Everything, really. The protocol is a layer underneath the WebDriver protocol, and what Chrome DevTools uses. So it's pretty much the most complete API for the browser; in fact, Chrome is shipping the protocol as the 1st class API for headless Chrome .

We use it in Lighthouse [0] to reload the browser, manipulate ServiceWorkers and caches, execute a bunch of tests on pages and measure performance characteristics. I've also used it for automated profiling [1], in case you want to profile your JS with a bit more control. Using this for testing or scraping would work as well, but you might as well move a layer up and use WebDriver as the commands will be fairly common.

[0] https://github.com/GoogleChrome/lighthouse/

[1] https://github.com/paulirish/automated-chrome-profiling/

ianbicking 9 years ago | | |

How realistic do you think it is to add to the protocol? I've played with it some and it can be great for what it has, but I want just a little bit more... like a way to view user-generated events. I'm debating whether to play with an extension, or with the protocol itself.