پیش کش کردن بایدها و نبایدها

این مستندات قبلاً پیش کش را پوشش داده است، اما در مورد نحوه درست کردن آن کافی نیست. این مهم است، زیرا صرف نظر از اینکه از Workbox استفاده می‌کنید، به راحتی می‌توانید اطلاعات و پهنای باند را از قبل ذخیره کنید. شما باید مراقب باشید که چگونه بار پیش کش شما بر تجربه کاربر تأثیر می گذارد.

همانطور که این سند را می خوانید، درک کنید که اینها دستورالعمل های کلی هستند. معماری و الزامات برنامه شما ممکن است از شما بخواهد که کارها را متفاوت از آنچه در اینجا پیشنهاد شده است انجام دهید، اما این دستورالعمل ها به عنوان پیش فرض های خوبی عمل می کنند.

انجام دهید: دارایی های استاتیک بحرانی را پیش کش کنید

بهترین کاندیدها برای پیش کش، دارایی های ایستا حیاتی هستند، اما چه چیزی به عنوان دارایی "بحرانی" محسوب می شود؟ از منظر توسعه‌دهنده، ممکن است وسوسه‌انگیز باشد که یک برنامه کاربردی را «بحرانی» بدانیم، اما دیدگاه کاربر بیشترین اهمیت را دارد. دارایی های حیاتی را به عنوان دارایی هایی که برای ارائه تجربه کاربری کاملا ضروری هستند در نظر بگیرید:

• شیوه نامه های جهانی
• فایل های جاوا اسکریپت که عملکرد جهانی را ارائه می دهند.
• HTML پوسته برنامه، اگر برای معماری شما صدق می کند.

یادآوری: اینها دستورالعمل های کلی هستند، نه توصیه های سخت. هنگام پیش کش کردن دارایی ها، بهتر است در مورد پیش ذخیره سازی کمتر به جای بیشتر اشتباه کنید.

انجام دهید: یک نسخه بازگشتی آفلاین را برای وب سایت های چند صفحه ای پیش کش کنید

برای وب‌سایت‌های چند صفحه‌ای معمولی، ممکن است برای رسیدگی به درخواست‌های ناوبری به استراتژی ذخیره‌سازی شبکه اول یا فقط شبکه تکیه کنید.

در چنین مواردی، باید اطمینان حاصل کنید که کارگر سرویس شما زمانی که کاربر در حالت آفلاین درخواست ناوبری می کند، یک صفحه بازگشتی آفلاین را پیش کش می کند و به آن پاسخ می دهد. یکی از راه‌های انجام این کار در Workbox ممکن است استفاده از یک استراتژی فقط شبکه با یک بازگشت آفلاین باشد و از پیش‌بارگذاری ناوبری نیز استفاده کنید:

import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';

navigationPreload.enable();

// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);

// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
  return request.mode === 'navigate';
}, new NetworkOnly({
  plugins: [
    new PrecacheFallbackPlugin({
      fallbackURL: '/offline.html'
    })
  ]
}));

registerRoute(networkOnlyNavigationRoute);

این تضمین می‌کند که اگر کاربر آفلاین شود و به صفحه‌ای که در حافظه پنهان او نیست هدایت شود، حداقل محتوای آفلاین دریافت خواهد کرد.

شاید انجام دهید: پیش کشی سوداگرانه را در نظر بگیرید

این یک "شاید" بزرگ است، اما یک مزیت بالقوه در پیش کش کردن دارایی هایی وجود دارد که فقط تحت سناریوهای خاصی استفاده می شوند. در مورد آن به این صورت فکر کنید: کاربران با مزیت احتمالی سرعت بخشیدن به درخواست‌های آینده برای آن دارایی‌ها، بارگیری‌های اضافی قبلی را متحمل خواهند شد.

اکنون برای هشدار بزرگ: اگر تصمیم به انجام این کار دارید، بسیار مراقب باشید. هدر دادن داده ها در انجام این کار آسان است و این باید یک تصمیم مبتنی بر داده باشد. علاوه بر این، از پیش‌کش کردن دارایی‌هایی که به طور مکرر تغییر می‌کنند خودداری کنید، زیرا کاربر هر بار که کد پیش‌کش‌کننده نسخه جدیدی را شناسایی می‌کند، متحمل استفاده از داده‌های اضافی می‌شود. جریان های کاربر را در تجزیه و تحلیل خود مشاهده کنید تا ببینید کاربران تمایل دارند به کجا بروند. اگر در مورد پیش ذخیره سازی دارایی ها به صورت سفته بازی شک دارید، احتمالاً نشانه خوبی برای انجام ندادن آن است.

شاید این کار را نکنید: HTML ایستا را پیش کش کنید

این دستورالعمل بیشتر در مورد سایت‌های ایستا کاربرد دارد که در آن فایل‌های HTML گسسته یا توسط یک مولد سایت استاتیک تولید می‌شوند یا به‌طور دستی ایجاد می‌شوند، به‌جای اینکه به‌صورت پویا تولید یا توسط یک برنامه کاربردی ارائه شوند. اگر این معماری شما را توصیف می کند، پس احتمالاً بهترین کار این است که هر فایل HTML را برای وب سایت خود پیش کش نکنید .

