Getting your head around chrome headless

2,137 reads

A slew of automation “stuff” has just arrived due to Chrome’s new headless feature in v59 . As creator of snaptest.io, it’s my job to stay up-to-date with them.

So here’s what you need to know:

A headless browser means you don’t see it when you start it, it’s all in memory — and it also implies user actions are automated.

Uses of automation:

QA tests Scraping Pre-rendering single-page apps.

Uses of headless:

Less resource intensive. Great for build-systems running tests before a deploy. Can run in many more server environments, like Lambda.

Is this the first headless automated browser? No, phantomJS has been the goto browser like this, but the main contributor almost immediately stepped down when he heard about Chrome’s new headless feature . Turns out its hard to maintain an ENTIRE browser.

So what’s actually new in Chrome v59?

running the executable like this: `chrome — headless — disable-gpu — remote-debugging-port=9222` which opens it without a visible window.

which opens it without a visible window. then sending commands to the above port… closest to the metal node library is this one .

The above commands give you ability to do almost anything a user would do… so you can scrape data or make tests.

What is the community doing with these new features?

The community has decided that we need a pretty wrapper around this “low level” stuff, and have started making these:

Chromeless (a combination of the words “Chrome” and “Headless” and maybe even “Serverless”). Puppeteer (Googles very own “lightweight wrapper”) Simple-headless-chrome (another wrapper) Ping me if you know of more…

Conclusion:

What’s the state of each of these frameworks? Let’s find out in a couple months once they’ve grown up a bit. Comparing and contrasting right now would be a practice in futility.

Tags