Readers' experience with HTML smudging
From TBTF for 1999-03-01

TBTF for 1999-03-01 discussed the theory of HTML smudging -- a gradual degradation of the code base of the Web caused by inattention (human and programmatic) to maintaining consistent, unambiguous HTML structure on rapidly changing Web pages. Before and after pages were offered for readers interested in experimenting to validate whether or not a "smudge" effect could be measured. Here are some readers' responses (newest at the top).

• 1999-03-02: tomas montgomery <tomas at pluto dot njcc.com>: win95-4.00950a; navigator-4.5; 33 kbps
  before-smudged.html 13 seconds
  after-unsmudged.html 9 seconds

• 1999-03-02: Dave.Gatliff <Dave.Gatliff at yellowcorp dot com>: WOW -- Before--> almost 5 seconds, After--> about 2 seconds.

  OS -- Win NT 4.0 SP3, MSIE 5.00.0910.1309, T1 connection.

  Keep up the good work!!!

• 1999-03-02: Staci Munday <munday.staci at ev dot state dot az dot us>: The smudged page took 4 seconds and the unsmudged took 2. I'm on IE4, NT4, on a T-1.

• 1999-03-02: Jason Irwin <Jason.Irwin at capgemini dot co dot uk>: Old version - about 7 secs.
  New Version - about 3 sec.
  Running Window 95 with IE4.01

  One solution would be to provide HTML checking tools. I have not come across a HTML editor yet which does strict checking on HTML syntax, most just try and show you what the page looks like. It would also be helpful if these tools didn't automatically include tags and 'bots that the coder didn't put there. I must admit, I do not have a great deal of experience with direct HTML coding.

  Another method is to stop non-technical users updating web pages directly. Let them load into a database back-end from which the content is loaded. This should stop smudging.

• 1999-03-02: Erik Hovland <ehovland at mail dot instanet dot com>: First Post... Oops wrong website.

  OS: GNU/Linux slackware 3.4 with 2.0.36 kernel
  Browser: Communicator 4.08
  Connection: ISDN, 115kbps
  smudged: 7.6s
  unsmudged: 6.2s

  Not much of a difference either way. Noticed that the unsmudged did a better job of displaying the page before it was done downloading. TBTF is not necessarily a good page to demonstrate this with since it is by nature not as cluttered as other pages. Think we could identify a culprit and mirror it and a unsmudged version of it?

  TBTF rocks! Thanks.

• 1999-03-02: Richard Thomas <rmt at winterfold dot com>: Really good newsletter, thanks. Your smudged / unsmudged pages:

  Before - 7 seconds
  After - 4 seconds

  NT4, Pentium 200, NetScape 4.05, 64K line to UUNet in the UK.

  I'm off to check my own pages...

• 1999-03-02: Scott Hess <scott at doubleu dot com>: I fully agree that "clean" HTML is best, and have spent the last year working with XML to see how it can fit within our system.

  But the smudged-unsmudged test is silly. How can you possibly compare the time to update for two different files over the Internet from a production webserver using a stopwatch with a browser that you can't trust? There are too many places for potential delays to occur.

  In fact, it could be that it's your webserver which handles smudged HTML more slowly than unsmudged HTML.

  I just downloaded the source to the pages in question to my local filesystem, and my browsers all bring them up much too quickly to really measure how long it takes, let alone measure a difference between the two pages.

• 1999-03-02: Thomas Tavoly <aTmosh at amiga dot cistron.nl>: AmigaOS 3.1, AWeb 3.2, ~3 Mbit cablemodem, both versions loaded in about 2.8 seconds, including image rendering. Test machine was an Amiga 4000 with Motorola 68060/50 MHz, 66 MB memory. See here for machine details.

• 1999-03-01: Greg Roelofs <newt at pobox dot com>: About 6 seconds either way with NN 4.07 (nothing but CSS enabled) under Linux 2.0.36 on a P100. On the other hand, anything with large tables just sucks. Slashdot is a primo example. I'll be way too happy when Mozilla 5.0 is ready.

• 1999-03-02: Wendell Piez <wapiez at mulberrytech dot com>: Is XML the only thing that can save the web from itself?

  Although you do not say so, your observation implies a long-term case for XML, with its draconian well-formedness-handling and its support for external validation of document types. Without it, we have both the "degrading code base" described, and the associated browser bloat, choking the marketplace and stalling innovation. With XML, we can simply dump HTML and start fresh with decent tag sets tailored to our requirements. (Well, HTML will probably stick around as a de-facto display language for the web....)

