Web制作ベストプラクティスは、宝箱かミミックか
Web制作には様々な「ベストプラクティス」が存在し、Web記事はもちろんのこと、書籍であったり、場合によってはカンファレンス登壇で語られたりします。しかしながら、ベストプラクティスは玉石混交であることが多く、「お、宝箱だ」と思って蓋を開けたらミミックだった的なことも少なくありません。
そして、検証しない場合、ミミックだったにも関わらずプロダクトに持ち込んでしまうことがあるので、ベストプラクティスの検証は慎重に行う必要があります。本稿では、フェイク事例を紹介したあと、ベストプラクティスとの付き合い方について考えます。
１．昔はそうだった
当時は検証済みプラクティスだったものの、時間、仕様、技術の進化とともに効果がない、もしくは逆効果になってしまうプラクティスが最もフェイクとしては多いような気がしています。
例えば、以前、SEOで最もありふれたテクニックとして「被リンクを買う」がありました。
Googleでは被リンク数の増加は、順位に最も大きく影響しています。良質なホームページにリンクしてもらうためにお金を払うのはSEOの基本です。
今だと冗談のような内容ですが、多くの業者が実践し「基本中の基本」であった時代もあります。なお、今ではGoogleのスパム対策が進化し、このようなWebサイトは順位を落とす、場合によってはGoogle検索に表示されなくなっています。けれど、現代でも！令和に入っても！！被リンク購入で成功経験がある会社は「被リンクをやめたら順位が落ちる」といって継続的に購入を続けています。
「なんと！たからばこはミミックだった！」
HTMLの仕様も年々変わっています。
例えば、HTML5では、dl要素直下にはdt要素もしくはdd要素のみを書くことができましたが、HTML5.2からはdiv要素も新たに記述することができるようになりました。なのに「div要素を書いてはいけない」というプラクティスを守り続けている制作会社の話を聞いたことがあります。
開発中に<a href="#">とダミーリンクをつけるのは、HTML5以前はa要素にはhref属性が必須とされていたためですが、今ではa要素のみで利用することが可能です。b要素やsmall要素は継続して使える一方で、center要素などは廃止されました。数年前の「HTMLはこう書くべき」ベストプラクティスはまだ使えるか検討が必要です。
このようにベストプラクティスは時代とともに変わっていっています。
２．仕様上は正しい
一番ややこしいのはこれではないでしょうか。特にHTTP/2は「HTTPヘッダーを圧縮」「接続を多重化」といった仕様により、HTTP/1のボトルネックを解消し、Web全体の高速化が期待されました。しかしながら、現実は計算量が増えることによって計算量が増え、オーバーヘッドコストの増加により高速化しませんでした。
個人的にHTTP/2には期待をよせてて、リクエストでは同一速度でもServer Pushによる最適化で速くできれば！とか思ってそれをシンプルに書くためのCLIを作ったりしたのですが、計測したところ残念ながらむしろ遅くなっていたために利用を断念しました。残念・・・。
Minifyはファイルサイズが高速化されるから速くなるはず！も「実サイズの比較をしたところ数キロバイトしか違わずに計測結果には現れない」とか、個人的な感想ではWebパフォーマンスあたりに仕様上の期待と計測が一致しないことが多いように感じます。
「なんと！たからばこは空だった！」
けれど以外にそこに労力使ってしまうんですよね・・・。
３．コンテキストの違い
ちょっと実例をだしにくいので、仮に以下のようなベストプラクティスがあったとします。
フォントサイズを少し下げて一画面に入る文字を増やしたところコンバージョン率があがった
これは10代が利用するアプリで実際に成功してたとして、この事例を高齢者のアプリUIに持ち込んで成功すると思いますか？
このように特定のコンテキストの上に成立するベストプラクティスも少なくなく、情報に接した時に共通のコンテキストを持つかの検討は重要です。
「なんと！たからばこは・・・？」
ベストプラクティスとの付き合い方
ベストプラクティスとの付き合い方は以下のツイートが参考になると思っています。
いい加減な健康本が正しい健康本よりも普及しがちな一因として、後者は「○○を控えましょう」「バランスよく○○しましょう」みたいな形式なのに対して前者はとにかく「○○しなさい」みたいに単純なアクションを呼びかけてるから実行しやすいのではないかという仮説を得た。
— 西内啓 Hiromu Nishiuchi (@philomyu) September 4, 2019
プラクティスは
１．仕様上正しい
２．計測上正しい
のどちらかで検証可能なので「見出しの後に見出しはだめ」（※嘘です）みたいなマイルールはMDNのリファレンスで検証可能ですし、「速くなる」はBefore/Afterで検証することが重要になるかと思っています。
一時期、画像のLazy Loadingにより表示が速くなる！といいすべての画像を遅延読み込みすることが流行ったことがありますが、HTMLのparse完了直後に画像をリクエストするのと、Document.readyになってオンスクリーンであることを判定してから画像をリクエストするのと、どちらが速いかは自明です。
情報発信元は「読み込まない可能性の高いオフスクリーンにある画像は遅延読み込みにしよう」というプラクティスだったのかと思いますが、伝言ゲームの中でねじまがったのではないでしょうか。
このようなことも少なくはないので、個人的にはベストプラクティスは警戒して付き合うぐらいがちょうどいいと思っていて、ぜひ手にかける前「この宝箱にはアイテムがあるか、ミミックか、それとも落とし穴か」を考えてみてください。
宣伝
Web技術でストアから配信するモバイルアプリをつくるための書籍を11月末に出版します。プロダクト開発をはじめてみる、もしくは収益を受託から自社サービスに転換してみるきっかけになりましたら幸いです！
それでは、また。
この記事が気に入ったらサポートをしてみませんか？