With the increase in 3rd party widgets and modernization of web applications, Frontend Single Point Of Failure (SPOF) has become a critical focus point. Thanks to Steve Souders for his initial research on this topic, we now have a list of common patterns which causes SPOF. The awareness of Frontend SPOF has also increased tremendously among engineers, thanks to some of the recent blogs and articles emphasizing the importance of it.

There are already a bunch of utilities and plugins out there which can detect possible SPOF vulnerabilities in a web application. The most notable ones being webpagetest.org, SPOF-O-Matic chrome plugin and YSlow 3PO extension. At eBay we wanted to detect SPOF at a very early stage, during the development cycle itself. This means an additional hook in our automated testing pipeline. The solution resulted in creating a simple tool which works on our test URLs and produces SPOF alerts. The tool is SPOFCheck.

SPOFCheck is a Command Line Interface (CLI) built in Node.js to detect possible Frontend SPOF for web pages. The output is generated in an XML format that can be consumed and reported by CI jobs. The tool is integrated with our secondary jobs, which run daily automation on a testing server where a development branch is deployed. In case of a SPOF alert, engineers are notified and they act on it accordingly. This process ensures that SPOFs are contained within the development cycle and do not sneak into staging or production.

The command line interface

SPOFCheck provides a simple command line interface and runs on Node.js

To install SPOFCheck run the following

$ npm install -g spofcheck

To run SPOFCheck, use the following format

spofcheck[options]*[urls]*Options
--help | -hDisplaysthisinformation.
--format=<format> | -f <format>             Indicatewhichformat[junit-xml | spof-xml | text]touseforoutput.
--outputdir=<dir> | -o <dir>                Outputsthespofresultstothisdirectory.
--rules=<rule[,rule]+> | -r <rule[,rule]+>  Indicatewhichrulestoinclude.
--print | -pOutputstheresultsinconsole,
                                              insteadofsavingtoafile.
--quiet | -qKeepstheconsoleclearfromlogging.

Example

$ spofcheck -f junit-xml -o /tests www.ebay.com www.amazon.com

Rules

SPOFCheck by default runs with 5 rules (checks). The rules are maintained in the rules.js file. New rules are easily added by pushing entries to the rules array or calling the spof API registerRules. The default rules come from Souders’s original list outlined below.

  1. 3rdparty-scripts – Always load 3rd party external scripts asyncronously in a non-blocking pattern
  2. application-js – Load application JS in a non-blocking pattern or towards the end of page
  3. fontface-stylesheet – Try to inline @font-face style. Also make the font files compressed and cacheable
  4. fontface-inline – Make sure the fonts files are compressed, cached and small in size
  5. fontface-inline-precede-script-IE – Make sure inlined @font-face is not preceded by a SCRIPT tag, causes SPOF in IE

Output

SPOFCheck creates a file and writes results in one of these formats:

  • junit-xml – a format most CI servers can parse (the default format)
  • spof-xml – an XML format that can be consumed by other utilities
  • text – a textual representation of the results

The format can be specified using the --format or -f option. For just printing results, i.e. no file creation, use the --print or -p option.

A SPOF Free World

Our primary goal was to eradicate frontend SPOF before it creeps in, and SPOFCheck is a step towards it. Go ahead, give SPOFCheck a try and integrate it with your CI environments. Let’s build a SPOF Free World :-).

Thanks to github projects spof-o-matic and 3po, a lot of the code logic has been re-used here. The design and packaging of the tool is based on csslint, thanks to Nicholas Zakas and Nicole Sullivan.

ABOUT THE AUTHOR
Senthil Padmanabhan photo

Senthil Padmanabhan is a Principal Engineer & Frontend Lead at eBay. Prior to eBay, he worked in the Yahoo! Mail team as a frontend engineer building the new mail web application. He specializes in Web Performance and Frontend Architecture. Some of his previous works include the Cache Warmer and Data URI Sprites

He frequently blogs at eBayTechBlog under Software Engineering category and is active on github in his free time. He can be found at twitter via @senthil_hi

6 Responses to “SPOFCheck – Fighting Frontend SPOF at its root”

  1. Cliff Crocker

    Great work! Awesome to see this. I often run into developers who struggle with creating performance tests as part of their release process. Thanks for the contribution – another great tool for the quiver.

  2. Early Detection of Frontend Single Points of Failure — eBay Tech Blog

    [...] Thanks also to perfplanet, who featured SPOFCheck in their 2012 performance calendar. [...]

  3. The Many Kinds of SPOF | Zoompf

    [...] receiving a lot of research. Be sure to check out the work of Steve Souders as well as tools like SPOFCheck to learn more [...]

  4. techno blog

    With the rise in third party widgets and modernization of net applications, Frontend Single purpose Of Failure (SPOF) has become a vital focus purpose. due to Steve Souders for his initial analysis on this subject, we have a tendency to currently have a listing of common patterns that cause SPOF. the attention of Frontend SPOF has conjointly accumulated hugely among engineers, due to a number of the recent blogs and articles action the importance of it.

  5. Athena

    Hello to all, it’s actually a good for me to pay a visit this web page, it consists of helpful Information.

  6. Marco

    Hi, i think that i saw you visited my website so i came to
    “return the favor”.I’m attempting to find things to improve my site!I suppose
    its ok to use a few of your ideas!!

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
And here's a tool to convert HTML entities