• 1999-03-01: Jason Kottke <kottke at bitstream dot net>: Someone pointed me to Tidy. It's a tool for cleaning up bad code. BTW, thanks for the interesting article. I now have some new things to think about when coding.

  [ Editor's note: Kottke maintains a fabulous collection of ancient Web browsers. Turn on JavaScript before visiting. ]

• 1999-03-01: Bill Scanlon <wscanlon at execpc dot com>: My OS is Win98 on a 300 MHz machine and I am using Netscape 4.5.

  Summary: Smudginess is undesirable, but I could find no statistically supportable evidence with my system and the two pages you made available for testing that eliminating smudginess improves rendering speed significantly.

  Last night I did the test using a nominally 115 kbps ISDN connection. I have recalculated the results from that test, which involved first 5 downloads in a row of the "smudged" page and then 5 in a row of the "desmudged" page. For the smudged page, the average time to render was 16.2 seconds (standard deviation: 6.3 seconds). For the desmudged page, the time to render was 10.8 seconds (standard deviation 3.4 seconds). The test was run between about 5:45 and 6:00 PM CST (on a Sunday). These results indicate at most only a slight, statistically significant improvement in rendering time from reducing smudginess.

  This morning I did the test on two different analog connections, both nominally 56 kbps, one through a Milwaukee, WI isp, to which I am connected by a local call in Madison, and the other through the MSN network, to which I also connect through a local call in Madison. On each of the connections, I did 15 cycles of a download of the smudged version followed by a download of the desmudged version.

  The downloads through the local isp were done between 7:26 and 8:02 AM CST (on a Monday). This, of course, is when the Net is being heavily accessed by people just after arriving at their offices in the Eastern and Central time zones after the weekend. The average rendering time for the smudged version was 21.0 seconds (standard deviation 1.2 seconds). The average rendering time for the desmudged version was 20.7 seconds (standard deviation 1.4 seconds). The difference in rendering times is not statistically significant.

  The downloads through the MSN network were done between 8:35 and 8:57 AM CST (on a Monday). During this period, the Net is being accessed significantly less heavily than an hour earlier, because the early morning rushes in the Eastern and Central time zones are about over while the much lighter one in the Mountain Zone (with its significantly lower population) is still ramping up and the one in the Pacific Zone has not yet started. The average rendering time for the smudged version was 13.9 seconds (standard deviation 1.4 seconds). The average rendering time for the desmudged version was 13.5 seconds (standard deviation 1.0 seconds). Again, the difference in rendering times is not statistically significant.

  At least with the smudged and desmudged pages and the OS/browser combination used in the tests conducted here, it appears that there is very little or no improvement in rendering time attributable to desmudging.

  There are a number of factors that might explain this lack of observed improvement, even if there is some theoretical reason to believe that there should be some improvement. First, background due to random variations in transfer times over the Net might hide any improvement there might be from desmudging. It is not possible to determine from these tests whether an increase in smudginess would at some point allow an improvement in rendering time to be observed. To make such a determination, it would be necessary to test a page with at least three different levels of smudginess, including possibly the corresponding, completely smudge-free page.

  Second, so many people might have been accessing your server this morning in order to review or download the March 1 issue of TBTF that the dominant factor by far in determining rendering speed (i.e., the "rate-limiting factor") would have been delay in gaining access to your server. This would again represent a masking by characteristics of net traffic of any theoretical gain there might be due to desmudging.

  The chance is high that early yesterday evening (a Sunday evening), when I ran the tests with ISDN connectivity just a short time after you sent the e-mail version of TBTF for March 1, traffic to your server was much lower than it was this morning. This significant reduction in net-traffic background might be why a barely statistically significant improvement in rendering time was observed yesterday evening but could not be observed this morning.

  Finally, it is possible that, at least with a 300 MHz Netscape 4.5 system, smudging can be compensated for so well by the system that desmudging does not yield any gains until the smudging becomes so bad that a page cannot be successfully loaded at all.

  Much more data is needed to establish that smudging is a problem for rendering speed that needs attention anytime soon.

  I do agree though that smudginess represents both sloppiness and potential problems down the road. So, considering both the elegance of doing things properly and the desirability of avoiding problems over the long run, smudginess is something to be avoided and something that purchasers of webpages should, for their own good over the long haul, insist on and be willing to pay for.

• 1999-03-01: WJ Shack <wjshack at anl dot gov> smudged 7 secs; unsmudged 3 secs.
  Mac 7.6.1 Power Wave 200 Mhz 604e
  very high speed internet (>T1)

• 1999-03-01: Walter Belgers <Walter dot Belgers at nl dot cis dot philips dot com>: I tried loading your smudged and unsmudged HTML pages. The difference was clear. I measured approx. 4 versus 2 seconds on a FreeBSD 2.2.7 system running Netscape Communicator 4.5 behind a big pipe (9Mb).

• 1999-02-28: Danny Sullivan <danny at calafia dot com>, editor of Search Engine Watch: It's not exactly smudging, but create a blank HTML file in Word 2000, and you'll discover it takes up 5K in size. Reason: insertion of style codes you may or may not have wanted — and no way to disable the behavior, that I can find. But to be fair to MS, the newer versions of FrontPage are much better at not making unwanted changes.

• 1999-02-28: Graystreak <wex at media dot mit dot edu>: I tried your smudged-vs-unsmudged test (PII 200 on an ISDN line). 7 seconds for the first one, 2.5 for the second.

  However, there's at least one complicating factor here, and that's the routing. Although TCP/IP isn't a circuit protocol, the effect of fetching a page (or otherwise touching a remote site) is somewhat circuit like.

  Specifically, every machine between me and you has to know how to route the packets. If the next hop in the chain is in the machine's cache, then the lookup is fast and the packet moves out quickly. If even one site has to look up an address or do a name-to-IP-number translation that can slow things down.

  Thus the test is, at least potentially, order-dependent. Since you gave the before-smudged page first, it will be more likely to be hurt. That's not to say that your basic concept is wrong, just that your test needs to eliminate other factors first. Perhaps by running a traceroute first?