منتجك يبطّأ أو يطيح لما يكثر الناس؟

لما تجرّب، منتجك فيه مستخدم واحد وعشر طلبات. يوم الإطلاق أو بعد إعلان، يصير فيه مئات الناس وآلاف الطلبات، وتطلع مشاكل ما كانت تبان. هذي الأسباب اللي نشوفها أكثر شي.

1. يجيب كل شي ويفلتر في المتصفح

الكود يطلب كل الطلبات من قاعدة البيانات، وبعدها يفلتر اللي يخص المستخدم في المتصفح. مع 50 طلب ما تحس، ومع 50 ألف الصفحة تعلّق. فوق البطء، هذي غالبًا ثغرة: البيانات كلها وصلت لمتصفح المستخدم. الصح إن قاعدة البيانات ترجع اللي تحتاجه بس، صفحة صفحة. شوف درس 5 ثغرات في تسجيل الدخول.

2. ما فيه فهارس (indexes)

الفهرس مثل فهرس الكتاب: بدونه قاعدة البيانات تقرأ الجدول كامل عشان تلقى سطر واحد. أي عمود تبحث فيه أو ترتّب عليه كثير، مثل رقم المستخدم أو التاريخ، يحتاج فهرس. في Supabase، صفحة Query Performance تقول لك أبطأ الاستعلامات.

3. طلب داخل حلقة

صفحة فيها 100 منتج، والكود يطلب سعر كل منتج بطلب لحاله: 100 طلب بدل طلب واحد. تحس فيه لما الصفحة تفتح ببطء حتى لو المستخدمين قلة. افتح تبويب Network في أدوات المطوّر (F12): إذا شفت عشرات الطلبات المتشابهة لصفحة وحدة، هذا هو.

4. صور بحجمها الأصلي

صورة من الجوال حجمها 4 ميغا تنعرض في مربع صغير. عشر منها في صفحة وحدة يعني 40 ميغا على جوال عميلك. الصور لازم تنضغط وتصغر قبل ما تنعرض.

5. حدود الخطة اللي أنت عليها

الخطط المجانية لها حدود: عدد الاتصالات بقاعدة البيانات، والطلبات في الدقيقة، والتخزين. بعضها يوقف المشروع إذا ما استخدمته فترة، مثل مشاريع Supabase المجانية اللي توقف بعد أسبوع بدون نشاط. اعرف حدود خطتك قبل الإطلاق، مو يومه. إذا منتجك على Replit، شوف ليش ينام ويصحى ببطء.

كيف تختبره قبل الإطلاق

على نسخة تجريبية، مو على منتجك الحقيقي، تقدر تحاكي زحمة بأداة مثل autocannon أو k6. مثلًا npx autocannon -c 50 -d 30 https://staging.example.com يرسل طلبات من 50 اتصال لمدة 30 ثانية، ويقول لك كم طلب انخدم وكم أخذ. جرّب بس على مواقعك أنت.

تبي تعرف قبل الإطلاق؟

الأداء والتكلفة من الجوانب التسعة في تدقيق جاهزية الإطلاق. إذا تعرف وش البطيء وتبيه ينصلح، فيه الإصلاح المباشر.