الموقع يفتح ببطء شديد، هل هي مشكلة تصميم أم مشكلة تطوير؟ هذا السؤال يواجهه تقريبًا كل من يعمل على موقع مؤسسي. يفتح المدير الموقع الرسمي ويرى دائرة التحميل تدور خمس ثوانٍ، فتكون ردة فعله الأولى غالبًا «هل السيرفر ضعيف جدًا». لكن الحقيقة هي: السيرفر يشكل جزءًا فقط، بينما التصميم والتطوير يشكلان جزءًا كبيرًا جدًا.
رأيت سيناريو نموذجيًا: شركة تعمل في مجال المعدات، بعد إعادة تصميم موقعها الرسمي انتقل وقت تحميل الصفحة الرئيسية من ثانيتين إلى 8 ثوانٍ. ظن المدير أن المشكلة في مركز البيانات، فقام بتغيير السيرفر مرتين، لكن الموقع بقي بطيئًا. في النهاية تبين أن التصميم وضع 12 صورة عالية الدقة في الصفحة الرئيسية، ولم يقم المطور بضغطها أو تفعيل التحميل الكسول، فطلبت الشاشة الأولى أكثر من 30 موردًا دفعة واحدة.
لذلك لا يمكن الإجابة على هذا السؤال بشكل عشوائي. فيما يلي نشرح الأمر حسب ترتيب التشخيص.
أولًا: ميّز أولًا بين ثلاثة أنواع من «البطء»
البطء في الفتح ليس مرضًا واحدًا، بل ينقسم على الأقل إلى ثلاثة أنواع:
- طول الشاشة البيضاء الأولى: بعد النقر على الرابط تبقى الشاشة فارغة لفترة طويلة، وعادة يكون السبب حجم الموارد الكبير أو بطء الواجهات البرمجية أو حجب السكربتات.
- يفتح لكن التفاعل متقطع: تظهر الصفحة، لكن التمرير والنقر وتبديل التبويبات متقطع، وغالبًا يكون السبب منطق الواجهة الأمامية أو الرسوم المتحركة الثقيلة جدًا.
- سريع أحيانًا وبطيء أحيانًا: بطيء نهارًا وسريع ليلًا، أو بطيء في مناطق معينة، وغالبًا يكون السبب النطاق الترددي أو CDN أو إعدادات السيرفر.
حدد أولًا أي نوع من هذه الأنواع، ثم تحدث عن مسؤولية من. وإلا فمن السهل جدًا أن يحدث تبادل اللوم: «المصمم يقول المطور لم يحسّن، والمطور يقول ملف التصميم كبير جدًا».
ثانيًا: على مستوى التصميم: قد يكون ملف التصميم المرئي قد زرع المشكلة من البداية
التصميم ليس مجرد رسم جميل، فقرارات التصميم تحدد مباشرة وزن الصفحة. من الأخطاء الشائعة:
1. صورة كبيرة غير واقعية في الشاشة الأولى: وضع صورة رئيسية بدقة 4K مباشرة في الشاشة الأولى، مع طلب عدم ضغطها.
2. استخدام خطوط كثيرة جدًا: إدخال أربعة أو خمسة خطوط صينية في صفحة واحدة، كل نوع بحجم مئات الكيلوبايت، فيصبح التحميل بطيئًا بطبيعة الحال.
3. تكديس التأثيرات الحركية: تشغيل رسوم الدخول ورسوم التمرير وتأثيرات البارالاكس كلها، فتصبح الهواتف متجمدة مباشرة.
4. عدم وجود مواصفات للصور: ملف التصميم يعطي التأثير فقط، دون اقتراح المقاسات أو الصيغ، فيضطر المطور إلى نسخها كما هي.
طريقة تجنب هذه المشكلات بسيطة: يتم الاتفاق في مرحلة التصميم على أن الصورة الرئيسية للشاشة الأولى لا تتجاوز 300KB، والخطوط الصينية في الموقع كله لا تتجاوز مجموعتين، والتأثيرات الحركية تقتصر على تأثير أو تأثيرين ضروريين فقط. هذه ليست قيودًا على الإبداع، بل هي ما يجعل الإبداع قابلًا للتنفيذ.
ثالثًا: على مستوى التطوير: معظم مشكلات الأداء تظهر في هذه النقاط
إذا كان ملف التصميم نفسه سليمًا، فيجب النظر إلى مرحلة تطوير الموقع. من نقاط الضعف الشائعة في الأداء:
- الصور غير مضغوطة، وغير محولة إلى WebP، وبدون تحميل كسول، وهذا أكثر الأنواع شيوعًا وأسهلها في الإصلاح.
- استدعاء الواجهات البرمجية بشكل تسلسلي: الصفحة الرئيسية تنتظر عودة الواجهة A قبل طلب الواجهة B، مما يضيف مئات المللي ثانية بلا داعٍ.
- كثرة السكربتات الخارجية: الإحصاءات وخدمة العملاء والخرائط وإضافات الإعلانات، كل واحد منها يبطئ الشاشة الأولى.
- عدم وجود استراتيجية تخزين مؤقت: كل زيارة تعيد جلب البيانات كاملة، مما يضغط على السيرفر ويطيل انتظار المستخدم.
- عدم تقسيم حزمة الواجهة الأمامية: تحميل ملف JS بحجم عدة ميغابايت دفعة واحدة، فتكون الشاشة الأولى بطيئة حتمًا.
هناك حيلة تشخيصية هنا: استخدم أدوات مطوري المتصفح وانظر إلى لوحة Network، فإذا تجاوز عدد طلبات الشاشة الأولى 50 طلبًا، أو تجاوز مورد واحد 1MB، فيمكن الجزم تقريبًا بأن تحسينات التطوير لم تُنفذ بشكل كافٍ.
رابعًا: السيرفر والنشر: لا تعتبره السبب الوحيد، ولا تتجاهله
السيرفر يؤثر فعلًا على السرعة، لكنه عادة ليس السبب الرئيسي لبطء الشاشة الأولى. ما يجب الانتباه إليه:
- هل النطاق الترددي كافٍ، خصوصًا للمواقع المؤسسية كثيرة الصور.
- هل تم تفعيل CDN، وهل يتم توزيع الموارد الثابتة إلى عقد قريبة من المستخدم.
- هل توجد استعلامات بطيئة في قاعدة البيانات، ويظهر ذلك خصوصًا في أنظمة الإدارة الخلفية.
- هل تم تفعيل ضغط Gzip أو Brotli.
من المفاهيم الخاطئة الشائعة: إنفاق مبالغ كبيرة على ترقية السيرفر دون ضغط الصور. والنتيجة أن المال يُصرف، بينما تتحسن السرعة قليلًا فقط. الترتيب الصحيح هو تحسين موارد الواجهة الأمامية أولًا، ثم التفكير في زيادة المواصفات.
خامسًا: سيناريوهات محددة: لماذا تكون تطبيقات الحجز وأنظمة الإدارة بطيئة أيضًا
ليس الأمر مقتصرًا على المواقع المؤسسية، فـ تطوير التطبيقات المصغرة و تطوير التطبيقات يواجهان المشكلات نفسها.
مثلًا تطبيق مصغر للحجز، ينتظر المستخدم بعد فتحه ثلاث ثوانٍ حتى تظهر أوقات الحجز المتاحة. بعد التشخيص تبين أن الصفحة عند الدخول تطلب أربع واجهات في الوقت نفسه: قائمة الفروع، والخدمات، ومعلومات المستخدم، والفترات المتاحة للحجز، دون أي تخزين مؤقت. بعد التعديل ليتم عرض شاشة هيكلية أولًا، وطلب الواجهات بالتوازي، وتخزين بيانات الفترات محليًا، انخفض وقت الشاشة الأولى إلى أقل من ثانية.
ومثال آخر نظام إدارة خلفي، صفحة القائمة تعيد استعلام الجدول كاملًا عند كل تنقل بين الصفحات. بعد إضافة الفهارس وتخزين الترقيم مؤقتًا، انخفض زمن الاستجابة من 4 ثوانٍ إلى 300 مللي ثانية.
هذه ليست مشكلات تصميم، وليست بالكامل مشكلات سيرفر، بل هي مشكلة وعي بالأداء في مرحلة التطوير.
سادسًا: متى يكون من المناسب اللجوء إلى MIC Studio
إذا كنت قد راجعت الأمور وفق الترتيب أعلاه ولم تجد السبب، أو لم يكن في الفريق من يفهم التصميم والواجهة الأمامية والخلفية والنشر في الوقت نفسه، فحينها يكون من المناسب إشراك فريق متخصص.
تعمل MIC Studio في المواقع المؤسسية، وتطوير التطبيقات المصغرة، وتطوير التطبيقات، وتطوير السكربتات، كما تقوم باختبارات أمان المواقع والاختبارات العكسية. منهجنا في التعامل مع هذه المشكلات هو: قياس السرعة أولًا لتحديد الموقع، ثم تقديم قائمة تحسينات، والتعديل حسب الأولوية، وليس مطالبتك بإعادة العمل من الصفر مباشرة.
من الحالات المناسبة للجوء إلينا:
- الموقع الرسمي أصبح أبطأ بشكل واضح بعد إعادة التصميم، ولا تستطيع معرفة السبب بنفسك؛
- تحميل الشاشة الأولى في التطبيق المصغر أو التطبيق يتجاوز 3 ثوانٍ ويؤثر على التحويل؛
- النظام الخلفي يزداد بطئًا مع الاستخدام، وتصبح الاستجابة بطيئة بعد زيادة البيانات؛
- تحتاج إلى خطة تحسين أداء قابلة للتنفيذ، وليس مجرد «نوصي بالتحسين» بشكل عام.
الخاتمة: ثلاث توصيات قابلة للتنفيذ
1. قِس أولًا ثم عدّل: استخدم أدوات المطورين أو منصات قياس السرعة لتسجيل زمن الشاشة الأولى وعدد الطلبات وحجم الموارد، واعتمد على البيانات، ولا تغيّر السيرفر بناءً على الإحساس.
2. مواءمة التصميم والتطوير مسبقًا: اتفق في مرحلة التصميم المرئي على مواصفات الصور وعدد الخطوط ونطاق التأثيرات الحركية، فهذا يوفر الكثير من إعادة العمل لاحقًا.
3. لا تعكس ترتيب التحسين: اضغط الصور أولًا، وقلل الطلبات، وأضف التخزين المؤقت، ثم فكر في ترقية النطاق الترددي والسيرفر، فهذا هو الأعلى قيمة مقابل التكلفة.
بطء الموقع ليس مخيفًا، المخيف هو الاستمرار في التخمين. قسّم المشكلة إلى ثلاثة أجزاء: التصميم والتطوير والنشر، واختبر كل جزء على حدة، وستظهر الإجابة تلقائيًا.