デジタルの世界では、スピードがユーザー体験の通貨です。ウェブページがミリ秒で読み込まれ、動画が瞬時にストリーミングされ、アプリが応答的であることを期待します。しかし、500ページの医療報告書や複雑な建築図面のような大容量ドキュメントをオンラインで閲覧する場合、ユーザーはしばしば待たされます。
ロード中のスピナーを見つめます。「processing...」バーを待ちます。ページがブロックごとにゆっくりと描画されるのを見守ります。
その待ち時間は設計上の決定であり、物理法則ではありません。オンラインドキュメントビューア は Doconut エンジン上で動作し、閲覧中のページを最初に準備し、残りは読み進めながら処理します。
なぜレガシービューアは遅いのか
なぜ一部のビューアが遅れるのかを理解するには、その仕組みを見る必要があります。
- クライアント側に負荷が集中: 一部のビューアは PDF やファイル全体をブラウザにダウンロードさせ、JavaScript で描画しようとします。100 MB のファイルの場合、ユーザーはページ 1 が表示される前に 100 MB 全体のダウンロードを待たなければなりません。
- 非効率な変換: 他のビューアはサーバー側でドキュメント全体を画像に変換してから表示します。1,000 ページの変換には時間がかかり、最初の描画が遅れます。
スピードの秘訣:オンデマンドストリーミング
Doconut はより賢いアプローチ、ページレベルストリーミング を採用しています。
ユーザーがドキュメントを開くとき:
- 最初のページを最優先: エンジンは表示中のページを描画して送信するため、残りのファイルが処理中でもドキュメントはすぐに開きます。
- バックグラウンド処理: ユーザーがページ 1 を読んでいる間に、サーバーは静かにページ 2 と 3 を準備します。
- ベクター最適化: 重いビットマップを送る代わりに、Doconut は最適化された SVG データを送信でき、軽量でピクセル化せずにスケーラブルです。
重要なパフォーマンス指標
ビューアを評価する際は、見出しに惑わされず自分のファイルで以下を測定してください:
- Time to First Byte (TTFB): サーバーの応答速度はどれくらいか?
- Time to First Page (TTFP): ビューアの実感速度、ユーザーが実際に感じる速度は?
- スクロールの滑らかさ: 100 ページのドキュメントをジャークなく移動できるか?
- コールド vs ウォーム: ウォームランは初回処理のコストを隠します。両方をテストしてください。
同じマシン、ブラウザ、ネットワークプロファイル、ドキュメントセットで全候補を比較し、平均ではなくパーセンタイルで報告しましょう。中央値はサポートチケットを生む遅いドキュメントを隠してしまいます。
帯域幅に優しい
スピードは CPU だけでなく、ネットワークを横断するデータ量でもあります。
- モバイル: 表示中のページだけをストリーミングすれば、端末は読まないファイルをダウンロードしません。
- ベクターが有効な場面: 大きなビットマップの代わりに最適化ベクターデータを送ることで、技術図面はどんなズームでも鮮明に保たれ、ペイロードは軽くなります。
最も遅いファイルで試してみる
正直なベンチマークは、今日あなたがイライラしているファイルです。OnlineDocumentViewer.com で開き、最初のページが表示される瞬間を確認してください。
事前に知っておくべき2つの制限があります。アップロードはフォーマットごとに上限があり、PDF、PSD、TIFF、Visio、EPUB と画像は 25 MB、Excel、PowerPoint、Project は 20 MB、Word は 15 MB、CAD とメールは 10 MB、HTML、XML、テキストは 5 MB です。そのため、実際に巨大なスキャンはここでは受け付けず、遅くレンダリングされることはありません。また、閲覧後はファイルが削除されます。次の訪問者のためにキャッシュが残ることはありません。
結論
実感スピードは一つの決定から生まれます:読者が見ているページを先に準備し、残りは読んでいる間に処理すること。これが大容量ドキュメントを「読み込み中」ではなく「開かれた」状態に感じさせる要因です。
上記の制限を超えるファイルや、社内ネットワーク内だけで使用するドキュメントについては、同じエンジンが Doconut SDK としてライセンス提供されており、社内ハードウェア上で実行できます。その場合、受け入れる最大ファイルサイズに合わせてマシンを構成してください。
