The static image web-site

A "broken document", similar to what web browsers show if a downloaded image is corrupted.

A few years ago, I stumbled on a web site which was just one static image. The web site was for a small ramen restaurant in Zürich, and the image was just a simple poster with the basic information: address, opening hours, phone number.

If you look at it academically, this is the worst type of web-site, it completely sidesteps the idea of the web, breaks accessibility, web-site indexing and makes things like copy-pasting information impossible. Still, given the state of the web, this might be a reasonable approach to web-design for the following reasons:

  • It is fast – a PNG image of text will compress very well, and the total amount of data will be way less than downloading the many JavaScript frameworks needed by most sites nowadays. In fact if the PNG is interlaced, the site can already displayed when a fraction (typically half) of the data has been downloaded.
  • Better privacy – if the image is downloaded directly from the web server, no third party is involved, no cookies are set.
  • Better security – if only one static resource is loaded, the attack surface is greatly reduced.
  • Graphically stable – the web site will have the same layout regardless of installed font, web browser, etc.
  • Portable – the image will display fine on any web browser that supports PNG.
  • Sharable – the content of the web site can be saved on any device, forwarded by instant messaging without having to worry that the web-site will be turned down, blocking your particular address or anything like that.

I suppose the logical continuation of that idea would be to use a web server that can only serve static resources, maybe even link the image inside the binary, so there is just one, read-only binary running in isolation on the server.

To be clear, I don’t think this is the right approach, but given the state of the web these days, I don’t think it is that wrong either…

Blank-document-broken – Based on Tango Project’s identically licensed Edit-copy.svg
Modified outlines so the document looks like it’s ripped in half. Intended to look like a “broken document”, similar to what web browsers show if a downloaded image is corrupted. The image was cropped to have less blank space. Image licensed under the Creative Commons CC-BY-SA 2.5.

7 thoughts on “The static image web-site”

  1. Is it really a reasonable approach to design to simply exclude users who can’t see images, for whatever reason? If you want to be extreme about it, it seems more reasonable to lay out the entire thing as a plain text file, which would beat the graphic on almost all counts. (It would definitely be harder to share as a frozen element and would be more variable in appearance, of course. But it would be accessible on more devices and in more situations, not to mention easier to zoom, copy & paste sections of, etc., among other obvious benefits…)

    • No, it’s not really reasonable. My point was mostly (ironicly) that any approach will exclude someone. An accessible site might end up be bloated and too heavy to download, or less secure and less available (thus excluding other people). Sadly the text file does not beat a graphic on all counts: it’s ugly, and only works reliably for ASCII (which excludes a lot of people),

      • Okay, I think I understand what you’re saying now. Yes, a text file is uglier, no argument there. I’m not sure I follow what you’re saying about ASCII—if the file is encoded correctly and served with the right headers, is there a significant section of users who will not be able to access the content?

        • Text file will work if
          a) the web server headers are set up correctly
          b) the web browser handles that encoding
          c) the browser has the font to render the text
          d) the underlying renderer can handle that character set (many writing system require different compositing rules / features than latin text).

          a) Is difficult to fix if you cannot control the web server (rented hosting).
          b) is usually not a problem,
          c) user cannot easily install font on mobile devices.
          d) typically requires an operating system update (which might never come).

          I cannot make any statement of what proportion of the users would be hit by which issue, but I can say that I regularly encounter web-pages with encoding problems (typically pages in iso-latin or one of the Japanese encodings with missing or incorrect headers).

          • Gotcha. Thanks for explaining (and in particular for mentioning your personal experience, which is what I was most curious about). All that makes sense.

            Re: a), does meta http-equiv="Content-Type" have any effect in that situation?

            I haven’t yet come across devices that aren’t able to handle Hindi (which is practically built out of ligatures) and Urdu (which is practically built out of ligatures as well as written from right to left), the two languages I’m most familiar with other than English, even though they’re both rather Indo-centric and not well known to people outside the subcontinent. Of course, both of them are reasonably well supported in Unicode, and I’m not fluent in any languages that aren’t, so that’s why I was wondering about what the practical issues are.

        • For Indi and Urdu, how confident these will render correctly on a PlayStation 2 (the oldest device I have with a web browser)? On a cheap mobile phone sold in Eastern Europe? On a PC that still runs Windows XP? These are edge cases you can exclude, but then you are excluded some users…

          The meta http-equiv=”Content-Type” is only available for HTML, not plain text. Now I agree that some reasonable subset of HTML would probably be the solution – I’m pretty sure my home page renders pretty much everywhere – the problem is, I don’t think there is a clear idea on what that reasonable subset is, nor do I know tools available to the general public that generate documents in that subset.

          • Welp, Windows XP SP2 seems to handle Hindi and Urdu mostly fine (a few rendering quirks, but still comprehensible). I couldn’t comment on the PS2 web browser, which I can’t find information, or a cheap Eastern European mobile phone, which I don’t have. But your point is taken. Again, I wonder: is the set of visitors to your site from a PS2 or a cheap Eastern European phone larger than the set of visitors who can’t see images? I guess that’s a question each site would have to answer for itself.

            That’s right about Content-Type, sorry—I got mixed up and forgot we were only talking about plain text. I think the subset you’re talking about will be different for different sites, since, as you’ve been saying, everything excludes /someone/… this is a complicated situation indeed.

            I appreciate the discussion. I’d never considered how a text document could be less than universal.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: