今回は、Webブラウザ開発者の観点でWebサイトの良し悪しについて考えてみたい。

開発者というわけではなく、一般的なユーザーの視点からすると、読み込みに時間がかかるようなWebサイトが悪いサイトとしてまずは想起されるだろう。対照的に、良いサイト=軽いサイトということになる。サイトの軽さは、サイトの作り以前に、リモートのサーバーのインフラや、個々のユーザーの回線状況に依存するため、この場合の「Webサイト」は、サーバー内に格納され、要求に応じて送信されるデータセットに留まらない、広い概念である。

サーバーやネットワークのようなインフラの概念が無いユーザーにとっては、Webブラウザの枠(クローム)に包まれたコンテンツはほぼ一枚岩の均質な空間であり、ブラックボックスですらある。ただしその場合でも、Webサイトやネットワークにまつわる何もかもをひっくるめた「ネット」とは別に、自分の手元にある「Webブラウザ」というものの存在はユーザーに認識されている(WebブラウザをOSの不可分一体な部分として捉えさせるというMicrosoftの意図が暗黙裡に実現されている場合、もしくはWebブラウザがOSを取り込んだChrome OSの場合は別として)。それでもやはり、どこからどこまでがWebブラウザの仕事なのか、一般ユーザーには容易に判別がつかないだろう。

1990年代の終わりにInternet ExplorerのレンダリングエンジンTridentが他に先駆けて実装したテクニックであるincremental reflowは、送信されてきたWebサイトのデータを手元にある分の範囲で順次レンダリングしていき、ユーザーが体感する表示遅延を軽減するというものだが、この手法が一般的になった今日ではincremental reflowがWebブラウザで動作していることを明示的に意識する者はほとんどいないのではないか。それは、近年WebKitに実装されたDNSプリフェッチングの場合も同様である。

つまり、視覚上・操作上把握できるGUIとしてのクロームを除いたコンテンツ部分でユーザーがストレスを感じた場合、その責任の帰属先として「ネット」「Webブラウザ」「OS」「パソコン」のどの要素の調子が悪いと考えるかはユーザーによってまちまちであり、一定しない。この状況をブラウザ開発者から見ると、いわれのない非難を受けるのは極力避けたいというわけなので、読み込みが遅いサイトは当然ながら悪である。

もちろん、Webサイトを構成するファイル群の内容のみに起因して「悪い」サイトとなる場合もある。既存レンダリングエンジンを用いてブラウザを開発する者から見て最も悩ましいのは、ユーザーエージェント文字列に特定の語が入っていない場合に正常に機能しないWebサイトだ。例えば、Geckoエンジンで開いた場合に、"Firefox"がユーザーエージェント文字列に含まれていないと正しく動作せず、しかもそのことを告知しないWebサイトが、実際に存在している。Lunascapeではこの問題に対してGeckoエンジン利用時は"Firefox"をユーザーエージェント文字列に含めることでこれに対処している。ただしこのような問題の影響自体は、既存レンダリングエンジンを利用する場合に限定されていない。Internet Explorerが"Mozilla"をユーザーエージェント文字列に含むのも、同様の経緯であったと推察される。

ここまで悪いサイトの特徴を主に見てきたが、Webブラウザ開発者から見た「良いサイト」の積極的な定義を考えようとすると、これは難しい。一般的なWebサイトを閲覧するだけでは発見できない重要な問題について警鐘を鳴らすテストケースとして機能しやすいという点では、何らかの問題を含んだ際どい作りのWebサイトの方が興味深いといえるからだ。その意味では、上記の、特定文字列がユーザーエージェント文字列に入っていないと機能しないWebサイトも、逆説的ながら良いサイトとして捉えることも可能である。もっと洗練された事例としては、Googleの一連のサービスのようにJavaScriptを駆使した複雑なWebアプリケーションも、Webブラウザに様々な面からストレスを与えるため、問題の発見に役立つ。

このようにひねくれた見方でなく、素直に、Webブラウザのユーザーに負担をかけないサイトが良いサイトである、と定義すれば話は別だ。Webサイトを作ったら、まずはW3Cのバリデータで文法をチェックし、次に、できるだけ多くの種類やバージョンのWebブラウザでテストする。テストと、そこで発見された問題の対応とに割けるコストとの相談になるが、たとえばLunascapeの3つのエンジンでページを開いてみるだけでもほとんどの問題の端緒はつかめるだろう。