241
116

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

海外のガチHTMLコーダーに阿部寛のホームページを見てもらった

Last updated at Posted at 2022-04-20

(2022/4/28) フォローアップ記事となる、ジェイソンさんの記事の翻訳版を公開いたしました。
HTML3.2のどこが「間違って」いるのか、そしてそれを見た目重視のクラスで再現するのがおかしいわけ

先日投稿した「「阿部寛のホームページ」はHTML界のシーラカンスである」の続編として、MediumのHTML関連の記事でセマンティックではないHTML・CSS(特にTailwind CSS)に対し舌鋒鋭い批判をしていらっしゃるJason Knightさんに、英語版の記事見ていただいた。しっかりコードを分析されているようで恐縮である。忌憚・忖度の無いセカンドオピニオン的知見としてご覧いただければ幸いである。

(2022/4/22) 上司から会社の名前を載せて書いているのに、表現が過激すぎるのではないかとお達しがあったため、表現をマイルドにして、原文を削除した。大変申し訳ありませんでした。

(2022/4/21) なんと、実際にジェイソンさんがそれっぽい(コンテンツのコピーができないため)ページを作成された。Lighthouseの測定でもSEO以外が100点満点、Speed Indexが1.1秒という爆速ぶりである(海外サーバなのでさすがにロード時間で本家に劣ってしまうが)。ちなみに本家はコードが古すぎたからかパフォーマンスを計れなかった。なんということでしょう! (本当は、こういうのも自分でやらなきゃなと思うんだけど、よわよわデベロッパーだから…)

ソース一式はこちらからどうぞ。

以下ジェイソンさんのコメント

みんなが「速い」というのがどういうことか分かっていない、驚くべき例だね。framesetを使うと最初のロード時にキャッシュが空で、両方のフレームをフルのハンドシェイクでロードしなくてはならないから3回ハンドシェイクをする必要があるから遅くなるんだよね。これが単一ページとスタイルシートだと2回で済むんだ。

メニューサイドバー自体が全体のホームページメニューのマークアップよりもでかくなるし、コンテンツもそうだよね。ざっと見てこのHTMLは2.5k(B)くらいが妥当だと思うけど、3つのファイルで計7.12kになってる。

正直このサイトのシンプルさから見て、CSSも5kくらいで済むと思うんだよね。

サブページの短所として、膨れ上がって遅くなってしまっている。特にフレームのオーバーヘッドとテーブルが組み合わさっているところがね。もし単一のスタイルシートとマークアップを1/3にすれば、サブページの見た目をキャッシュできてページもさらに速くなるよ。

例えば次のコードを短くしてみよう。

<table border="0" width="142">
  <tr> 
    <td width="15"> </td>
    <td width="10"> </td>
    <td width="148"> </td>
  </tr>
  <tr> 
    <td width="15"> </td>
    <td width="10"><font color="#FFCCCC">?</font></td>
    <td width="148"> 
      <p><a href="top.htm" target="right">???</a></p>
    </td>
  </tr>
<nav id="mainMenu">
  <ul>
    <li><a href="./">Top</a></li>

もうこれで速くなるのは火を見るより明らかだよね。このページが早い唯一の理由は内容が軽量だからだ。それに見合う帯域幅の倍を食っているし、50%は余計なハンドシェイクとサーバーリクエストを要求しちゃってる。

まだユーザビリティとアクセシビリティに対してNOと言っていることは話してなかったよね。

これの代替品を作る記事も書いてみていいかもな。表示中心のマークアップの悪い点を凝縮したようなものだから。「コピーは禁じます」とページにあるから偽のコンテントを作らなきゃならないけど、頑張って順守してみる…可能な限り。

ブラウザサポートに関してはやらない理由が無い。絵的なユーザーエージェント、つまりブラウザはマークアップを気にする必要が無く、ブロック化インラインレベルのタグかどうかだけが重要だ。機能を維持するのはコードや処理のオーバヘッドにとって大きな問題じゃない。だって386を積んだWindows3.1でも動いたわけだし。

でもレガシー機能は新しいdoctypeを書いたらブロックすべきだと思う。だからWHATWGがバージョン表記をやめて「現行ドキュメント」という方式をとったのは残念な判断だ。

2年前に「HTML5」で書いた正しいコードが今不正かもしれないのに、HTML5の「バージョン」が分からない中で今日正しいのが明日だめになってしまうかもしれない? 冗談きついよ。

ユーザーエージェントが「ダメ」と言って、開発者に修正してもらえるように止まるのじゃなくて「検証サービス」が必要なのが馬鹿げているようなものだ。この「問題が無いかのように馬鹿正直な」パーサー動作はひどいと言わざるを得ない。

でもそんな動作になったら80%以上のWebページが壊れてしまうのも確かだ。フレームワークや出来合いのブログプラグインが<body>内に<style>を入れたりしたらうまくいかなくなるしね。

241
116
3

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
241
116

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?