パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

モバイル版Webサイトの完成度はなぜ低い?」記事へのコメント

  • 日本のスマートフォンサイトをこの3年ほど計測してデータを見てきました。
    以下に、現状の問題点をまとめてみました。

    ・コンテンツを盛り込み過ぎ

    かなりの割合で、1ページ1MBを超えるスマートフォンサイトがあります。
    スマートフォンサイトを見るのは、大抵が、日常の細切れ時間、5~10分の範疇です。
    あれこれ、コンテンツを盛り込んでも、見てはもらえません。
    PCサイトで出来ることを全てスマートフォンサイトに盛り込むのは止めた方が良いと思います。
    スマートフォンで閲覧する目的やスマートフォンから利用されるページ・機能をよく調査して絞り込む必要があります。
    1MBも容量がある場合、1時間に1回の間隔で一ヶ月定点観測したデータから見ると、95%の確率でダウンロードに22~96秒かかります。

    ・携帯網のスピードを盲信し過ぎ

    どんなにTVコマーシャルで、「繋がりやすさNo.1」とか、あれこれ各社が宣伝していたとしても、携帯網の仕組みから来る限界というのがあります。例えば、人口密集地の基地局は、200~300mの範囲をカバーし、更に過密な地域では、最近では更に電波を弱くして20~30mの範囲をカバーして基地局を増やすことで、繋がりやすくしています。基地局の設置の仕方は、きちんと専用のシミュレーションソフトを使って配置しているキャリアもあれば、単純にコンパスで地図上に円を描いて設置しているキャリアもあります。
    一つの基地局あたり、大体100人ぐらい繋がります。問題は、100人以上が一つの基地局にアクセスした場合です。
    その場合は、ユーザの通信の公平性を担保するために、時分割で通信時間が割り当てられ、自分が通信できない間はパケットがドロップします。
    電波が繋がるということと、通信できるという事は同義ではないです。
    3G回線の場合、大体1ページあたり100KBを超えると、パケットドロップに巻き込まれやすいのがデータからわかっています。
    5秒以内にページを表示したいなら、100KB以内に1ページのサイズを抑えるべきです。
    そうすれば、自ずと、コンテンツの絞込もしなければならないでしょう。
    RBB TODAY SPEED TESTを、3GやLTEのスピードテストで使って、マーケティングデータとして発表している所が多いですが、スマートフォンサイトの場合は、TCP/IP 3Way Handshakeや、TCP Slow Startなどのオーバーヘッドの影響がありますし、HTML、CSS、JavaScript、画像のファイルサイズも小さく、Keep-aliveを設定していないサイトも多いため、スマートフォンサイトの配信における実際のスループットはかなり低いです。20~100KB/秒ぐらいしか出ません。

    ・サードパーティーコンテンツを盛り込み過ぎ

    自社ドメイン以外のコンテンツをサードパーティーコンテンツと呼びますが、それを盛り込み過ぎです。
    遅延の要因で多いのは、
    ・Facebookのいいねボタン
    ・TwitterのTweetボタン
    ・広告配信
    ・Google Analyticsなどの解析ツール
    などです。
    夜9~12時の時間帯は、30~60秒以上かかってダウンロードされることが多いです。
    もちろん、Google Analyticsのデータは、「偏って」います。ダウンロードに成功した、もしくは素早くダウンロードできた場合しかデータが取得できていないからです。

    ・タグマネージャは有効ではない

    こういったサードパーティーのタグをまとめて配信してくれるサービス、タグマネージャを利用しているサイトもありますが、タグマネージャ自体が配信が遅いので、有効ではありません。

    ・レスポンシブデザインは有効ではない

    レスポンシブデザインが流行っていますが、レスポンシブデザインにしているサイトは容量が大きいため遅いです。
    尚且つ、レスポンシブデザインは管理すべき事項がどんどん多くなってしまうので、サイトの規模が大きくなるほど破綻しやすいです。

    ・スマートフォンコンバーターの処理の遅延

    PCサイトをスマートフォン向けに作り変えるサービスを使っているところが多いですが、殆どがサービス事業者側の処理遅延によって、非常に遅い配信になっています。

    ・CDNは有効ではない

    スマートフォンサイトの場合、基地局から携帯網のネットワークを通り、ゲートウェイからインターネットに出るまで約10ホップぐらい余分にかかります。携帯網のネットワークの中にキャッシュサーバーを置いている事業者はほぼ皆無なので、CDNは高速化には効かないです。

    ・FEO(Front End Optimization)も有効ではない

    ページサイズや、CSS、JavaScriptなどを最適化してくれるFEOサービスを使っているサイトがありますが、確かに軽量化してはくれますが、そのための処理のオーバーヘッドとネットワークのラウンドトリップの方が大きく、効果が認められません。

    ・Ajaxは携帯網では遅延する

    スマートフォンサイトでAjaxを使うと致命傷です。携帯網のレイテンシはLTEで35~45ms、3Gで100msです。
    日本での有線回線では、大抵5~15msぐらいですから、レスポンス面でかなり遅いというのがわかると思います。
    尚且つ、パケットドロップもあります。Ajaxでデータを取得しようとして、Request Timeoutになる確率がかなり高いです。

    ・DNSのTTLを短くし過ぎ

    DNSのTTLを5~15分に設定しているサイトが多いです。そういう所に、TTLが短い理由を訊くと、サイトの内容を素早く切り替えるためとか、障害対策のためとかおっしゃるのですが、通常のデスクトップ向けのWebサイトは、ユーザが使っているISPや会社などのDNSを名前解決に利用するため、DNS Lookupのトラフィックが分散されますが、携帯網の場合は、NTT DoCoMo、KDDI、SoftBankの3社のDNSに集約されます。
    大規模アクセスのあるサイトがTTLを5分に設定すると、一気に数百万台のスマートフォンが携帯会社のDNSに対して名前解決に来るため、一気に負荷が上がります。昨年末ぐらいから、DNSの名前解決の遅延によるスマートフォンサイトの表示の遅延現象が発生しています。
    BINDで、ホスト単位とか、サブドメイン単位でTTLが設定できるので、スマートフォンサイトの配信サーバについてのTTLは長めに設定すべきです。

    以上をまとめると、Webサイトというのは「美術」ではなく、「機能」を提供するものなので、もっとシンプルに、まるでボクサーがギリギリまで減量するように、スマートフォンでアクセスする際に必要な「表示」と「機能」のみに絞り込むべきです。
    あと、フロントエンドの部分だけを学ぶのではなく、携帯網の仕組みそのものを勉強されてから、スマートフォンサイトを作った方が良いのではないかと思います。

    • by Anonymous Coward

      レスポンシブってレイアウトを放棄したゴミみたいなクソデザインだと常々感じていましたが、やはりデメリットの方が目立ちますね。
      Web2.0とかと同じバズワードで、無知なクライアントをほどよく騙して儲けるテクニックなのだなぁと思っていました。
      得意そうに提案してくるデザイナーのデザイン力のなさといったらもう…。

      • レスポンシブを携帯網経由のブラウザに見せるのはどうかという本題はおいといて、

        PCwith光回線において、レスポンシブデザインは有効だと思う

        せっかく柔軟な表示ができるのがHTMLのいいところだとおもうのに
        固定幅でセンタリングされたり、左寄せされたサイトをみると
        なんか、もったいない感じがするのですよ
        だいたいがPCのブラウザが特定幅で表示していない(ユーザによって幅が違う)のに
        呼応するための技術ですし…

        あと
        レスポンシブか否かと
        デザイナーのデザイン力に相関性はないと思う
        まぁ、デザイン力とレスポンシブでクロス分類すると
        偏りがあることは否定しない…

        --
        〜〜 姫 〜〜
        親コメント
      • by Anonymous Coward

        以前あるWeb記事にフェラーリーのデザインをしたことのある車デザイナーがデザインとアートは違うと言うことを書いていました。
        デザインには機能も含まれるというような趣旨で、アートはあくまでその個人の自己表現の手段であるようなことを。
        個人的にはアートしかできない人をデザイナーと呼ぶのは、製品設計時にとても迷惑でした。
        アートとデザインは違うと言うことをもう少し経営者が理解して判断してくれると会社の評価に良い影響があると思うのですがね。

        • by Anonymous Coward on 2013年12月29日 11時37分 (#2519977)

          フェラーリはずっとながいことフェラーリがエンジン付きシャシー制作→ピニンファリーナやベルトーネのような
          カロッツェリアにデザイン依頼→スカリエッティでボディ制作の分業制でまず機械部分が決まってからそれを
          覆うボディがデザインされるという流れだった。
          技術があるメーカーだと先にデザインしてから機械部分を載せることもできるけど、そのせいで整備性や
          居住性が劣悪になったりすることもあるし。

          他のコメントにあるAmazonと楽天もAmazonがデータを用意してから見せ方を考える“データファースト”な
          設計に見えるのに対し、楽天はデザインをきめてからデータをはめ込む“デザインファースト”で作ってるように
          見える。
          実際の内部構造は知らないけどね。
          プログラマが好むのはAmazonじゃないかなあ?

          フェラーリもデイトナは元々のシャシーはもっと幅が狭くてデザイナーの提案に合わせてシャシーの側を
          設計変更したし、水平対向ミッドシップレイアウトはピニンファリーナ側からフェラーリへ提案したとか。
          そういう柔軟さも大事だね。

          親コメント
    • by Anonymous Coward

      その数々の問題点は他の国・文化圏では有り得ないものなのか、というのは気になる。

      • パフォーマンスの平均値、ファイル容量、オブジェクト数のデータは公開しているので、こちらをどうぞ。
        私は、日本担当なので、他の地域はよく知りません。しかし、ACMの記事とか、Website Magazineの記事などを読んでいると、扱っている問題は日本と同じなので、似たようなものらしいです。

        アメリカ リテールモバイルサイト
        www.keynote.com/keynote_competitive_research/performance_indices/mobile/retail/index.html

        アメリカ ニュース&ポータルモバイルサイト
        www.keynote.com/keynote_competitive_research/performance_indices/mobile/news/index.html

        アメリカ ファイナンスサービスモバイルサイト
        www.keynote.com/keynote_competitive_research/performance_indices/mobile/financial_services/index.html

        アメリカ スタートアップ企業3スクリーン(PC、タブレット、スマートフォン)
        www.keynote.com/keynote_competitive_research/performance_indices/startup/index.html

        親コメント

開いた括弧は必ず閉じる -- あるプログラマー

処理中...