Show HN: Chrome Remote Debugging Protocol interface(github.com)
github.com
Show HN: Chrome Remote Debugging Protocol interface
https://github.com/cyrus-and/chrome-remote-interface
2 comments
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?
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?
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.
I see, well I've never performed any benchmark but it's quite possible that an ad hoc headless browser performs better for what concerns repeated tests. On the other hand, in this case you're instrumenting a real (really employed by the final user) browser. Possibly things will improve with this new headless mode for Chrome.
In any case this JavaScript module should not introduce any performance degradation, but if it does and you happen to give it a try in the future, feel free to open an issue.
In any case this JavaScript module should not introduce any performance degradation, but if it does and you happen to give it a try in the future, feel free to open an issue.
What is the use case for this? Testing? Scraping?
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/
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/
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.