Chrome 59 has cross-platform headless support

Post by 19eightyfour » Thu, Apr 13, 2017, 8:33 AM UTC

jotto wrote: post #92

nreece wrote: post #68

I've been testing Chrome headless extensively for the past few months, and while it's a good step, but it's not stable for high-volume or even diverse set of webpages. Memory usage is pretty high, lot of heavy webpages result in crashes/hangs, there are many inconsistencies between features available in full version and headless, their debugging protocol has different APIs that work on headless/non-headless in Linux…

I've been successfully using Chrome headless in a 500MB Docker container for dumping the DOM for https://www.prerender.cloud/ for months (rendering a large variety of sites without restarts for weeks at a time) Run it with: --js-flags="--max_old_space_size=500" to force the VM to keep it GC'd below 500 Chrome v55 was a 30% memory savings, before that I used 1GB containers. It's not perfect, but I am definitely pushin…

  --js-flags="--max-old-space-size=500"

  --js-flags="--help"

Post by kenshaw » Thu, Apr 13, 2017, 8:44 AM UTC

chrissnell wrote: post #78

kenshaw wrote: post #30

Earlier quoted context omitted.

If you're using Go, https://github.com/knq/chromedp It's also worth noting that the 57+ series has a nice embedded viewer you can use to view the actual viewport via devtools.

WOW. That's fantastic. As I noted in a comment above, I wrote a tool called crabby that uses Selenium and Chrome headless to do automated page testing and to report results back to metrics engines like Graphite, Datadog, Prometheus, and Riemann. The biggest problem I have is the unreliability of chromedriver and the extreme resource consumption of Chrome + Selenium. It's really too much for your average public cloud…

Post by brazzledazzle » Thu, Apr 13, 2017, 9:53 AM UTC

19eightyfour wrote: post #111

jotto wrote: post #92

Earlier quoted context omitted.

I've been successfully using Chrome headless in a 500MB Docker container for dumping the DOM for https://www.prerender.cloud/ for months (rendering a large variety of sites without restarts for weeks at a time) Run it with: --js-flags="--max_old_space_size=500" to force the VM to keep it GC'd below 500 Chrome v55 was a 30% memory savings, before that I used 1GB containers. It's not perfect, but I am definitely pushin…

That ought actually be: --js-flags="--max-old-space-size=500" Hyphens not underscores. A list of V8 flags can be found with: --js-flags="--help"

Post by codedokode » Thu, Apr 13, 2017, 10:17 AM UTC

adam77 wrote: post #75

erikig wrote: post #54

Earlier quoted context omitted.

https://wkhtmltopdf.org/ You can download the two tools wkhtmltopdf and wkhtmltoimage which use WebKit to generate pdfs/images.

Sadly wkhtmltopdf's version of Webkit is ancient :( No flexbox, no es6, etc...

Post by 2T1Qka0rEiPr » Thu, Apr 13, 2017, 10:23 AM UTC

paulirish wrote: post #63

bluepnume wrote: post #10

This is fantastic. I'm using a combination of Chrome and PhantomJS for karma testing right now, for https://github.com/paypal/paypal-checkout and https://github.com/krakenjs/xcomponent . There are hundreds of tests opening up hundreds of iframes and popup windows, and sending a lot of cross-window messages, and that ends up being really memory hungry. Chrome deals pretty well with garbage collection, so long as I'm c…

We (Chrome) have reached out to PhantomJS to inquire if they're interested in collaborating: https://groups.google.com/d/msg/phantomjs-dev/S-mEBwuSgKQ/tU... The DevTools Protocol is the primary API for headless Chrome, but we are excited for higher-level abstractions like PhantomJS & NightmareJS's API to manipulate the browser as well. Plenty of details to work out, but hopefully sometime this year you'll get a drop-…