یکی از مشکلات پیش‌کش کردن کل فایل‌های HTML یک سایت این است که نشانه‌گذاری‌هایی که اکنون از پیش ذخیره می‌شوند، همیشه بعداً تا زمانی که سرویس‌کار به‌روزرسانی شود، از حافظه پنهان ارائه می‌شود. این برای عملکرد عالی است، اما اگر HTML وب سایت شما به طور مکرر تغییر کند، می تواند منجر به ریزش حافظه پنهان شود.

هر چند چند استثنا در این قاعده وجود دارد. اگر یک وب‌سایت کوچک با چند فایل HTML ایستا راه‌اندازی می‌کنید، احتمالاً خوب است که همه آن صفحات را پیش کش کنید تا آفلاین در دسترس باشند. اگر وب‌سایت بزرگی دارید، چند صفحه با ارزش بالا و یک نسخه بازگشتی آفلاین را به صورت حدس و گمان پیش کش کنید و برای ذخیره کردن صفحات دیگر برای خود به کش در زمان اجرا تکیه کنید.

انجام ندهید: تصاویر یا فاویکون های پاسخگو را از قبل ذخیره کنید

این کمتر یک دستورالعمل کلی و بیشتر یک قانون است. تصاویر واکنش گرا راه حلی پیچیده برای یک مشکل پیچیده هستند: شما کاربران زیادی در دستگاه های بسیاری دارید که هر کدام از نظر اندازه صفحه نمایش، تراکم پیکسلی و پشتیبانی از فرمت های جایگزین متفاوت هستند. اگر مجموعه کاملی از تصاویر واکنش‌گرا را پیش کش می‌کنید، احتمالاً چندین تصویر را پیش کش می‌کنید در حالی که کاربر ممکن است تنها یکی از آنها را دانلود کند.

فاویکون ها وضعیت مشابهی را ارائه می دهند، به این صورت که وب سایت ها اغلب مجموعه ای کامل از فاویکون ها را برای سناریوهای مختلف مستقر می کنند. اغلب، فقط یک فاویکون درخواست می‌شود، که باعث می‌شود پیش کش کردن کل مجموعه فاویکون به طور مشابه بیهوده باشد.

به کاربران خود لطف کنید و مجموعه‌های عکس‌های واکنش‌گرا و فاویکون‌ها را از قبل ذخیره نکنید. به جای آن به ذخیره سازی زمان اجرا تکیه کنید. اگر باید تصاویر را پیش کش کنید، تصاویر پرکاربردی که بخشی از مجموعه ای از تصاویر واکنشگرا یا فاویکون نیستند را پیش کش کنید. SVGها از نظر استفاده از داده خطر کمتری دارند، یک SVG تنها بدون در نظر گرفتن تراکم پیکسلی صفحه نمایش، به صورت بهینه ارائه می شود.

Don't: Precache polyfills

پشتیبانی از مرورگرهای مختلف از APIها یک چالش همیشگی برای توسعه دهندگان وب است و polyfilling یکی از راه هایی است که با چالش مواجه می شود. یکی از راه‌های به حداقل رساندن هزینه عملکرد پلی‌فیل‌ها، بررسی ویژگی‌ها و بارگذاری پلی‌فیل‌ها برای مرورگرهایی است که به آن‌ها نیاز دارند.

از آنجا که بارگذاری مشروط polyfills در طول زمان اجرا با توجه به محیط فعلی اتفاق می‌افتد، پیش کش کردن polyfill‌ها یک قمار است. برخی از کاربران از آن سود می برند، در حالی که برخی دیگر در نهایت پهنای باند را برای پلی پرهای غیر ضروری تلف می کنند.

پلی فیل ها را پیش کش نکنید. برای اطمینان از اینکه فقط در مرورگرهایی که به آنها نیاز دارند تا از هدر رفتن داده ها جلوگیری کنند، به کش در زمان اجرا تکیه کنید.

نتیجه گیری

پیش کش نیاز به تفکر قبلی در مورد دارایی هایی دارد که کاربران شما واقعاً به آنها نیاز دارند، اما قطعاً می توانید آن را به گونه ای درست انجام دهید که عملکرد و قابلیت اطمینان آینده را در اولویت قرار دهد.

اگر مطمئن نیستید که آیا دارایی‌های خاصی باید از پیش ذخیره شوند، بهترین گزینه ممکن است این باشد که به Workbox بگویید آن دارایی‌ها را حذف کند و یک مسیر ذخیره زمان اجرا برای مدیریت آنها ایجاد کند. در هر صورت، پیش کش در آینده به تفصیل در این مستندات پوشش داده شده است ، بنابراین شما می توانید این اصول را در منطق پیش کش خود در آینده اعمال کنید.