デザイナーとWebサイトの高速化 前編 高速化の知識の重要性

普段意識されることが少ないのですが、Webサイトの高速化を考えるとき、デザイナーだからこそできる作業があります。まず、なぜデザイナーが高速化を考える必要があるかを考えてみましょう。

発行

著者 小原 司 UIデザイナー
デザイナーとWebサイトの高速化 シリーズの記事一覧

はじめに

この記事はWebデザイナー向けに書かれたものです。Webサイトの高速化というと、デザイナーとは関わりの薄い分野だと思う人もいるかもしれませんが、筆者は「デザイナーにしかできない高速化」という作業があると考えています。一般的にWebサイトやWebアプリケーションの高速化といえば、フロントエンドやサーバーサイド、ネットワークなどに関わる人たちが得意とする分野です。それは間違いありません。

しかし、フロントエンドの高速化の中には、デザインが確定してしまったあとからではできないものもあります。そして、デザイナーだからこそサイトの高速化に注目するべき理由があります。Webサイトの高速化というものはエンジニアのみで行うものではなく、それは、デザイナーも含めて取り組むべき課題なのです。このシリーズでは、デザイナーが高速化の手法を知ることの重要性や、その勘所を知ることによって、サイトをより良くしたいデザイナーとエンジニアとの協業が、より円滑で前向きにできるようになることを目指しています。

なぜ、デザイナーに高速化の知識が必要なのか?

デザインは、表示要素とユーザーを繋ぐもの

デザインというものは、ユーザーが感じるサイトやアプリケーションへの印象の多くを左右します。それは、デザインがブラウザに表示される要素とユーザーとの最終的な繋ぎ手となるからです。どんなに内容が良くても、相手を間違ってデザインをしてしまえば、その人は「自分には関係のないサイトだ」と受け取るでしょうし、場違いに機能を並べすぎてしまうと「これは難しすぎる」と敬遠してしまうかもしれません。逆に、そのときユーザーが求めているものに近ければ好印象を持たれますし、使いやすく感じられれば、このまま繰り返し使おうと思ってもらえるかもしれません。

当たり前のことですが、どんなタイプのデザインでも、それが相手に見える状態でなければ効果を発揮することはできません(聴覚を利用した内容であれば音声が聞こえる状態)。内容が見えるようになって初めてデザインがスタートします。それがブラウザであれば読み込みが完了して画面構築が完了し、画面が表示されて初めてデザインがスタートラインに立ちます。

媒体によって待たされる時間が異なる

筆者はWeb関連の仕事をする前は、紙媒体でのデザイン制作に10年以上関わっていました。当時はデザインを提供するための一連の動作として、ユーザーが「見よう」と思ってから目に入るまでの時間について考えたことは一度もありませんでした。媒体としての仕組みがまったく違うので比べるのはナンセンスかもしれませんが、紙媒体の雑誌などではページをめくれば、瞬時に内容を読み始めることができるのは言うまでもありません。

一方、Webはというと、ページ遷移をしてから内容を読み始めるまでには若干のタイムラグが存在します。ページを構成する要素の読み込み待ちと、読み込まれたファイル群をブラウザが画面に構築するまでの時間です。Web上にある広告などのリンクから遷移してサイトを表示する場合も同様で、読み込み待ちと画面構築が発生します。見ようと思ってから実際に見られるまでに待機しなければならない時間が存在するということです。

先に進みたいのに待たされるというのは、ストレスを感じやすい行為です。マイナス印象です。デザイナーとしては、いち早くデザインされた内容をユーザーに見てもらいたいのに、待機時間があるせいで画面が表示される前からマイナス印象となってしまうのは問題です。そして、残念なことにデザイナーが丹精を込めて仕上げたデザインが原因となって、画面表示までの待機時間をより長くしている場合があります。デザイナーはデザインを良くすることで、サイトやアプリケーション、対象としている商品の印象を良くするように努力をしているはずなのに、その努力が逆効果となってしまうのでは本末転倒になってしまいます。

デザイナーがブラウザの仕組みと高速化の勘所を知ることで、いままで発生していた待機時間を短縮させることが可能になります。そうすることで、サイト全体としての評価を向上させることができるのですから、デザイナーとしてはとても意義のある分野なのではないでしょうか。

どのような待ち時間にマイナスを感じるのか?

待ち時間の感じ方の違い

Webの待ち時間はそれほど長くないのでは? と思われる方もいるかもしれません。確かにWebにおける読み込み待ちの時間は数秒から十秒程度で、1時間待ちなどではありません。しかし、待ち時間の性質を観察してみると、Webにおける短い待ち時間の積み重ねが、ユーザーの時間を無駄に消費してしまっていることがあります。

実は筆者は待つのが得意なほうです。たとえば、友達が待ち合わせの時間に遅れてきてもまったく気にしません。どれくらい大丈夫かというと2時間ぐらい待っても平気です。毎回ではさすがに困ると思いますが、たまにであれば大丈夫です。もちろんその間微動だにせずに直立の姿勢をキープしているわけではありませんが、カフェに入って読書をしたりiPhoneからインターネット上の記事を読んだり、最近ではKindleという時間つぶしに最適なツールもあります。何かしら違うことをして時間をなるべく有効に使うことができていれば、待ち時間にはそれほどストレスは感じません。

