Web Performance Calendar

The speed geek's favorite time of year
2019 Edition
Robert Boedigheimer

Robert Boedigheimer (@boedie) works for Schwan's Home Service providing business solutions with web technologies. He is a Microsoft MVP, a Progress Developer Expert (Fiddler), an ASPInsider, a Pluralsight author, and a 3rd degree black belt in Tae Kwon Do. Robert regularly speaks at national and international events.

Fiddler is a great free web troubleshooting tool that has been available on Microsoft Windows since 2003 with a new cross-platform version called Fiddler Everywhere currently in beta. Fiddler functions by acting as a proxy between the web client and the web server, which gives it the ability to not only monitor traffic but also manipulate the traffic (and yes, it even works with HTTPS). There are many times as a web developer where it is useful to simulate particular situations to determine the impact it will have on page rendering and user experience. It has an AutoResponder feature with many capabilities, one of the most interesting is the ability to add an artificial delay to responses.

How Fiddler Works

When Fiddler is started, it changes the system proxy configuration to route HTTP and HTTPS requests to (the local machine) and the default Fiddler port 8888. Modern browsers read the proxy information and direct requests to the local machine and port where Fiddler can intercept and either monitor or change the traffic as desired. As mentioned, Fiddler can be configured to decrypt HTTPS (which you are using on your site, right?).


The easiest way to take advantage of AutoResponder is to simply start Fiddler and request the page you want to troubleshoot. We want to use Fiddler in these cases to add an artificial delay to see how it impacts performance and rendering, and code differently to work around those impacts. Once the page has been requested, just drag the individual resource you want to delay to the AutoResponder tab which will create the basic rule structure.

CSS font-display

Web fonts have been a great addition to the web for developers and designers. They allow web sites to use fonts that might not normally be available on the client. Since these files need to be downloaded, browsers had to decide what to do with text in these custom fonts while the resources are being acquired. Browsers typically either used FOUT (Flash of Unstyled Text) where they initially render in a fallback font until the custom font is available, or they use FOIT (Flash of Invisible Text) where they doesn’t display anything until the custom font is available, or some combination of those. In order to see these default browser behaviors, we want a mechanism that allows us to control how long the font download will take.

Here is an example web page that uses the Lobster Two font downloaded and hosted locally. The web page references the font files on lines 9 and 10

With this web page hosted on a web server, open Fiddler and a web browser and request the page and Fiddler will show the necessary requests like this

Simply drag the request for the .woff2 font file to the AutoResponder tab and it will create a basic rule which we can change to respond with a delay of 10000ms (10 seconds) and press the Save button. We also check the “Enable rules” and “Unmatched requests passthrough” (requests that don’t match rules just continue to the server normally)

Now when we open Chrome and visit the web page the web font will take 10 seconds to download so we can see how it is rendered while waiting. Chrome 79 uses FOIT so the content area is blank for about 4 seconds, then it uses FOUT to show a fallback font, then finally after 10 seconds it shows as intended.

If we try Edge 44, it immediately displays the text using FOUT with a fallback font, then eventually shows as intended.

CSS now provides the ability to use the font-display property to influence how browsers behave more consistently. Setting font-display: swap instructs compliant browsers to always use FOUT while the download of the custom font occurs.

Async and Defer

Another practical example of using Fiddler’s AutoResponder feature is to demonstrate the JavaScript async and defer attributes. Here is an example of some JavaScript files included above some content:

Originally browsers would wait when they encounter a <script> tag, wait for the download to finish and then execute the script before continuing. Modern browsers will typically download these files in parallel but still wait to execute them all before rendering the “Content”. This can be demonstrated using the Fiddler AutoResponder by creating rules for these JavaScript files with various delays (drag the files over and set delay values similar to above example)

Fiddler recently added the ability to group rules in AutoResponder as you can see with the “Async and Defer Demo” header which really helps organize when a lot of rules are present. With these rules in place, modern browsers will download the 3 JavaScript files in parallel and when the slowest is done (alert1.js) it will execute them in source order (alert1.js, alert2.js, alert3.js). During those 8 seconds the web site visitor is staring at a blank page! By adding the async or defer attribute to the <script> tags you are indicating the content is not dependent on those files so the content can be immediately displayed while the JavaScript files are downloaded. For more nuanced description of defer vs async, see Steve Souders’ article from a previous Calendar edition.


The display-font CSS property and JavaScript async/defer attributes are great, but the important point is that Fiddler AutoResponder provided a convenient way to enforce a specific delay on the response in order to discover how browsers would behave and a method to test when we make modifications to improve the user experience when downloads might be delayed. There are many other awesome features in Fiddler, so check out some of the resources below!