Top / 体験研究 / Hidden but Loaded
インターフェースの体験 — Hidden but Loaded

PCで、見えないスマホ用の動画まで読んでいた

2026.10 Web / Weight

自分のサイトのトップを、PCで開いて読み込みを数えた。いちばん大きいファイルは、スマホ用の動画だった。PCでは一度も画面に出ない動画だ。

この研究を一言でいうと──「隠す」は見た目の話。「読まない」は別に書く。

点線のスマホの枠の中に薄く見える、PCでは画面に出ないスマホ用の絵
— PCで読んでいた量の26%が、画面に一度も出ていなかった

実験:PCで開いて、何を読んだかを数えた

トップを幅1440×高さ900、キャッシュなしで開き、自分のサイトから届いたファイルを大きい順に並べた。1位はスマホ用の動画(320KB)、5位はスマホ用の絵(180KB)だった。合わせて0.50MB。PCで読んでいた1.89MBの26%が、画面に一度も出ていなかった。

PCで読んでいた量の帯グラフ。直す前は1.89MBのうちスマホ用の動画320KBと絵180KBが含まれ、直したあとは画面に出る1.39MBだけ
— 直したあと、PCで読むのは画面に出るものだけになった。スマホは変わらない

どちらも、スマホでトップを開いたときに一面に出る絵と、その上で動く動画だ。スマホには要る。PCでは、CSSで箱ごと隠してあった。隠れているので、見ていても気づけない。

体験:見えない重さは、見える物の順番を遅らせる

PCの回線なら0.5MBは一瞬に思える。けれど、ページを開いた直後は、ブラウザが同時に取りに行ける数に限りがある。見えない動画と絵が先に並ぶと、そのぶん作品の画像が後ろに回る。見る人にとっては「なぜか遅い」としか感じられない重さになる。

画面で消したものは、見る人の目からは消える。回線からは消えていない。

デザインでは、PCとスマホで2つの絵を用意して、片方を隠す、というやり方をよく使う。デザイナーが「隠した」と思った時点で、その絵はなくなったことになる。けれど、ページを届ける側から見ると、2つとも全員に配っている。作る人の頭の中と、届ける仕組みのあいだにある、見えないずれだった。

原因:隠し方は正しかった。取りに行く方が止まっていなかった

原因の図。絵は display:none の箱でも読みに行くので picture でPCに1×1の透明画像を渡した。動画は preload none でも autoplay と play() が再生を頼んでいたので、画面幅を見てから再生にした
— 絵と動画で、止め方が違う
ものなぜ読んでいたか直し方
スマホ用の絵CSSで箱を消しても、ブラウザは img の src を見た時点で取りに行くpicture で、PCの幅には1×1の透明画像を渡す
スマホ用の動画読み込みは preload="none" で止めていた。けれど autoplay と、開いた直後の play() が再生を頼んでいたautoplay を外し、スマホの幅のときだけ play() を呼ぶ

直したあと、PCで開いて数え直すと、スマホ用の動画と絵は0になった。スマホでは、これまでどおり絵が出て、その上で動画が流れる。PCもスマホも、直す前と並べて、見た目が変わっていないことを確かめた。

決めたこと

あなたのサイトで、いちばん大きいファイルは、いま開いている画面に出ていますか。

同じページへ、読み直してから戻っていた、の研究を読む →

— 他の研究を読む
← 体験研究の一覧へ 全ての設計事例を見る →