Until fairly recently, a single point of failure (SPOF)—a condition that can bring down an entire system—has been predominantly associated with the backend world of server clusters, networking, and operations. However, with the increase in third-party widgets and the complexity of modern web applications, the web community is increasingly aware that a frontend SPOF can also bring down an entire site. As a result of a frontend SPOF, the user sees an entirely or partially blank page, or experiences delayed rendering of the page.
This post describes a tool developed at eBay, called SPOFCheck, which has been open-sourced and is being integrated into engineering life cycles not only at eBay but globally.
Background
The awareness of frontend SPOF has increased tremendously among engineers, thanks to Steve Souders’ initial research on this topic, as well as recent articles and blogs emphasizing its importance; see, for example, Bjorn Kaiser’s post about third-party content causing SPOFs. Numerous utilities and plugins exist that can detect possible SPOF vulnerabilities in a web application, most notably webpagetest.org, the Chrome plugin SPOF-O-Matic, and the YSlow 3PO extension.
At eBay, we wanted to detect SPOF at a very early stage, during the development lifecycle itself. Such early detection would require an additional hook in our automated testing pipeline. The solution we developed and open-sourced is SPOFCheck, a simple tool that works on our test URLs and produces SPOF alerts. The tool is integrated with our secondary jobs, which run daily automations on a testing server where a development branch is deployed. When SPOFCheck detects possible vulnerabilities, engineers receive SPOF alerts and act accordingly. As a result, SPOFs can be contained within the development cycle, rather than sneaking into staging or production.
Command-line interface
SPOFCheck is a command-line interface (CLI) that runs on Node.js. Source code, syntax, and usage documentation are available in GitHub. Running SPOFCheck involves simply specifying the output directory. Command-line options include output format (XML that most CI servers can parse, XML to be consumed by other utilities, or text), console-only output, and the rules (checks) to be run. By default, SPOFCheck runs the following rules:
- Always load third-party external scripts asynchronously in a non-blocking pattern.
- Load application JS in a non-blocking pattern or towards the end of the page.
- Attempt to inline the @font-face style; ensure that the font files are compressed and cacheable.
- Ensure that the font files are compressed, cached, and small in size.
- Ensure that inlined @font-face styles are not preceded by a SCRIPT tag (which causes SPOFs in Internet Explorer).
Extensibility
New rules can be easily added, either by pushing them to the rules array or by calling SPOFCheck’s registerRules function.
At eBay, we’ve built a thin web client to provide SPOFCheck as a service. eBay engineers can create multiple SPOF projects, which can be triggered on demand or configured to run on a recurring schedule. Project owners designate the teams or individuals who receive SPOFCheck results.
Acknowledgements
Thanks to Steve Souders, whose work (cited above) is the source of SPOFCheck’s default rules.
SPOFCheck reuses code logic from the GitHub projects spof-o-matic and 3po. The design and packaging of the tool is based on csslint, thanks to Nicholas Zakas and Nicole Sullivan.
Thanks also to perfplanet, who featured SPOFCheck in their 2012 performance calendar.