يا جماعة الخير، السلام عليكم ورحمة الله وبركاته. معكم أخوكم أبو عمر.
خليني أحكيلكم قصة صارت معي قبل كم سنة، قصة علّمتني درس ما بنساه بحياتي كمبرمج. كنت وقتها شغال على مشروع شخصي، متجر إلكتروني صغير لبيع منتجات حرفية. قضيت شهور وأنا أبني فيه، سهران الليالي، وكاتب كل سطر كود بحب وشغف. لما خلصت، كنت فخور جداً بالنتيجة. الموقع كان تصميمه حلو، وشغال مية بالمية… على جهازي طبعاً.
جهازي المكتبي وقتها كان “وحش”، معالج قوي، رام عالية، وخط انترنت فايبر سريع. كل ما أفتح الموقع، يفتح بلمح البصر. الصفحات تتنقل بسلاسة، الصور تظهر فوراً. قلت لحالي: “خلص، هي الشغل الصح يا أبو عمر!”. بكل ثقة، بعتت الرابط لصديقي أبو خليل عشان “أتشاوَف” عليه شوي وأورجيه إبداعاتي.
بعد دقيقتين، رن عليّ تلفون. كان أبو خليل. توقعت منه مديح وإطراء، بس اللي سمعته كان صدمة: “أبو عمر، يعطيك العافية، بس شو هالموقع البطيء؟ فتحت الصفحة الرئيسية وبعدني بستنى الصور تْحمّل!”.
أول ردة فعل إلي كانت دفاعية: “كيف يعني بطيء؟ عندي زي الصاروخ! يمكن النت عندك ضعيف!”. لكن أبو خليل أكّدلي إنه النت عنده ممتاز. هون بلّش الشك يدخل قلبي. كيف ممكن يكون الموقع سريع عندي وبطيء عنده لهالدرجة؟ هاي اللحظة كانت بداية رحلتي مع عالم اختبارات الأداء، واللحظة اللي اكتشفت فيها إن عبارة “شغال على جهازي” هي من أكبر الأوهام اللي ممكن يعيشها المبرمج.
الوهم الكبير: لماذا كان موقعي سريعاً على جهازي فقط؟
بعد الصدمة الأولى، قعدت أفكر وأحلل. ليش تجربتي كانت مختلفة تماماً عن تجربة المستخدم الحقيقي؟ الأسباب كانت واضحة بس أنا كنت متجاهلها:
- قوة الجهاز (Hardware): جهازي المكتبي بمعالجه القوي وذاكرته الكبيرة قادر على معالجة أكواد JavaScript المعقدة ورسم العناصر على الشاشة بسرعة فائقة، وهذا لا يعكس قدرة هاتف محمول متوسط.
- سرعة الإنترنت (Network): اتصالي الفايبر ذو الكمون (Latency) المنخفض جداً يخفي مشاكل حجم الملفات الكبيرة. المستخدم العادي على شبكة 4G أو حتى 3G يعاني الأمرين لتحميل صورة حجمها 2 ميغابايت.
- التخزين المؤقت (Browser Caching): بما أني مطور الموقع، فأنا أزوره مئات المرات في اليوم. المتصفح عندي كان حافظ كل ملفات CSS و JavaScript والصور. الزائر الجديد لا يملك هذا الترف، فهو يحمّل كل شيء من الصفر.
- القرب من الخادم (Server Proximity): في بعض مراحل التطوير، كنت أختبر الموقع على خادم محلي (localhost). هنا، لا يوجد أي تأخير في الشبكة على الإطلاق!
أدركت أني كنت أعيش في “فقاعة المطور” المثالية، بينما المستخدمون الحقيقيون يعيشون في عالم مختلف تماماً. كنت بحاجة لأداة تخرجني من فقاعتي وتورجيني الحقيقة المُرّة. وهنا كان دور البطل: أداة Lighthouse.
Lighthouse: القاضي النزيه الذي لا يجامل
Lighthouse هي أداة مجانية ومفتوحة المصدر من جوجل، مصممة لتحليل صفحات الويب وتقديم تقارير مفصلة عن جودتها. هي ليست مجرد أداة لقياس السرعة، بل تقيّم الموقع من عدة جوانب حيوية: الأداء (Performance)، إمكانية الوصول (Accessibility)، أفضل الممارسات (Best Practices)، وتحسين محركات البحث (SEO).
كيف تبدأ مع Lighthouse؟
أجمل ما في Lighthouse هو سهولة الوصول إليها. لا تحتاج لتثبيت أي شيء معقد. أسهل طريقة هي من خلال متصفح Google Chrome:
- افتح موقعك في Chrome.
- اضغط على
F12(أوCtrl+Shift+I) لفتح أدوات المطور (DevTools). - اذهب إلى تبويب “Lighthouse”.
- اختر الفئات التي تريد اختبارها (ركّز على “Performance” مبدئياً).
- نقطة مهمة: اختر “Mobile” كجهاز للاختبار. معظم المستخدمين يأتون من الهواتف، وهذه هي التجربة التي نريد تحسينها.
- اضغط على “Analyze page load”.
بعد دقيقة تقريباً، ستظهر لك النتيجة. في حالتي، كانت النتيجة صادمة. درجة الأداء (Performance Score) كانت في المنطقة الحمراء، حوالي 35 من 100! هنا عرفت أن أبو خليل كان على حق، وأن أمامي عمل كثير.
الغوص في المقاييس: فهم مؤشرات أداء الويب الأساسية (Core Web Vitals)
الرقم 35 كان محبطاً، لكن القوة الحقيقية لـ Lighthouse تكمن في التفاصيل. الأداة لا تعطيك درجة سيئة وتتركك، بل تشرح لك بالتفصيل سبب هذه الدرجة من خلال مجموعة من المقاييس، أهمها ما تسميه جوجل “مؤشرات أداء الويب الأساسية” أو Core Web Vitals.
هذه المؤشرات الثلاثة تقيس ثلاثة جوانب أساسية من تجربة المستخدم: سرعة التحميل، سرعة الاستجابة، والاستقرار البصري.
1. أكبر محتوى مرئي (Largest Contentful Paint – LCP)
“متى المستخدم بشوف الأشي المهم؟”
هذا المقياس يجيب عن سؤال: كم من الوقت يستغرق ظهور أكبر عنصر (صورة أو كتلة نصية) في الشاشة؟ هو يعبر عن السرعة “المحسوسة” للتحميل. إذا كان هذا الرقم عالياً، يشعر المستخدم أن الصفحة فارغة وبطيئة.
- جيد: أقل من 2.5 ثانية.
- يحتاج تحسين: بين 2.5 و 4 ثوانٍ.
- سيء: أكثر من 4 ثوانٍ.
في موقعي، كان السبب الرئيسي لضعف الـ LCP هو صورة الهيدر الضخمة التي كنت أستخدمها في الصفحة الرئيسية. كان حجمها حوالي 3 ميجابايت!
نصيحة من خبرتي: الصور هي العدو الأول للـ LCP. قبل رفع أي صورة لموقعك، قم بضغطها جيداً باستخدام أدوات مثل Squoosh، وحاول استخدام صيغ حديثة مثل WebP التي تعطي جودة ممتازة بحجم أقل بكثير. ولا تنسَ إضافة التحميل الكسول (Lazy Loading) للصور التي لا تظهر في الجزء الأول من الشاشة.
<!-- المتصفح سيؤجل تحميل هذه الصورة حتى يقترب المستخدم من رؤيتها -->
<img src="my-image.jpg" alt="وصف الصورة" loading="lazy" width="800" height="600">2. التفاعل مع أول رسمة تالية (Interaction to Next Paint – INP)
“كبست عالزر… ليش ما في إشي بصير؟”
هذا هو المقياس الأحدث والأكثر دقة لقياس الاستجابة (كان قبله FID). يقيس INP الوقت من لحظة تفاعل المستخدم (نقرة، ضغطة مفتاح) حتى يرى تحديثاً بصرياً على الشاشة. إذا نقرت على زر “إضافة للسلة” ولم يحدث شيء لثانية أو اثنتين، ستشعر أن الموقع “معلّق” أو مكسور.
- جيد: أقل من 200 ميلي ثانية.
- يحتاج تحسين: بين 200 و 500 ميلي ثانية.
- سيء: أكثر من 500 ميلي ثانية.
السبب الرئيسي لضعف هذا المقياس هو وجود أكواد JavaScript طويلة تعمل على الـ “Main Thread” (الخيط الرئيسي للمتصفح)، مما يمنعه من الاستجابة للمستخدم. في حالتي، كان لدي سكربت يقوم بفلترة المنتجات على الواجهة الأمامية بطريقة غير فعالة، مما كان “يجمّد” الصفحة لبرهة عند استخدامه.
نصيحة من خبرتي: قسّم مهام JavaScript الطويلة إلى أجزاء أصغر. استخدم
setTimeoutأوrequestIdleCallbackلتنفيذ الأكواد غير العاجلة عندما يكون المتصفح متفرغاً. للمهام الثقيلة جداً، فكر في استخدام Web Workers لتشغيلها في خيط منفصل تماماً دون التأثير على واجهة المستخدم.
3. متغيّرات التصميم التراكمية (Cumulative Layout Shift – CLS)
“كنت بدي أكبس هون… ليش الصفحة نطّت؟”
هل سبق لك أن حاولت النقر على رابط، وفي اللحظة الأخيرة “قفزت” الصفحة لأسفل بسبب ظهور إعلان أو تحميل صورة، مما جعلك تنقر على شيء آخر عن طريق الخطأ؟ هذا هو الـ CLS. إنه يقيس مدى الاستقرار البصري للصفحة.
- جيد: أقل من 0.1.
- يحتاج تحسين: بين 0.1 و 0.25.
- سيء: أكثر من 0.25.
الأسباب الشائعة هي الصور التي لا يتم تحديد أبعادها، الإعلانات التي يتم حقنها ديناميكياً، أو تحميل الخطوط الذي يسبب تغييراً في حجم النص.
نصيحة من خبرتي: هذا المقياس من أسهل المقاييس التي يمكن إصلاحها. القاعدة الذهبية: دائماً قم بتحديد أبعاد (width و height) للصور والعناصر التي قد تسبب قفزات في التصميم. هذا يسمح للمتصفح بحجز مساحة لها حتى قبل تحميلها.
<!-- سيء: المتصفح لا يعرف حجم الصورة قبل تحميلها -->
<img src="logo.png">
<!-- جيد: المتصفح يحجز مساحة 200x100 بكسل -->
<img src="logo.png" width="200" height="100">
<!-- أفضل للتصميم المتجاوب باستخدام CSS -->
<!-- HTML -->
<img src="logo.png" class="my-logo">
<!-- CSS -->
.my-logo {
width: 100%; /* or any responsive width */
height: auto;
aspect-ratio: 200 / 100; /* يحافظ على نسبة العرض للارتفاع */
}
الكنز الحقيقي: أقسام “الفرص” و “التشخيصات”
بعد فهم المقاييس، ستجد في تقرير Lighthouse قسمين في غاية الأهمية:
- Opportunities (الفرص): يقدم لك Lighthouse هنا توصيات مباشرة وقابلة للتنفيذ. سيقول لك مثلاً: “قم بضغط هذه الصور”، “أزل أكواد CSS غير المستخدمة”، “فعّل ضغط النص”. والأجمل أنه يخبرك بالوفر المحتمل في الوقت إذا قمت بتنفيذ هذه التوصية.
- Diagnostics (التشخيصات): يقدم هذا القسم معلومات أعمق حول أداء صفحتك، مثل حجم DOM، والمهام الطويلة التي تعيق الخيط الرئيسي، وأحجام الشبكة الضخمة.
هذان القسمان هما خارطة طريقك نحو تحسين الأداء. لا تركز فقط على الدرجة النهائية، بل اقضِ وقتاً في قراءة كل توصية وفهمها. كل توصية هي درس مجاني في تحسين أداء الويب.
الخلاصة: من مبرمج “شاطر” إلى مطور يهتم بالمستخدم
قصتي مع موقعي البطيء كانت جرس إنذار. علمتني أن بناء موقع “يعمل” هو مجرد البداية. النجاح الحقيقي يكمن في بناء موقع يقدم تجربة مستخدم ممتازة، والأداء هو حجر الزاوية في هذه التجربة. أدوات مثل Lighthouse ليست لإحباطنا، بل لتمكيننا. إنها تمنحنا عيون المستخدم وأدواته، وتجبرنا على الخروج من فقاعتنا المريحة لنبني منتجات أفضل للعالم الحقيقي.
نصيحتي الأخيرة لك: اجعل اختبار الأداء جزءاً لا يتجزأ من روتين عملك. لا تنتظر حتى النهاية لتكتشف الكارثة. قم بتشغيل Lighthouse بشكل دوري مع كل تغيير كبير تقوم به. تذكر دائماً أنك لا تبني الموقع لنفسك، بل لمستخدم قد يكون على هاتف قديم واتصال إنترنت بطيء في مكان ما من هذا العالم الواسع.
ما تنسوا، الموقع السريع مش رفاهية، هو أساس النجاح وتعبير عن احترامك لوقت المستخدم. يلا يا جماعة، خلينا نبني ويب أسرع للكل! 💪
