prefetch

دارایی حجیم را پیش از آنکه لازم شود در انبارهٔ مرورگر گرم می‌کند، آن هم بی‌آنکه پشت سر کاربر داده‌اش را خرج کند.

نکتهٔ اصلی: اگر یک Service Worker درخواست‌های GETِ هم‌مبدأ را نخست از انباره پاسخ دهد، تنها یک بار fetch کردن نشانی کافی است تا در CacheStorage بنشیند. هر درخواست بعدی برای همان نشانی به انباره می‌خورد و آفلاین هم کار می‌کند. پس پیش‌واکشی به بارگیرِ ویژه‌ای نیاز ندارد: کافی است بایت‌ها را به درون بکشید.

API

تابع	توضیح
whenIdle(callback, options?)	وقتی مرورگر بیکار است اجرا می‌کند؛ تابعی برای لغو برمی‌گرداند
networkAllowsDownload(options?)	آیا همین حالا می‌توان دادهٔ کاربر را خرج کرد؟
isUrlCached(url)	آیا این نشانی از پیش در CacheStorage هست؟
prefetchUrl(url)	یک نشانی را به انباره می‌کشد؛ اگر باشد از آن می‌گذرد و اگر شکست بخورد خاموش می‌ماند
prefetchUrls(urls, options?)	همین کار برای یک فهرست، پشت سر هم
prefetchWhenIdle(urls, options?)	هر سه با هم: اجازه ← بیکاری ← پیش‌واکشی پیاپی. مسدود نمی‌کند

گزینه‌ها

گزینه	مربوط به	توضیح	پیش‌فرض
timeout	whenIdle	بیشترین انتظار برای requestIdleCallback (میلی‌ثانیه)	8000
fallbackDelay	whenIdle	انتظار وقتی requestIdleCallback نباشد (میلی‌ثانیه)	2500
optOutKey	اجازهٔ شبکه	کلید localStorage؛ هر مقداری که باشد یعنی کاربر پیش‌واکشی را خاموش کرده است	—
slowTypes	اجازهٔ شبکه	مقدارهای effectiveType که بیش از حد کند شمرده می‌شوند	['slow-2g', '2g']
serviceWorkerMessage	prefetchUrls	مقدار type پیامی که فهرست را به SWِ در حال کنترل می‌سپارد	—

نمونه

import { prefetchWhenIdle, isUrlCached } from 'ranuts';

prefetchWhenIdle(modelFiles, {
  optOutKey: 'disable_model_prefetch',
  serviceWorkerMessage: 'precache-models',
});

// بعدتر: آیا از پیش محلی است؟ (فایلی را وارسی کنید که دیرتر از همه بارگیری‌اش تمام می‌شود)
const ready = await isUrlCached(modelFiles.at(-1));

یادداشت‌ها

1. پیش‌واکشی دادهٔ کسی دیگر را خرج می‌کند. networkAllowsDownload هنگام روشن بودن صرفه‌جویی داده، روی اتصال کند، یا وقتی کاربر نخواسته باشد، سر باز می‌زند.
2. ندانستن یعنی اجازه دادن. Network Information API در سافاری و فایرفاکس نیست؛ ناتوانی در خواندن وضع اتصال دلیلی نمی‌شود که هرگز پیش‌واکشی نکنیم.
3. فهرست‌ها پشت سر هم گرفته می‌شوند: اشباع کردن لوله، همان صفحه‌ای را کند می‌کند که کاربر واقعاً به آن نگاه می‌کند.
4. راه Service Worker را ترجیح دهید. SWی که از event.waitUntil استفاده می‌کند، حتی با جابه‌جایی میان صفحه‌ها بارگیری را ادامه می‌دهد؛ اما fetchِ رشتهٔ اصلی به‌محض رفتن کاربر می‌میرد. اگر SWی در حال کنترل نباشد، خودبه‌خود به همان راه دیگر پناه می‌برد.
5. برای وارسیِ انباره‌شدنِ یک مجموعه، بزرگ‌ترین فایل را بیازمایید، وگرنه بارگیریِ نیمه‌کاره کامل خوانده می‌شود.
6. خاموش بودن شکست‌ها عمدی است: پیش‌واکشیِ ناکام تنها یعنی بارگذاری واقعی دیرتر دانلود می‌کند.