昨日の Twitter タイムラインは dev.to 一色でしたね。
何がきっかけでバズったのかは不明ですが、開発者の Ben Helpern さんも日本からのアクセスが急に増えたという記事を書いています。
We’re not totally certain what the sequence of events was, but dev.to has received a lot of positive attention/publicity in Japan in the last 12 hours or so. It has meant a lot of new members and a lot of new posts.
Contents
どんなサイト？
dev.to がどんなサイトかというと、日本のサイトでは qiita がもっとも近いサイトでしょうか。ソフトウェアエンジニアが技術記事を書くプラットフォームです。
なぜバズったかと言えば、その圧倒的な速度です。上述の Ben Helpern さんが web performance についてたくさんの記事を書いていることからもわかりますが、とにかくそのレスポンス速度は驚くほど高速です。
なぜ速いのか
まだ十分に記事を読みこんだりコードを分析できているわけではないのですが、気になったところを紹介します。
AMP と同じ方針
AMP 自体は使われていませんが、同じ考え方にもとづいて作っている、とのことです。
Regardless of AMP politics, the general mantra is very sound and more websites should be built in this style. This application you are reading from was built with AMP-esque constraints and I think it is wonderful for the user experience. The site loads extremely quickly, internal navigation within the site is blazingly fast, and nothing takes priority over the content.
重要な箇所を引用しました。強調をさらに加えています。一部を省略して簡単に訳せば、
AMP の考え方はとても健全で、もっと多くのウェブサイトがこの考え方にもとづいて作成されるべきだ。AMP で課せられているような制約を加えれば、サイトのロード時間もページ内ナビゲーションも驚くほど高速になる。
といった主旨になります。
AMP 自体を使え、とは言ってないところは注意すべき点ですね。
Vanilla JS
驚きだったのは、React, Angular, Vue.js の3巨頭をはじめフロントエンドフレームワーク全盛の今、生の JavaScript で書かれていることです。
確かに記事中心のサイトなのでフロントエンドフレームワークを導入するほど複雑なインタラクションは必要としません。フレームワークの使いどころはサイトの特性にあわせて考えましょう、ということですね。
Turbolinks 相当のサイト内ナビゲーション
Turbolinks とは Rails でサイト内ナビゲーションを高速化する手法で、リンクを JavaScript でフックして ajax でリンク先を取得したあと body タグ内を置き換えることで、ブラウザの初期化コストを抑えるテクニックです。
なお、この手法は Rails が Turbolinks を導入したことで一気に普及しましたが、もともとは pjax = pushState + ajax と呼ばれていました。
dev.to では独自の実装を使っているとのことです。Turbolinks は body をまるごと差し替えますが、dev.to も多くのサイト同様にナビゲーションやフッターなどは共通なので、コンテンツ部分だけを差し替える工夫をしているようです。
So we only inline styles on requests that are not triggered by internal navigation. To take it a step further, we also stopped sending over the nav bar or the footer.
加えて AMP スタイルの制約で重要な inline CSS も初回表示のみに必要なだけで、それ以降では不要になるので除かれています。
これも記事を中心としたサイトだからこその設計判断だと思いますが、SPA を頑張って SSR 対応させるよりは健全で素直な考え方だと思います。SSR の使い方についても考えさせられますね。
Progressive Web Apps
dev.to は PWA として実装されています。
Android で見ているかぎりネイティブアプリと遜色なく初期化も含めて最速クラスです。
ですが、面白いのはむしろ PC で見たときで、リンクにマウスオーバーした途端 ServiceWorker が裏でリンク先を fetch しています。サイト内ナビゲーションの高速化に一番貢献しているのではないでしょうか。
タップで予告なく遷移するスマートフォンではどのような工夫がされているかは気になるところです。記事リストはカード型でビューポート内に表示される数はせいぜい 3～4 個なので、表示されているカードの記事を裏で取得というのはできそうですね。
CDN に Fastly
ネットワーク環境が充実していて国土もそう広くない日本国内に閉じたサービスであれば CDN はあまり気にする必要はないと考えています。AWS をはじめとするクラウドサービスの日本リージョンを使っていれば、パケットの往復に 50 msec 以上かかることは稀でしょう。
CDN を使う上ではキャッシュが重要になりますが、パーソナライズされたコンテンツのキャッシュは Edge Computing が強力な Fastly でも難しいようで、クライアントサイドでのパーソナライズデータ保存を計画しているそうです。
A lot of this data is, itself, cached, but its cache keys are based on the specific user session, so we could not return this from the edge as of now. We plan to store more of this data on the client as well so we do not have to fetch from the source as often, but that is not implemented as of yet.
Web UX で最重要なのは速度
いろいろ調べてみた結果、そのテクニックはいずれもとても参考になるものでした。
ですが、やはり一番印象に残ったのは Web UX における速度の重要性です。その引用で本記事を締めたいと思います。
From the beginning, the idea was that if we could make everything insanely fast, every other UX consideration was going to be a lot easier going forward. Performance of a webpage is the most important UX consideration for me. Nobody wants to spend their time staring at a blank screen.
すべてを正気とは思えないほどに速くできれば、他のUX の問題はいずれもとても簡単になる、と最初から考えていました。速度こそが Web UX における一番重要な私の関心事です。