一方で、わりと待てるタイプの私でも、なるべく待ちたくない場合があります。それはスーパーなどのレジ待ちです。混雑しているスーパーなどで買い物をするときは、最短の時間でレジに到達できそうな列を、脳みそをフル回転させて選びだそうとします。待つのが苦手ではないはずなのにレジ待ちは極力したくありません。何が違うのでしょうか?

レジ待ちの列は、さっさと精算を済ませて次のことをやりたいのだけれども、順番は守らなければなません。さらに、ただ漫然と待っていればよいかというとそうでもありません。前の人が進めば自分も少しだけ前に進む必要があり、合間合間で気を配る必要があります。このように、必ず待つ必要があるのだけれど、その中にも小さな判断を頭でしなければならないタイミングが小刻みにやってくる場合というのは、ある程度まとまった待機時間に比べると、何か別のことに集中して時間を有効に使うことが難しくなります。あまり褒められたことではありませんが、レジ担当の人が研修中の名札をして、なれない手つきで品物を手に取ったり、先の人が支払いにとても手間取っていたりすると、待ち時間が伸びてしまうので「あぁ〜」という気持ちが湧いてきてしまいます。

サイトやアプリケーションの待ち時間

サイトやアプリケーションにおける表示待ち時間の場合はどうでしょうか。スーパーのレジ待ちの列に並ぶのと同じ性質を持っていると筆者は感じます。さっさと読み込みを済ませて目的の画面にたどり着きたいのだけれど、データの読み込みは必ずしなければなりません。そして、その間ただ待っていれば欲している情報にたどり着けるかといえばそうはいきません。たとえば、自身が求める情報にたどり着くためには、メニューから該当する項目を探してクリックするなど、何かしらの判断を繰り返し行う必要があります。そして遷移を繰り返すということは、そのたびに読み込み待ちの「細切れな待ち時間」が発生するということです。

加えて、サイトでの待ち時間となると、レジ打ちのように対人で何かをするわけではありません。無機物に対する負の感情はとてもストレートにでやすいものです。そうなると、待ち時間を作り出しているサイトへの評価がマイナスされます。

このように「細切れな待ち時間」というのは、時間が短いがゆえに、何かほかのことに置き換えることができません。そして、それはある程度まとまった時間とは別ものです。小刻みに待つということは、待つことしかできないので待機している側からすると小さなイライラを積み重ねる作業になります。そして、繰り返しになりますが、この状態はサイト全体の評価を下げてしまうことにつながります。

デザイナーにしかできない高速化とは?

それでは、デザイナーにしかできない高速化とは、どんなことでしょうか? 具体的な技術については次回に解説しますが、デザイナーにしかできない高速化というはデザインとパフォーマンスのバランスを調整するということです。

一生懸命頑張って作成したデザインが、サイトが遅いからという理由で離脱されてしまったり、離脱しないまでも悪い印象を持たれてしまっては残念です。しかし、逆に高速に動作することを意識しすぎたせいで、必要な画像やインフォメーション、それにデザイン的要素が抜け落ちてしまい、ユーザーがそもそもの目的を果たせなくなってしまっても意味がありません。

そこで、デザイナーがパフォーマンスについての勘所を押さえることができるようになれば、「ここまでやってしまうと、サイトが重くなりそうだ」という感覚や「ここは画像を使わずに、CSSで表現できる範囲で雰囲気がでるようにしてみよう」などといった調整が可能になります。また、エンジニアとチームを組んで開発に関わっているならば、部分的に豪華にデザインしたい箇所などで、全体のパフォーマンスをなるべく落とさずに、より良いデザインにする方法があるか事前に相談することも可能になります。

CodeGridの記事では何度も紹介されている株式会社ピクセルグリッド コーポレートサイトですが、このサイトも高速に動作することを意識してデザインとパフォーマンスのバランス調整をしながら作成されたサイトです。サイト内で遷移をすると、高速に内容が切り替わることが確認できると思います。このような速度感にできているのは、ネットワーク部分も含めてエンジニアが総合的にパフォーマンスを意識しているからではありますが、デザイン段階から高速に動作することを意識しなければ、無駄な要素や装飾が増えることとなり、サイトのパフォーマンスを低下させる原因を作り出していたかと思います。

まとめ

ここまでは、デザイナーにパフォーマンスに対する知識が必要な理由と、デザイナーにしかできない高速化について解説しました。次回は、デザイナーがデザインをする上で知っておきたい高速化のポイントを、ブラウザの仕組みと合わせて紹介します。

小原 司
PixelGrid Inc.
UIデザイナー

紙媒体をメインに制作しているデザイン事務所で広告デザインの基礎を学ぶ。2000年に独立。化粧品関連媒体の販促物を中心に、店頭グラフィック、パッケージ、POP、グッズ立案など多岐にわたるデザインを担当。2007年頃からWeb媒体へのデザインにも積極的に取り組み、クロスプラットフォームアプリのデザイン、画面設計、実装に携わる。2013年にピクセルグリッドに入社。現在では利用者にストレスを与えず迷わないユーザーインターフェースの設計とデザインに励んでいる。 著書に『ノンデザイナーズ・デザインブック[第4版]』(日本語版補足解説:マイナビ出版、2016年6月30日)などがある。また、マンセル色相環とムーン&スペンサー配色理論を採用した配色アプリ『HUE360』を1人でデザインから開発まで行い公開している。

Xにポストする Blueskyにポストする この記事の内容についての意見・感想を送る

全記事アクセス+月4回配信、月額880円(税込)

CodeGridを購読する

初めてお申し込みの方には、30日間無料でお使いいただけます