SaaS شما به‌اندازهٔ کافی سریع است — تا وقتی که نباشد

افت‌های کارایی به‌ندرت با یک تصمیم بد یک‌جا می‌آیند. روی هم انباشته می‌شوند: یک وابستگی که کتابخانهٔ نمودار خودش را هم با خودش آورده، یک لیست که بدون مجازی‌سازی رندر می‌شود، یک مسیر پردازش تصویر «موقت» که کسی جایگزینش نکرد.

وقتی کندی به چشم کاربران می‌آید، از قبل در سراسر کد پخش شده است؛ به همین دلیل ممیزی را طبق برنامه انجام می‌دهیم و منتظر شکایت نمی‌مانیم. این ترتیبی است که ممیزی را در آن اجرا می‌کنیم، و دلیلش.

از مرز شبکه شروع کنید

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

بعد رندر را بسنجید، نه فقط بارگذاری را

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

ممیزی، به ترتیب

• اندازهٔ انتقال و کش در مسیر حیاتی
• تصاویر: فرمت، ابعاد و مرز‌های بارگذاری تأخیری
• جاوااسکریپت: چه چیزی ارسال می‌شود، چه چیزی هنگام بارگذاری اجرا می‌شود، چه چیزی می‌تواند صبر کند
• داده: تعداد کوئری در هر رندر و هر N+1 در مسیر داغ
• تعامل: هزینهٔ hydration و اشغال ترد اصلی
• اندازه‌گیری: بودجه‌های متصل به CI تا افت‌ها بیلد را رد کنند

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