Browser Automation
Browser automation have become an important part of how modern websites are built, tested, and deployed. Automation setups range from scripts to run on local machines to deployments in CI servers running Jenkins, CircleCI, TeamCity, Bamboo, GitLab, Buddy, Travis CI, Codeship, GoCD, Wercker, Semaphore, Nevercode, Spinnaker, Buildbot, etc as well as in the cloud. Browsers have long supported some level of automated control through third-party driver software.
@Potch in his article explains the idea of headless in simple words that, browsers are at their core a user interface to the web, and a graphical user interface in particular. This poses a few problems for automation. In some environments, there may be no graphical display available, or it may be desirable to not have the browser appear at all when being controlled. This has required tools like virtual display software in order to run properly, adding complexity.
Before the idea of headless came into practice, the best way to load webpages without displaying UI was PhantomJS, which is based on WebKit. It still remains as a valuable tool to be able to run automated browser tests in official browsers, and so it’s valuable to have a headless mode available.
Firefox in Headless Mode
In headless mode Firefox is run as normal, minus any visible UI components visible. Though not so useful for surfing the web, it comes into its own with automated testing.
References
You can find a couple of relevant discussions in: