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-03: Tom S. Asbury <tom at bridger dot com>: Win 98, IE 4.01, fractional T1, no observable difference (5 sec). Time was 6:08am MST.

• 1999-03-02: James Tauber <jtauber at jtauber dot com> >Table-based layout is bad.

  Now if only browsers supported CSS properly!

  There was a time when Hn elements were abused to control font size (probably still happens). FONT elements were only slightly better (but at least you said what you meant).

  Then we got the table hacks:

  • tables to do margins (multiple ULs were used for this too but it didn't work on IE), particularly when you had a background with some colour or pattern on the lefthand side.
  • tables to do columns and/or side navigation bars (I admit, I'm guilty)
  • tables to do background colours (I remember using this with a beta of Netscape 3 for a presentation I gave while working at Sun Labs in early 1996. Everyone asked me afterwards how I did the background colours. I'm still guilty of this, though I generally use CSS for it now).

  I resolved a little while ago to do (almost) everything with CSS (and now XML+XSL->HTML+CSS).

  Inspired by Jakob (who I notice is CCed on this thread now -- hi Jakob!) I now do entirely *text* navbars and encourage my students to do so too (I run an undergraduate and graduate course in website management).

  Table hacks for columns and side navbars are about all that remains. I can't wait until I can ditch them for CSS2.

• 1999-03-02: Bertrand Ibrahim <Bertrand dot Ibrahim at cui dot unige dot ch>: Solaris 2.6, Sun UltraSparc 10, Netscape Communicator 4.5, connectivity 10 Mbits/sec.

  Page [12] loaded in ~11 sec. and page [13] in 6.5 sec. However, these numbers cannot be meaningful, as there were images in [12] that had to be fetched for the first time, and were already in the local cache for [13].

  For a more meaningful comparison, you should have used equivalent pictures, but with different file names in both documents so as to make sure that the same number of files are fetched for each version.

  Once loaded in the local cache, page [12] took 1 sec. and [13] 0.6 sec. to re-display. However, the error margin on these figures is quite high, as I was clocking the loading time by hand, with a stopwatch. It is therefore difficult to draw conclusions.

  But, anyway, never let facts interfere with a good story :-) Regardless of whether your theory is founded or not, advocating for cleaner HTML code can only be a good thing.

  The conditions under which this experiment could give more meaningful results should, in my opinion, be:

  • preload both versions, so that they reside in the browser's local cache (making sure that the cache is large enough ro contain all the elements of both documents), thus isolating the experiment from loading times;
  • use a low-end machine so that display time is longer, thus reducing the relative error of hanp-operated stopwatch measurements

  Since I have an old 386-based PC with 6 Mbytes of RAM, running windows 3.1 in a corner of my office, I thought I could try the experiment. I installed Opera 3.51, made sure the cache would be big enough to hold all the elements of the two versions of your test document, accessed both documents and ensured that the setup was such that the browser would use the cached copies. I tried a few times to go back and forth between the two versions and always got for both an average display time of 14 seconds (more less half a second).

  This leads me to believe that, at least for the Opera browser, the quality of the HTML code doesn't have much of an influence on the display time.

• 1999-03-02: Michael Bryan <michael at ursine dot com> I think I've found the primary answer as to why some tests show a marked difference between the two pages, and others see no statistically significant difference. It's a cache issue, and I suspect your conclusions are very likely incorrect.

  When I first looked at your "before" and "after" pages, I got the following results:

  System: Windows 95b, AMD K6-233, Netscape Communicator 4.5 Network: 44000 bps dialup connection to a very well connected ISP (colocated with AboveNet)

  Before/Smudged: 10 seconds After/Unsmudged: 4 seconds

  The results were -very- consisitent. I flushed the disk and memory caches before each test, and was fairly confident that the results/effects were real.

  However, when I visited your site today, I noticed some of the comments you have added. I then did another set of tests, only I reversed the order in which I tested them, doing the unsmudged page before the smudged page. Guess what? The numbers flipped:

  After/Unsmudged: 10 seconds
  Before/Smudged: 4 seconds

  What? How could this be? I'm not using a proxy server, so this is a direct connection to you. The answer was glaringly obvious after a moment of reflection, and examination of the HTML source confirmed my suspicions: both pages reference the -same- image files! In my tests (and I suspect those of many other people, even yours) I had done the following sequence of events:

  1. Clear disk and memory caches.
  2. Load the first page. (10 seconds)
  3. Load the second page. (4 seconds)

  However, the load of the second page goes much more quickly because the images are already cached on my system. So next I changed the procedure to include a second clearing of the caches between the first and second pages. Suddenly, there was no discernible difference between the two pages. Both take about 10 seconds to download and render.

  I suspect that there is no significant performance gain in the unsmudging of your pages. Those people that are seeing a 50% reduction in the rendering time for the second page very likely made the same mistake I did. Perhaps even your results of 7 seconds vs 13 seconds are the same effect -- I strongly suspect so. Those people who are getting no noticeable difference already assumed the need to clear the cache between the two pages.

  To eliminate the chance of people making this mistake, I would recommend changing the test pages to include their own private copies of any of the files they reference. That way nothing cached in the first page would be useful in rendering the second page. I strongly suspect that once this is done, nobody will see any difference between the two pages.

• 1999-03-02: Lloyd Wood <L dot Wood at surrey dot ac dot uk>: HTML 'smudging': a useful term.

  Rendering time and transfer time are intimately intertwined, even in threaded browsers.

  Consider a page whose entire content is nested in a complex table. The page cannot be rendered until the entire table loads in so that sizes can be estimated or layout can be carried out; dynamic on-the-fly rendering in parallel with transfer time is not possible, and the rendering time becomes dependent on the time taken to finish transfer.

  The exact opposite is a stream of unannotated ascii text, which appears just as it loads in over the network.

  Table-based layout is bad. To wit:

  • slashdot.org (which has no navigation metaphor to speak of to boot, and dynamic cgi serving that accentuates table slowness. Boy, this site needs a critique by someone who will then justly get lots of publicity from the Slashdot Effect).
  • mozilla.org (not anywhere as bad, but a design that is being increasingly emulated elsewhere, increasingly badly).
  • A whole host of other poor sites whose creators would think that having users waiting staring at a blank screen until the bottom of the document (that won't even be visible on-screen) has loaded in makes for cool design if they ever actually used a modem - which they obviously don't.
  The pointless (fixed-width, yet!) tables added to give a white border around the Florida Today Space Online site are a good example of the latter.

  etc.

  Table layout has replaced leaving out IMG height and width tags as the #1 HTML cause of perceived web slowdown due to rendering/transfer dependencies. They're worse than multi-load non-nested framesets and far more prevalent. Their use is encouraged because enough nested tables might just crash the other guys' browsers -- that seems to be a goal of gecko development, judging from screenshots.

  Tables suck.

• 1999-03-02: Tim Gentry <tim.gentry at sierra dot com>: You might not like the results of my test. The "before" version loaded in 2 seconds, the "after" in 7. I'm running WinNT 4 (sorry...), Netscape Communicator 4.05, on (basically) a T1 connection.

  I'll take a quick moment and say "Thanks" for all your work on TBTF. Not only is it enjoyable reading, but its technical content is reliable and very informative.

• 1999-03-02: Brian Westrich <Brian.Westrich at mcwestcorp dot com>: I retried it without cache (which incidentally I had to do with Netscape, as I couldn't figure out how to run IE without any cache, short of deleting the cache files manually). Here's the results:

  OS: WinNT4.0
  Browser: Netscape 4.5
  Link speed: 512K

  before: 4 seconds
  after: 2 seconds

  Certainly a noticeable difference.

• 1999-03-02: <pjg at connect dot com>: Link [12], 43 seconds from click to *Done*
  Link [13], 20 seconds from click to *Done*

  Win 98, IE5, shook hands at 45,333 w/56k v.90 modem.

• 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?