Web自动化
这里所说的Web自动化是所有跟页面相关的自动化，比如页面爬取，数据抓取，页面内容检测，页面功能测试，页面加载性能测试，页面回归测试等等，当前主要由如下几种解决方式：
文本数据获取
这就是各种request库或者类似curl这样的工具做的事情，拿到的是页面的文本，然后进行XML文档解析，获得相应的内容。但如果页面有一些动态执行的内容，比如JavaScript生成跳转URL，这样就搞不定了，需要有JS引擎的工具来搞，比如再配合JS引擎自行实现的工具，或者直接使用浏览器内核来搞的工具。
按照浏览器的方式来执行
这就是各种使用浏览器内核来实现的工具，比如基于Webkit的PhantomJS, 基于Gecko的SlimerJS, 经过包装的CasperJS兼容PhantomJS和SlimerJS，以及基于v8JS引擎和.net平台的trifleJS等。这些工具更新迭代跟不上Web标准的发展，新的Web标准无法得到良好的支持。
通过协议直接操作真实浏览器
这就是Selenium的实现方式，通过WebDriver协议进行通信，浏览器和浏览器驱动都实现了C/S结构的WebDriver协议,Selenium通过浏览器的驱动包，来发送操作请求，浏览器根据请求响应相应的操作。这样实现有一个问题是始终有一个真实浏览器的界面在渲染和变化，一方面效率低下，另一方面在服务端环境无法运行。于是就衍生出了使用Xvfb(virtual framebuffer X Server) 来配合实现在服务器环境下的运行，基本解决了问题。但每一种浏览器的特性支持都依赖于相应的驱动的实现和支持情况。
无界面浏览器
前面的实现方式都或多或少有自己的问题或者局限，如果浏览器本身支持在服务端环境运行，这将是一个近乎完美的解决思路。Chrome 59开始支持无界面模式，Firefox 55支持Linux版的无界面模式，Firefox 56支持全平台的无界面模式，这样一来，使用方不用被动等待浏览器的WebDriver的实现。
Headless Chrome相关的对比
Headless 是一种在无图形界面环境运行的一种能力，比如高性能的服务器端环境，参考。
PhantomJS的问题
使用老版本的Webkit，不支持新的Web标准，跟真实浏览器存在差异
开发者维护难度大，，起因是Chrome 将支持 Headless模式
要解决的问题多，1800+
内存占用高，并发有问题，不稳定，有些奇奇怪怪的bug
Selenium的问题
使用接口和浏览器驱动来操作真实浏览器，带界面渲染，速度慢
需要有图形界面，显示设备的支持
-
需要使用（virtual framebuffer X Server）
X是架构无关的远程图形界面和输入设备兼容的系统，C/S架构
在没有物理输入和显示设备的机器上运行
这里可以简单理解为虚拟显示器或者显示器模拟器
也支持Headless实现，实现跟Web标准有差异
-
通过(WebDriver的Chrome实现)的来操作Chrome，需要依赖ChromeDriver的更新
可以在查看支持的Chrome版本
Headless Chrome带来的优势
资源占用少（相对于PhantomJS）
服务端环境(命令行，无图形界面)
支持现代Web标准和技术(ES6,ServiceWorkers,WebGL...)
行为符合Web规范、版本能自动更新
Chronium/Chrome团队维护