5秒の読み込み時間は許容できない。でも、それが「普通」になっている。

プログラムを起動したり、アプリを開いたり、ウェブサイトを読み込んだりするとき、あなたはおそらく少なくとも数秒は待たされているはずだ。それが当たり前になっている。

でも、そうあるべきではない。

顧客が一度でも高速な読み込みと反応を味わってしまえば、二度と競合に移ったりしない。あなたの速いアプリと競合の遅いアプリの違いを体感すれば、遅いほうに強いストレスを感じるようになる。

この優位性をどう実現するか、現実の世界での事実、そして開発者に何を尋ねるべきか。すべてこの記事に書いた。

5秒の読み込み時間は許容できない。でも、それが「普通」になっている。

本当はどこまで速くできるのか?

これは技術記事ではないので、基本的でわかりやすい数字をいくつかざっと眺めて、それを現実の世界と比べてみよう。

安価なスマホに載っている安いCPUでも、毎秒数十億の命令を処理できる。しかもコアは少なくとも2つ(実質的に処理ユニットが2つ)ある。

最新のディスクドライブからのデータ読み込みは、毎秒数千メガバイト。これも安いスマホですらそうだ。

インターネット経由の転送は、低めに見積もっても毎秒数百メガバイト。

比較してみる

まずいちばん遅い対象から見ていこう。質の高いウェブページは、読み込み直後の状態で、大きめに見ても15〜25メガバイトくらいだ。

つまり全部を計算に入れても、開いたブラウザにリンクを入力してから、ウェブサイトが完全に表示されるまでは約1〜2秒であるべきだ。

スマホのアプリを取り上げると、これはデバイス上に保存されたファイルなので、ここにはインターネット接続(いちばん遅い速度)は関係ない。毎秒ギガバイト級の速度なら、典型的なアプリは0.15〜0.25秒で開いて動作するはずだ。

すでに開いているアプリやプログラム、ウェブサイトの中での操作は、いちばん速いCPU、ときにはGPUの速度だけを通る。ボタンをクリックしたら、文字どおり瞬時に画面へ目に見える結果が返ってくるべきなのだ。

現実の今

今の現実では、こうした速度に常に到達できるわけではない。でも想像がつくと思うが、読み込み時間が1〜2秒から5秒になる必要もまったくないし、あなたのウェブサイトだって2〜3秒で開けるはずだ。しかもそれは、まともな最適化が抜け落ちている本当に大きなウェブページの話だ。

開発者に何を尋ねるべきか?

テクノロジーやコーディングを細かく理解する必要はない。技術面接をするわけではないのだから。

スタック

まずは「あなたのスタックは何ですか?」と聞いてみよう。これは、何のツールや技術を使って、何の上に作っているのかを尋ねる質問だ。もし開発者が、使っているクールな技術を次々に語り始めたら、それは危険信号(レッドフラグ)だ。「webview」みたいなことを言うのも同じく。

なぜか。今日の遅いソフトウェアの大半は、以前に作られた何かの上に作られていて、それもまた以前に作られた別の何かの上に作られているからだ。鎖のようにつながっている。つまり、先ほど挙げた速度は依然として有効なのに、処理しなければならないのはあなたのプロジェクトではなく、何層もの積み重ねなのだ。

WordPressが遅いのは、必要のないものまで全部やってしまうからだ。

計測

2つめの質問は、どうやって速度を計測しているか、そして速度の目標値はどこに置いているか、だ。

意外なほど多くの開発者が、5秒が目標だと答える。これもまたレッドフラグだ。計測方法をきちんと答えられない場合も同じ。あるいは答えが「開いて見てます」だった場合も。

自分の目で見て肌で感じることは、テストに欠かせない部分だ。でもそれは同時に、数多くの「自分の環境では動くんですけど」問題の元凶でもある。

速度の指標を要求し始めるべきだ

プロジェクトをきちんと作るのは、手間が増える。でも、思っているほどではない。

小さなプロジェクト(1ページだけのウェブサイトなど)では、ゼロから始めるのと既存のツールを使うのとで、計測できるほどの作業量の差はない。大きなプロジェクトでは、入念な計画と、長所と短所の比較、そしていわゆるフレームワークをなぜ使うのかを理解することが必要になる。

製品仕様には、製品がどう動くべきかだけでなく、どれだけ速くあるべきかも含めるべきだ。これはとても重要な議論なのだ。

私たちの経験から言えば、技術に詳しくない人にとって、これは居心地の悪い会話だ。だからこそ私たちLINK-Vは、クライアントが理解できる言葉でこのプロセスを一緒に歩んでいく。結局のところ、ソフトウェアとは人とコンピューターのあいだの層であり、私たちがそのソフトウェアを作るなら、私たちも同じように振る舞うのだ。

Tom J. · LINK-V