디지털 세계에서는 속도가 사용자 경험의 통화와 같습니다. 우리는 웹 페이지가 밀리초 안에 로드되고, 동영상이 즉시 스트리밍되며, 앱이 반응성을 유지하기를 기대합니다. 그러나 500페이지 분량의 의료 보고서나 복잡한 건축 도면처럼 큰 문서를 온라인에서 볼 때는 사용자가 종종 기다려야 합니다.

그들은 로딩 스피너를 바라보고, “processing...” 표시줄을 기다리며, 페이지가 블록 단위로 천천히 렌더링되는 모습을 지켜봅니다.

그 기다림은 물리 법칙이 아니라 설계 결정입니다. 온라인 문서 뷰어 는 Doconut 엔진으로 구동되며, 사용자가 보는 첫 페이지를 먼저 준비하고 나머지는 읽는 동안 처리합니다.

레거시 뷰어가 느린 이유

왜 일부 뷰어가 지연되는지 이해하려면 그 작동 방식을 살펴봐야 합니다.

클라이언트‑사이드 무거움: 일부 뷰어는 전체 PDF 또는 파일을 브라우저에 다운로드하고 JavaScript로 렌더링하려 합니다. 100 MB 파일의 경우 사용자는 페이지 1을 보기 전에 전체 100 MB가 다운로드될 때까지 기다려야 합니다.
비효율적인 변환: 다른 뷰어는 서버에서 전체 문서를 이미지로 변환한 뒤에야 보여줍니다. 1,000페이지를 변환하는 데 시간이 걸려 첫 화면 표시가 지연됩니다.

속도의 비밀: 온‑디맨드 스트리밍

Doconut은 더 똑똑한 접근 방식을 사용합니다: 페이지‑레벨 스트리밍.

사용자가 문서를 열면:

첫 페이지 먼저: 엔진은 눈에 보이는 페이지를 렌더링해 전송하므로, 파일 전체가 처리되기 전에 문서가 열립니다.
백그라운드 처리: 사용자가 페이지 1을 읽는 동안 서버는 조용히 페이지 2와 3을 준비합니다.
벡터 최적화: 무거운 비트맵 대신 Doconut이 최적화된 SVG 데이터를 전송할 수 있어 가볍고 확대해도 픽셀화되지 않습니다.

중요한 성능 지표

뷰어를 평가할 때는 헤드라인을 믿지 말고 직접 파일로 측정하세요:

첫 바이트 시간 (TTFB): 서버 응답 속도는?
첫 페이지 시간 (TTFP): 사용자가 실제로 느끼는 뷰어 속도는?
스크롤 부드러움: 100페이지 문서를 끊김 없이 넘길 수 있나요?
콜드 vs 워밍: 워밍 실행은 최초 처리 비용을 숨깁니다. 두 경우 모두 테스트하세요.

동일한 머신, 브라우저, 네트워크 프로필, 문서 세트를 사용해 모든 후보를 비교하고, 평균이 아닌 백분위수를 보고하세요. 중앙값은 지원 티켓을 유발하는 느린 문서를 가릴 수 있습니다.

대역폭 친화적

속도는 CPU만이 아니라 네트워크를 가로지르는 양이기도 합니다.

모바일: 현재 화면에 보이는 페이지만 스트리밍하면 휴대폰이 읽지 않을 파일을 다운로드하지 않게 됩니다.
벡터 활용: 대용량 비트맵 대신 최적화된 벡터 데이터를 전송하면 기술 도면을 어떤 확대 수준에서도 선명하게 유지하면서 부담을 줄일 수 있습니다.

가장 느린 파일로 직접 체험해 보기

정직한 벤치마크는 오늘 당신을 짜증나게 하는 파일입니다. OnlineDocumentViewer.com 에서 열어 첫 페이지가 나타나는 순간을 확인하세요.

두 가지 제한을 미리 알아두세요. 업로드는 형식당 제한이 있습니다 — PDF, PSD, TIFF, Visio, EPUB 및 이미지 25 MB, Excel, PowerPoint 및 Project 20 MB, Word 15 MB, CAD 및 이메일 10 MB, HTML, XML 및 텍스트 5 MB — 따라서 정말 거대한 스캔 파일은 여기서 거부됩니다. 또한 파일은 보기 후 삭제됩니다. 다음 방문자를 위한 캐시가 없기 때문에 다음 방문자도 없습니다.

결론

인지된 속도는 한 가지 결정에서 비롯됩니다: 독자가 보고 있는 페이지를 먼저 준비하고, 나머지는 읽는 동안 준비합니다. 이것이 대용량 문서를 로딩 중이 아니라 바로 열려 있는 것처럼 느끼게 하는 비결입니다.

위 제한을 초과하거나 네트워크 밖으로 문서를 내보내야 하는 경우, 동일한 엔진을 Doconut SDK 로 라이선스하여 자체 하드웨어에서 실행할 수 있습니다. 이때는 가장 큰 파일을 처리할 수 있도록 머신 사양을 맞추면 됩니다.