ليه موقعك بطيء (و 7 حلول حقيقيه بتشتغل)

لو سبق وقعدت تبص في علامة التحميل الدوارة على موقعك وفي بالك سؤال "ليه موقعي بيحمّل ببطء؟"، اطمن، إنت مش لوحدك، وأنا متأكد إنك مش بتواجه مشكلة غامضة. بعد ما سلّمت أكتر من 25 مشروع إنتاج في مصر والسعودية والإمارات وبريطانيا وسويسرا وفرنسا وألمانيا والكويت خلال الخمس سنين اللي فاتت، أقدر أقولك إن السبب نادراً ما بيكون "محتاجين نعيد بناء كل الـ stack". في الغالب بيكون واحدة من سبع مشاكل محددة، وكل واحدة فيهم ليها حل مستهدف وقابل للقياس. الدليل ده هو نفس البلاي بوك التشخيصي اللي بستخدمه لما عميل يبعتلي إيميل الساعة 2 الفجر يقولي إن معدل التحويل عنده انهار فجأة.

إيه يعني "بطيء" فعلياً: شرح Core Web Vitals

قبل ما تقدر تصلّح أي حاجة، لازم يكون عندك قاموس مشترك. كلمة "بطيء" دي إحساس، أما Core Web Vitals فهي أرقام. جوجل دلوقتي بترتّب الصفحات جزئياً بناءً على ثلاث مقاييس محددة، ومستخدمك بيحس بكل واحد فيهم بشكل مختلف.

Largest Contentful Paint (LCP)

الـ LCP بيقيس وقت اكتمال ظهور أكبر عنصر مرئي على الصفحة، وعادةً بيكون صورة الهيرو أو عنوان كبير أو بوستر فيديو. جوجل بتعتبر أقل من 2.5 ثانية "ممتاز"، ومن 2.5 لـ 4 ثواني "محتاج تحسين"، وأكتر من 4 ثواني "ضعيف". لما تسأل "ليه موقعي بيحمّل ببطء؟"، الـ LCP هو الرقم الوحيد اللي بيجاوب على السؤال ده في أغلب الحالات. قلّل وقت الـ LCP وهتلاقي السرعة المُدرَكة طارت لفوق فوراً، حتى لو ما اتغيرش حاجة تانية.

Interaction to Next Paint (INP)

الـ INP حلّ محل الـ First Input Delay في مارس 2024. بيقيس زمن التأخير بين تفاعل المستخدم (نقرة، كبسة، ضغطة زرار) وأول تحديث بصري بعدها. أقل من 200ms ممتاز، وأكتر من 500ms ضعيف. المقياس ده بيعاقب الـ JavaScript الثقيل اللي بيشتغل على الـ main thread، يعني نفس النوع من الكود اللي بيتحمّل تمام لكن بيحس المستخدم إن الصفحة "بتلج".

Cumulative Layout Shift (CLS)

الـ CLS بيقيس قد إيه تخطيط صفحتك بينطّ ويتحرك أثناء التحميل. نتيجة أقل من 0.1 ممتازة، وفوق 0.25 ضعيفة. كل مرة زرار بيتحرك والمستخدم مادّ إيده يدوس عليه، ميزانية الـ CLS عندك بتقل وثقة المستخدم بتتبخر.

الثلاث مقاييس دول مع بعض، LCP وINP وCLS، بيشكّلوا حدود Core Web Vitals اللي بتظهر في Google Search Console وPageSpeed Insights وChrome User Experience Report. دول الأساس اللي عليه أي نقاش جاد عن سرعة المواقع.

إزاي جوجل بتقيس سرعة الصفحة وليه بيأثر على الترتيب

جوجل بتستخدم مصدرين بيانات لتقييم موقعك. الأول هو Chrome User Experience Report (CrUX)، وده بيانات ميدانية حقيقية ومجهولة من مستخدمين Chrome فعليين. التاني هو Lighthouse، وده اختبار معملي اصطناعي بيحاكي موبايل أندرويد متوسط على اتصال 4G مخفّض. البيانات الميدانية بتحرّك الترتيب، والبيانات المعملية بتحرّك التشخيص.

تجربة الصفحة كانت عامل ترتيب مؤكد من 2021، والـ Core Web Vitals هي أقوى إشارة في السلة دي. مش أكبر عامل ترتيب، لأن جودة المحتوى لسه بتفوز، لكنها عامل ترجيح بيشتغل على كامل الفهرس. لما صفحتين يبقى عندهم جودة محتوى وسلطة متقاربة، الصفحة الأسرع بتكسب على الموبايل. شفت السيناريو ده بيتكرر في عشرات لوحات تحليل العملاء.

التعامل مع Core Web Vitals كأنها "تحسين SEO" بيضيّع جوهر الموضوع. المواقع البطيئة بتفقد المستخدمين قبل ما ترتيب البحث يدخل من أساسه. معدل الارتداد على صفحة LCP 4 ثواني تقريباً ضعف معدل الارتداد على صفحة LCP 1.5 ثانية. الـ SEO تأثير ثانوي، أما الإيرادات فأثر أساسي.

إزاي تشخّص سرعة الموقع: ورك فلو الـ 5 دقايق

دي الخطوات اللي بشتغلها بالظبط قبل ما أعرض أي مشروع تحسين أداء. دي قائمة المراجعة لتحسين سرعة المواقع اللي بفتحها في تاب جديد على أول مكالمة مع عميل جديد.

1. شغّل PageSpeed Insights على الصفحة الرئيسية وعلى ثلاث صفحات داخلية عليها زيارات عالية. سجّل نتائج الموبايل والديسكتوب.
2. افتح الصفحة في Chrome وشغّل DevTools. اتنقل لتاب Network، حدد throttling على "Fast 3G"، عطّل الـ cache، وأعد التحميل.
3. رتّب طلبات الشبكة حسب الحجم. أي حاجة فوق 200KB بتتعلّم. وأي حاجة فوق 1MB بتاخد دائرة حمرا.
4. رتّب حسب الوقت. دوّر على الطلبات اللي بتاخد أكتر من 500ms. دول المشتبه بهم في بطء السيرفر أو بطء الـ third-party.
5. اتنقل لتاب Performance وسجّل بروفايل لمدة 6 ثواني. بُص على track الـ "Long Tasks"، أي حاجة فوق 50ms معناها إنها بتعطّل الـ main thread.
6. شغّل Lighthouse audit في وضع incognito (الإضافات بتشوّش على النتائج بشكل كبير).
7. راجع باستخدام WebPageTest على جهاز حقيقي من جغرافيا جمهورك. PageSpeed Insights بتختبر من سيرفرات أمريكا، ولو جمهورك في القاهرة، ده فرق مهم.

دي مرحلة التشخيص بالكامل. بتاخد حوالي ساعة في المرة الأولى، وخمستاشر دقيقة بعد ما تعملها عشر مرات. خلينا دلوقتي نفصّل السبع أسباب، إيه اللي بيخليهم يحصلوا، وإزاي تصلّحهم بالضبط.

السبب الأول: صور غير محسّنة ومشكلة الـ LCP

بترفع صورة هيرو 5MB من موبايلك على طول، والمتصفح بينزّلها على اتصال 4G في الرياض، والـ LCP عندك بيوصل لـ 6 ثواني. ده أكتر سبب شائع لبطء المواقع بقابله. كل. مشروع. على حدة.

الصور بتمثل من 40 لـ 60% من وزن صفحة الويب المتوسطة. لو غلطت فيها، أي حاجة تانية هتعملها مش هتفرق. ولو ضبطتها، يبقى كسبت نص معركة الأداء على طول.

الأربع خطايا في الصور

• الصيغة الغلط. تقديم JPEG بينما WebP كان هيبقى أصغر بـ 30%، أو PNG بينما SVG كان هيبقى أصغر بـ 99%.
• الأبعاد الغلط. عرض thumbnail بمقاس 400x300 بصورة مصدرها 4000x3000.
• استراتيجية تحميل غلط. تحميل eager لـ 40 صورة منتج بينما 4 بس فوق الـ fold.
• ضغط غلط. JPEGs بجودة 100 بينما جودة 80 بتبان نفس الشكل بصرياً وأخف بـ 60%.

بلاي بوك إصلاح الصور: WebP وAVIF وsrcset وsizes وlazy loading

ده هو تحسين الصور لأداء الويب في أبسط شكل قابل للتطبيق. طبّق الخمس تقنيات دول وشوف الـ LCP بينزل بنسبة 50 لـ 70%.

الأول، حوّل لصيغ حديثة. الـ AVIF تقريباً أصغر بـ 50% من JPEG عند نفس الجودة، ومدعوم دلوقتي في أكتر من 95% من المتصفحات. الـ WebP بقى الـ fallback عندك للـ long tail. استخدم عنصر picture مع مصادر متعددة عشان كل متصفح ياخد أحسن صيغة يقدر يفك تشفيرها.

<picture>
  <source srcset="/img/hero.avif" type="image/avif">
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg"
       width="1600" height="900"
       alt="Cairo skyline at dusk"
       loading="eager"
       fetchpriority="high">
</picture>

لاحظ ثلاث تفاصيل صغيرة لكن قوية. السمات width وheight بتحجز المساحة وبتشيل أي layout shift. تلميح fetchpriority بيقول للمتصفح إن الصورة دي حرجة، فمرشّح الـ LCP بياخد الشبكة الأول. وloading="eager" بيلغي أي lazy-loading افتراضي على الصورة اللي فوق الـ fold. تحميل LCP image بشكل lazy من أكتر الأخطاء اللي بشوفها، وبيكلّفك ثانية كاملة.

تاني حاجة، استخدم srcset وsizes عشان كل جهاز ينزّل بس اللي يقدر يعرضه:

<img src="/img/hero-800.jpg"
     srcset="/img/hero-400.jpg 400w,
             /img/hero-800.jpg 800w,
             /img/hero-1600.jpg 1600w"
     sizes="(max-width: 600px) 100vw, 50vw"
     alt="...">

ثالث حاجة، حمّل كل حاجة تحت الـ fold بشكل lazy باستخدام loading="lazy" الأصلية. مش محتاج أي مكتبة JavaScript. رابع حاجة، استخدم خط أنابيب صور وقت البناء، يا zd sharp في Node، أو مكتبة Spatie للصور في Laravel، أو خدمات زي Cloudinary وImageKit، عشان تولّد كل الـ variants بشكل تلقائي. خامس حاجة، حدد width وheight صريحين على كل عنصر صورة. دايماً. ده أرخص مكسب لـ CLS في بلاي بوك الأداء كله.

السبب التاني: JavaScript معطّل للعرض وسكريبتات third-party

كل script tag في الـ head من غير defer أو async بيعطّل تحليل HTML. المتصفح بيقف، بينزّل السكريبت، بينفّذه، وبعدها بس بيكمّل بناء الـ DOM. لو عندك خمس سكريبتات معطلة للعرض في الـ head، يبقى ضمنت صفحة بطيئة.

الخطية الأكبر هي سكريبتات الـ third-party. ودجت الشات "الغير ضار" اللي أضفته من سنتين ونسيته؟ ده بيحمّل 800KB من JavaScript، بيفتح websocket، وبيضيف 600ms لوقت التفاعل. بيكسلات التسويق، منصات A/B testing، أدوات تسجيل الجلسات، الإمبدز الاجتماعية، كلها بتتراكم بهدوء وبتدمّر أداءك.

بلاي بوك إصلاح الـ JavaScript: defer وasync وcode splitting وتدقيق السكريبتات

إصلاح JavaScript المعطّل للعرض مباشر لما تفهم سمات التحميل التلاتة.

• defer — بينزّل السكريبت بالتوازي مع التحليل، وبينفّذه بعد ما الـ DOM يتحلّل بالكامل. استخدمها لأي حاجة تقريباً.
• async — بينزّل بالتوازي، وبينفّذ بمجرد ما يوصل (وبيقاطع التحليل). استخدمها للسكريبتات المستقلة زي analytics اللي مش بتلمس الـ DOM.
• type="module" — defer بشكل افتراضي، وبيدعم ES modules أصلياً. ده الافتراضي الحديث.

لكود تطبيقك الخاص، احتضن code splitting. الفريموركس الحديثة بتسهّل ده. في React، dynamic imports بتديك تقسيم على مستوى الـ route:

// Before: one giant bundle
import Dashboard from './Dashboard';

// After: split chunks loaded on demand
const Dashboard = lazy(() => import('./Dashboard'));

<Suspense fallback={<Spinner />}>
  <Dashboard />
</Suspense>

بالنسبة لسكريبتات الـ third-party، دقّق بلا رحمة. افتح تاب Coverage في Chrome DevTools وبُص على عمود "Unused Bytes". أي حاجة أعلى من 50% غير مستخدمة دي مرشّح للحذف أو التأجيل أو الاستبدال ببديل أخف. عندي قائمة سوداء شخصية لسكريبتات برفض أضيفها لأي موقع عميل من غير مبرر تجاري واضح.

بالنسبة لـ tag managers، استخدم server-side tagging قد ما تقدر. الـ server-side container بتاع Google Tag Manager بينقل عبء التتبع من جهاز المستخدم. لـ chat widgets، حمّلها على تفاعل المستخدم (mousemove أو scroll أو بعد 5 ثواني timeout) بدل التحميل الفوري. Intercom وDrift الاتنين بيدعموا الـ delayed initialization، وأغلب العملاء عمرهم ما قروا الصفحة دي من توثيقهم.

السبب التالت: طلبات HTTP كتير جداً وانتفاخ الـ bundle

الـ HTTP/2 multiplexing خلّت إنجيل "طلبات أقل" مش حرج زي 2015، لكن 300 طلب لسه بيوجع. كل واحد محتاج DNS وTLS وheaders ووقت تحليل. والأهم، عدد الطلبات عادة عَرَض من أعراض إهمال الـ bundling، اللي بدوره مرتبط بانتفاخ الـ bundle.

دققت على مواقع Next.js بتشحن 2MB من JavaScript على الصفحة الرئيسية لأنهم استدعوا مكتبات Lodash وMoment وMaterial UI بالكامل وهم بيستخدموا تلات functions من كل واحدة. الـ Tree-shaking موجودة لسبب. استخدمها.

استراتيجيات الـ bundling مع Vite وWebpack وesbuild

Vite هو افتراضي للمشاريع الجديدة في 2026. بيستخدم esbuild للتطوير (hot reload أقل من 100ms) وRollup للإنتاج (tree-shaking ممتاز، code splitting ذكي). Webpack لسه كويس للمشاريع القديمة لكن تكوينه معروف بصعوبته، ولو بتهاجر، esbuild وVite الاتنين أسرع بـ 10 لـ 100 مرة.

ثلاث قواعد للـ bundling بتجيب نتيجة باستمرار:

1. حدد limits صريحة لحجم الـ chunk في تكوين البناء وخلي الـ CI تفشل لو أي chunk تجاوزها.
2. استخدم bundle analyzers (rollup-plugin-visualizer، webpack-bundle-analyzer) بعد كل تغيير في الـ dependencies. dependency جديد ضاف 200KB؟ دوّر على بديل أخف.
3. فضّل تقسيم لكل route على تقسيم لكل component لحد ما الـ profiling يثبت العكس. الـ chunks الصغيرة عندها overhead برضو.

الـ Critical CSS تستحق فقرة لوحدها. استخرج الستايلات اللازمة لعرض المحتوى فوق الـ fold، خليها inline في الـ head، وحمّل الباقي async. أدوات زي Critters (المستخدمة في Next.js) وCritical (لوحدها) بتأتمت ده. لو عملته صح، أول paint بيحصل قبل ما ملف الـ CSS الأساسي حتى يوصل.

السبب الرابع: استجابة سيرفر بطيئة (TTFB) واختناقات الـ backend

لو الـ TTFB (Time to First Byte) عندك فوق 200ms، السيرفر هو الاختناق، مش المتصفح. مفيش أي قدر من تحسين الـ frontend هينفع. المتصفح مستني السيرفر، وكل اللي وراه في طابور بيستنى نفس الانتظار. إصلاح TTFB البطيء عادة أعلى نقطة فعّالة في شغل الأداء.

المتسببين الشائعين في الـ backend اللي شحنت لهم إصلاحات فعلاً:

• استضافة مشتركة مع جيران شغّالين، أوقات استجابة مفاجئة بثانيتين في ساعات الذروة.
• غياب فهارس قاعدة البيانات على مسارات الاستعلامات الساخنة.
• أنماط N+1 query في Eloquent أو Active Record أو Prisma.
• استدعاءات متزامنة لـ APIs خارجية في دورة الطلب.
• غياب object cache (كل طلب بيضرب قاعدة البيانات لبيانات بتتغير كل ساعة).
• دوال serverless باردة على AWS Lambda من غير provisioned concurrency.
• SSL handshake في كل طلب لأن keep-alive معطّل.

مقارنة فئات الاستضافة: مشتركة مقابل VPS مقابل مُدارة مقابل edge

اختيار الاستضافة ليه تأثير أكبر على الأداء من اللي بيعترفوا بيه معظم المطورين. نقلت مواقع عملاء من استضافة مشتركة بـ 5 دولار في الشهر لاستضافة مُدارة بـ 40 دولار في الشهر وشفت الـ TTFB بينزل من 1200ms لـ 180ms من غير أي تغيير في الكود.

• استضافة مشتركة (3 لـ 15 دولار في الشهر): مقبولة لمدونات شخصية بأقل من 1000 زائر يومي. أكتر من كده، مشكلة الجيران الشغّالين بتبقى ما تتحملش.
• VPS (20 لـ 100 دولار في الشهر): موارد مخصصة، تحكم كامل، لكنك بقيت إنت الـ sysadmin. ممتاز لو عارف Linux، موجع لو ما تعرفش.
• استضافة مُدارة (30 لـ 200 دولار في الشهر): Hostinger وKinsta وWP Engine وForge مع DigitalOcean. النقطة المثالية لأغلب مواقع الإنتاج، ضبط الأداء والأمان والنسخ الاحتياطية متعملّك.
• منصات edge (0 لـ 500 دولار في الشهر): Vercel وCloudflare Workers وNetlify. ممتازة لمواقع ثقيلة بمحتوى static وجمهور عالمي. التكاليف ممكن تنفجر لأحمال شغل ديناميكية.

لو لسه بتتعارك مع القرار ده، تحليلي العميق عن اختيار استضافة الويب في 2026 بيفصّل المقايضات بأرقام benchmark حقيقية من مواقع بشغّلها.

تحسين قاعدة البيانات: الفهارس واستعلامات N+1 وتخزين الاستعلامات

قاعدة البيانات عادةً أبطأ حاجة في دورة الطلب عندك. استعلام بياخد 800ms في الإنتاج هو الفرق بين موقع سريع وموقع بطيء. ثلاث فحوصات بشغّلها على كل مشروع Laravel وNode:

الأول، فعّل تسجيل الاستعلامات البطيئة. في MySQL، حدد long_query_time لـ 0.1 وبص اللي طالع. هتفجع.

تاني حاجة، نصّب Laravel Debugbar (أو ما يكافئها في الـ stack بتاعك) في الـ staging وبص على عدد الاستعلامات في كل طلب. أي حاجة فوق 30 استعلام على صفحة واحدة دي علامة حمرا. أكتر من 100 دي طوارئ، بنسبة شبه أكيدة مشكلة N+1.

// N+1 disaster: 1 query for posts + 1 query per post for the author
$posts = Post::all();
foreach ($posts as $post) {
    echo $post->author->name; // BOOM, hidden query
}

// Eager loading: 2 queries total, regardless of post count
$posts = Post::with('author')->get();
foreach ($posts as $post) {
    echo $post->author->name; // already loaded
}

تالت حاجة، ضيف فهارس على كل عمود بتعمل عليه استعلام أو ترتيب أو join. أكتر فهرس ناقص ببقا لاقيه هو foreign key من غير فهرس خاص بيه، كتير من الـ ORMs ما بتعملهومش بشكل تلقائي.

-- Check existing indexes
SHOW INDEX FROM orders;

-- Add a composite index for a common query pattern
CREATE INDEX idx_orders_user_status_created
ON orders (user_id, status, created_at DESC);

لمعلومات أكتر عن قرارات الـ schema اللي بتعوّض على المدى الطويل، شوف دليلي عن تصميم قواعد البيانات لتطبيقات الويب.

السبب الخامس: غياب طبقات الـ caching (المتصفح، CDN، object، page)

لو كل طلب بيضرب قاعدة بياناتك، إنت بتسيب 90% من أداءك على الترابيزة. الـ caching هو أعلى استثمار فعّال في الأداء في كل الـ stack. في أربع طبقات، والمواقع الجادة بتستخدم كلهم.

1. Browser cache. حدد headers الـ Cache-Control عشان الزوار الراجعين ياخدوا تجربة شبه فورية.
2. CDN edge cache. Cloudflare وBunny وFastly أو CloudFront بيقدّموا الـ assets من مركز بيانات قريب من المستخدم. وقت الذهاب والعودة بينزل من 200ms لـ 20ms.
3. Object cache. Redis أو Memcached بيخزّن نتائج الاستعلامات اللي بتتطلب كتير في الذاكرة. استعلام قاعدة بيانات 200ms بيبقى cache hit 1ms.
4. Page cache. ردود HTML كاملة متخزنة ومتقدمة من غير ما تلمس PHP أو Node أو قاعدة بياناتك. لصفحات شبه static، ده الفرق بين 800ms و30ms TTFB.

headers الـ Cache-Control واستراتيجيات الـ assets الـ immutable

استراتيجية الـ cache من طبقتين بسيطة جداً وفعّالة بشكل صادم:

# nginx config for hashed asset files (1 year, immutable)
location ~* \.(?:js|css|woff2|webp|avif)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

# HTML pages - short cache with revalidation
location ~* \.html$ {
    add_header Cache-Control "public, max-age=300, must-revalidate";
}

توجيه "immutable" بيقول للمتصفح إن الملف ده مش هيتغير أبداً، وهو فعلاً مش هيتغير، لأن خط أنابيب البناء عندك بيضمّن content hashes في أسماء الملفات (app.a4b8c2.js). لما تشحن نسخة جديدة، اسم الملف بيتغير، والـ cache entry القديم بيبقى ببساطة غير ذي صلة. مفيش مشكلة cache invalidation لأن الـ URL نفسه هو النسخة.

للصفحات الديناميكية، استخدم Redis object cache. الـ cache helper الجاهز في Laravel بيخلي ده تافه، ومجرد التحويل من driver الـ file لـ driver الـ Redis لوحده بينزّل أوقات الاستجابة 10 أضعاف على أحمال الشغل النموذجية.

// Cache an expensive query for 1 hour
$products = Cache::remember('featured.products', 3600, function () {
    return Product::with('images', 'reviews')
        ->where('featured', true)
        ->orderBy('sales_count', 'desc')
        ->limit(12)
        ->get();
});

السبب السادس: خطوط الويب بتتعمل غلط (وإزاي تصلّحها)

خطوط الويب من أكتر ميزات CSS الحديثة اللي بيتم إساءة استخدامها. ست أوزان من عيلتين خطوط بيساوي تقريباً 600KB من الخطوط في أول تحميل. لصفحة المفروض وزنها 500KB إجمالاً. المستخدم بيقضي ثانيتين بيتفرج على صفحة فاضية أو تبديل خطوط.

الإصلاح من خمس أجزاء:

1. استضف خطوطك ذاتياً. أسطورة "Google Fonts هي CDN مجانية" ماتت مع HTTP/3، المتصفحات الحديثة ما بتشاركش الـ cache عبر الأصول أصلاً. الاستضافة الذاتية بتشيل DNS lookup وTLS handshake.
2. استخدم WOFF2 بس. 99% من المتصفحات بتدعمها. الصيغ التانية وزن ميت.
3. اعمل subset بشكل جريء. لو موقعك إنجليزي بس، شيل glyphs السيريلية والفيتنامية. أدوات زي glyphhanger أو fontTools بتقطع حجم الخط بـ 60 لـ 80%.
4. استخدم font-display: swap (أو optional). اعرض نص fallback فوراً، وبدّل بالخط الحقيقي لما يوصل. للخطوط الغير حرجة، استخدم optional عشان التبديل يحصل بس لو الخط حمّل بسرعة.
5. اعمل preload للخطوط الحرجة. قول للمتصفح يبدأ تحميل الخط المعطّل للـ LCP بالتوازي مع HTML.

<link rel="preload"
      href="/fonts/inter-var.woff2"
      as="font"
      type="font/woff2"
      crossorigin>

الخطوط المتغيرة (زي Inter Variable) تستاهل ذكر خاص. ملف واحد فيه كل وزن من 100 لـ 900. بتشحن 80KB بدل 600KB. لو نظام التصميم عندك بيستخدم أكتر من وزنين، حوّل لخط متغير ومتلتفتش وراك.

السبب السابع: تحرك تخطيطي تراكمي من الصور والإعلانات وتبديل الخطوط

الـ CLS هو المقياس اللي بيخلي المستخدمين يكرهوا موقعك حتى لو بيحمّل بسرعة. بيدوسوا على زرار، الصفحة بتنطّ، بيدوسوا على حاجة غلط. ارتداد. أكبر تلات مسببين للـ CLS:

• صور من غير أبعاد. المتصفح مش عارف يحجز قد إيه مساحة، فالتخطيط بيتحرك لما الصورة تتحمّل. الحل: حدد دايماً سمات width وheight.
• إعلانات بتتحقن بعد تحميل الصفحة. احجز مساحة بحاوية ليها min-height عشان موضع الإعلان يكون ليه أبعاد حتى لو فاضي.
• تبديل خط من fallback لخط ويب. لو المقاييس مختلفة بشكل كبير، النص بيعيد التدفق. الحل: استخدم descriptors size-adjust وascent-override وdescent-override لمطابقة المقاييس، أو استخدم font-display: optional.

مكاسب سرعة لكل فريموورك: Laravel وNext.js وWordPress وShopify

المبادئ العامة فوق بتنطبق في كل مكان، لكن كل فريموورك ليه مزالقه واختصاراته الخاصة في السرعة.

Laravel

اعمل cache للـ config والـ routes والـ views في الإنتاج باستخدام أوامر artisan. استخدم Octane (Swoole أو RoadRunner) عشان تخلي الفريموورك مفعّل بين الطلبات، TTFB بينزل 5 لـ 10 أضعاف. فعّل Redis للـ cache والـ sessions والـ queues. استخدم Laravel Horizon لمراقبة إنتاجية الطابور. لو بتبني SaaS، شرحي عن إزاي تبني SaaS MVP بـ Laravel وReact بيغطي افتراضيات الأداء اللي بشحنها افتراضياً.

Next.js

استخدم App Router مع React Server Components، بيشحنوا صفر JavaScript للأجزاء الـ static من الصفحة. استخدم next/image للتحويل التلقائي للصيغ وتوليد srcset. استخدم ISR (Incremental Static Regeneration) للمحتوى اللي بيتحدث كذا مرة في الساعة. تحليلي العميق عن تحسين أداء Next.js بيمشي على كل flag وخيار تكوين.

WordPress

عشان تخلي موقع WordPress يحمّل أسرع: نصّب plugin caching كويس (WP Rocket أو LiteSpeed Cache أو W3 Total Cache)، دقّق على plugins (أغلب المواقع عندها 30+ بينما محتاجة 8)، استخدم theme حديث ما يحملش jQuery، وحط Cloudflare قدام كل حاجة. WordPress يقدر فعلاً يجيب 90+ على Lighthouse، عملتها عشرات المرات، لكن التثبيت الافتراضي هيجيب 30. مقارنة المنصات في WordPress مقابل Laravel بتغطي إمتى WordPress هو الاختيار الصح برغم الـ overhead.

Shopify

إنت معلّق بالمنصة، لكن لسه تقدر تكسب. استخدم Dawn أو theme خفيف تاني كقاعدة. دقّق على الـ apps بلا رحمة، كل app عادةً بيضيف من 50 لـ 200KB من JavaScript. استخدم section rendering API عشان تحمّل بس اللي محتاجه. حمّل الصور والفيديوهات اللي تحت الـ fold بشكل lazy. أجّل الـ apps الغير حرجة عشان تتحمّل بعد ما الصفحة تفاعلية.

أداء الموبايل مقابل الديسكتوب: ليه نتيجة موبايلك أقل

لو نتيجة Lighthouse ديسكتوب عندك 95 وموبايلك 52، إنت مش لوحدك. الموبايل أصعب لتلات أسباب هيكلية. الأول، الـ CPU في جهاز الأندرويد متوسط المدى المحاكى تقريباً أبطأ 4 مرات من اللاب توب بتاعك. JavaScript بيشتغل في 100ms على الديسكتوب بياخد 400ms على جهاز الاختبار. تاني حاجة، الشبكة مخفّضة لـ 4G مع latency 150ms. تالت حاجة، أجهزة الموبايل ليها RAM أقل، فالمتصفح بيبقى أكتر عدوانية في الـ garbage collection وطرد التابات.

المعنى: أداء mobile-first مش شعار، ده استراتيجية بقاء. لو موقعك بيحمّل ببطء على الموبايل، صلّح انتفاخ JavaScript الأول، الصور تاني، السيرفر تالت. اختبر على موبايل أندرويد حقيقي بـ 200 دولار، مش الـ iPhone بتاعك بـ 1500 دولار. التجربة مختلفة بطرق المحاكي بيغطيها جزئياً بس. لمبادئ تصميم موبايل أوسع، شوف دليلي عن تصميم الويب mobile-first في 2026.

دراسة حالة حقيقية: نقل موقع Laravel من 38 لـ 94 على Lighthouse

السنة اللي فاتت اشتغلت مع عميل تجارة إلكترونية سعودي واجهة Laravel + Vue بتاعته كانت بتجيب 38 على Lighthouse موبايل. معدل الارتداد كان 71%. معدل التحويل كان 0.6%. ده اللي عملناه في أسبوعين مركزين، مع تحسن نتيجة أداء Lighthouse بعد كل خطوة.

1. الأسبوع 1، يوم 1-2: تحسين الصور. هاجرنا 14 ألف صورة منتج لـ AVIF مع fallback لـ WebP، ولّدنا srcset variants بعرض 400/800/1200/1600، أضفنا أبعاد صريحة، حمّلنا اللي تحت الـ fold بشكل lazy. Lighthouse: 38 → 61. LCP: 5.8s → 2.9s.
2. اليوم 3: تدقيق سكريبتات third-party. شيلنا 9 سكريبتات تتبع مش مستخدمة، أجّلنا 4 تانية، نقلنا ودجت الشات لتحميل lazy على أول تفاعل. Lighthouse: 61 → 72. وقت الحجب الكلي قُطع بنسبة 60%.
3. اليوم 4: تجميع JavaScript. هاجرنا من Webpack لـ Vite، فعّلنا code splitting بناءً على الـ route، حوّلنا Moment.js لـ date-fns. JS bundle: 1.4MB → 380KB. Lighthouse: 72 → 79.
4. اليوم 5: وقت استجابة السيرفر. أضفنا Laravel Octane مع Swoole، نقلنا الـ cache من file لـ Redis، صلّحنا 3 N+1 queries على صفحة تفاصيل المنتج، أضفنا composite indexes على جدول الطلبات. TTFB: 920ms → 140ms. Lighthouse: 79 → 87.
5. الأسبوع 2: Caching والخطوط. أضفنا Cloudflare قدام كل حاجة مع page caching عدواني لصفحات المنتج، حوّلنا من 6 أوزان خط لخط متغير واحد، حدّدنا Cache-Control immutable على كل الـ assets المُجزّأة. Lighthouse: 87 → 94. CLS: 0.18 → 0.04.

الأرقام التجارية بعد شهرين: معدل الارتداد نزل من 71% لـ 44%. معدل التحويل طلع من 0.6% لـ 1.8%، تحسن 3 أضعاف على نفس كتالوج المنتجات بالظبط. شغل الأداء سدّد تكلفته في 11 يوم بناءً على الإيراد التزايدي وحده. ده اللي بقصده لما أقول إن السرعة feature إيرادية، مش رفاهية هندسية.

مقارنة أدوات تحسين السرعة (PageSpeed وGTmetrix وWebPageTest وCalibre)

كل أداة ليها شغلها. اختار المناسبة للسؤال اللي بتسأله.

• PageSpeed Insights: مجاني، سريع، بيستخدم بيانات معملية وميدانية. أول فحص افتراضي عندي. الأفضل لـ: الحصول على snapshot لـ Core Web Vitals وقائمة إصلاحات مرتبة.
• Chrome DevTools Lighthouse: نفس المحرك زي PageSpeed لكن بيشتغل محلياً. الأفضل لـ: التكرار على الإصلاحات من غير انتظار للـ API العام.
• WebPageTest: أعمق أداة مجانية. مواقع متعددة، متصفحات متعددة، عرض filmstrip، شلال الطلبات. الأفضل لـ: فهم بالضبط إيه اللي بيحصل بين الطلب والعرض.
• GTmetrix: واجهة ودودة، كويسة لأصحاب المصلحة اللي ما بيقروش DevTools. النسخة المجانية محدودة لكن مفيدة.
• Calibre / SpeedCurve / Treo: مراقبة مستمرة مدفوعة. الأفضل لـ: التقاط التراجعات في الإنتاج عبر أسابيع وشهور.
• Chrome User Experience Report (CrUX): البيانات الميدانية الفعلية اللي جوجل بتستخدمها للترتيب. متاحة عبر PageSpeed Insights وBigQuery. الأفضل لـ: حسم النقاشات حول هل نتائجك الاصطناعية بتطابق الواقع.

أخطاء شائعة بتخلي المواقع أبطأ، مش أسرع

حاجات شفتها بتغلط لما الفرق بتحاول تحسّن من غير خطة:

• إضافة CDN لكن نسيان تكوين headers الـ cache، كل طلب لسه بيضرب الأصل.
• تحميل الـ LCP image بشكل lazy (تراجع ضخم في الـ LCP).
• استبدال مكتبة ثقيلة واحدة بثلاث مكتبات أصغر مجموعهم وزنه أكتر.
• Code-splitting بشكل عدواني جداً لدرجة إن كل تنقل بيشغّل 8 طلبات شبكة.
• إضافة service workers من غير فهم cache invalidation، المستخدمين بيعلقوا على نسخ قديمة لأسابيع.
• التحويل من MySQL لـ PostgreSQL (أو العكس) أملاً إن ده هيحل مشكلة استعلام كان فهرس هيصلّحها.
• الهجرة لـ Next.js أو فريموورك تاني كاستراتيجية أداء. الفريموركس ما بتصلّحش قواعد بيانات بطيئة.

إمتى تستأجر استشاري أداء مقابل إصلاحات DIY

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

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

تكلفة المواقع البطيئة: التحويل ومعدل الارتداد وأثر SEO

الأرقام موثقة كويس عبر دراسات متعددة. تحسن ثانية واحدة في وقت التحميل عادةً بيدفع زيادة 7 لـ 15% في التحويلات. بحث جوجل لقى زيادة 32% في احتمالية الارتداد لما وقت تحميل الصفحة يطلع من 1 لـ 3 ثواني، وزيادة 90% من 1 لـ 5 ثواني. Amazon اشتهرت إنها حسبت 1.6 مليار دولار في الإيراد السنوي من تحسن ثانية واحدة.

لمشروعك، الحساب عادةً أبسط. لو موقعك بيعمل 100 ألف دولار في الشهر إيراد ودلوقتي بيحمّل في 4 ثواني، الوصول لـ 2 ثانية على الأرجح يساوي 10 لـ 15 ألف دولار في الشهر من المبيعات التزايدية. تكلفة تعاقد أداء مركز، حتى بأسعار الوكالات، بيرجع عوائده في أسابيع، مش شهور. للتجارة الإلكترونية تحديداً، شوف دليل تطوير مواقع التجارة الإلكترونية بتاعي للمعايير عن شكل المواقع السريعة في القطاع ده فعلياً.

أسئلة شائعة عن سرعة تحميل المواقع

إيه هي نتيجة Lighthouse الكويسة؟

الهدف 90+ لمواقع الإنتاج. 80-89 مقبول لكن لازم يتحسن. أقل من 80 معناه إنك بتسيب تحويلات على الترابيزة. لاحظ إن Lighthouse بيستخدم بيانات معملية اصطناعية، مستخدميك الحقيقيين ممكن تكون عندهم تجربة مختلفة. راجع مقابل البيانات الميدانية في PageSpeed Insights أو Google Search Console.

قد إيه بتاخد عشان أصلّح موقع بطيء؟

لموقع تجاري صغير لمتوسط نموذجي، الإصلاحات عالية التأثير (الصور، سكريبتات third-party، الـ caching الأساسي) بتاخد 1 لـ 3 أيام مركزة. الوصول من 80 لـ 95+ بياخد أسبوع كمان. شغل البنية التحتية العميق (قاعدة البيانات، هجرة الاستضافة، edge caching) ممكن ياخد من 2 لـ 4 أسابيع. مكاسب الـ 80/20 سريعة، آخر 10% هندسة حقيقية.

هل HTTPS بيبطئ موقعي؟

لا، العكس. HTTP/2 وHTTP/3 متاحين بس عبر TLS، والاتنين أسرع بشكل كبير من HTTP/1.1. الـ handshake بيضيف milliseconds قليلة، تحسينات البروتوكول بتوفر مئات. قدّم دايماً عبر HTTPS.

هل CDN لوحده هيخلي موقعي سريع؟

الـ CDN بيحل مشكلة "البعد عن السيرفر". لو مستخدميك في القاهرة وسيرفرك في فيرجينيا، CDN بيقطع حوالي 200ms من وقت الذهاب والعودة. لكن CDN ما بيصلّحش استعلامات قاعدة بيانات بطيئة أو JavaScript معطّل للعرض أو صور ضخمة. اربط CDN مع باقي البلاي بوك.

أحوّل فريموركس عشان أخلي موقعي أسرع؟

نادراً. اختيار الفريموورك يمثل يمكن 10 لـ 20% من الأداء المُدرَك. الـ 80% هي التنفيذ: الصور، السكريبتات، استجابة السيرفر، الـ caching. موقع WordPress مبني كويس بيتفوق على موقع Next.js مبني وحش في كل مرة. حوّل الفريموركس لأسباب إنتاجية، مش لأسباب أداء.

إزاي أحسّن نتيجة Core Web Vitals بسرعة؟

أسرع طريق: حسّن صورة LCP بتاعتك (صيغة صحيحة، أبعاد صحيحة، fetchpriority="high")، أجّل كل JavaScript غير حرج، وحدد width/height على كل صورة. الثلاث تغييرات دول لوحدهم عادةً بينقلوا كل الـ Core Web Vitals للأخضر لأغلب المواقع.

هل العرض من جانب السيرفر دايماً أسرع من العرض من جانب العميل؟

لأول paint، شبه دايماً أيوه، الـ SSR بيقدّم HTML المتصفح يقدر يعرضه فوراً. للتفاعلات اللاحقة، تطبيقات client-side مبنية كويس ممكن تحس أسرع لأنها بتتجنب إعادة تحميل الصفحة كاملة. الفريموركس الحديثة (Next.js، Remix، Nuxt) بتمزج الطريقتين وبتديك الأفضل من الاتنين.

قائمة الصيانة: حافظ على سرعة موقعك بعد الإطلاق

الأداء مش مشروع لمرة واحدة. المواقع بتبقى أبطأ مع الوقت لما features وسكريبتات ومحتوى جديد بيتراكموا. ابني الفحوصات دي في الـ workflow بتاعك:

• شغّل Lighthouse على أعلى 5 صفحات كل شهر. تتبّع الاتجاه، مش الرقم بس.
• اظبط مراقبة Core Web Vitals في Google Search Console. خد تنبيهات لما المقاييس تتدهور.
• دقّق على سكريبتات third-party كل ربع سنة. شيل أي حاجة مش بتحرّك قيمة تجارية فعلاً.
• شغّل bundle analyzer بعد كل تغيير في الـ dependencies. ارفض الـ PRs اللي بتضيف أكتر من 50KB لـ bundle حرج من غير مبرر.
• شوف بروفايل سجل الاستعلامات البطيئة لقاعدة البيانات شهرياً. Features جديدة بتضيف أنماط استعلام جديدة، بعضها محتاج فهارس جديدة.
• أعد الاختبار على أجهزة موبايل حقيقية بعد الإصدارات الكبيرة. المحاكيات بتكدب.
• راجع مقاييس الاستضافة كل ربع سنة. كبرت على فئتك؟ ارفع قبل ما المستخدمين يحسوا.

الخطوة الجاية

الأداء بيمس كل جزء من تطوير الويب الحديث. لو عايز تتعمّق أكتر في المواضيع المجاورة، دي الأدلة اللي بلاقي نفسي ببعتها للعملاء أكتر حاجة: progressive web apps في 2026 للسرعة القابلة للتثبيت، React مقابل Vue في 2026 لمقايضات الفريموركس، أفضل ممارسات تصميم API لأداء الـ backend، اتجاهات تطوير الويب 2026 للمشهد الأوسع، وكام تكلفة موقع في 2026 لو بتخطط لإعادة تصميم. تقدر كمان تشوف اللي بقدمه دلوقتي على صفحة الخدمات.

استأجرني عشان أخلي موقعك سريع

لو قريت لحد هنا وتفضّل حد تاني يعمل الشغل، ده بالضبط اللي بعمله. بشغّل تدقيقات أداء مركزة بتقدّم تقرير مكتوب بإصلاحات مرتبة خلال 48 ساعة، وبنفّذ الإصلاحات لو عايز تعاقد جاهز للتسليم. النتائج النموذجية: Lighthouse Performance من 40 لـ 95+، LCP من 5 ثواني لـ 1.5 ثانية، إجمالي وزن الصفحة من 4MB لـ 600KB، ورفع قابل للقياس في معدل التحويل خلال 30 يوم. بشتغل مع مؤسسين وفرق منتج في مصر والخليج وأوروبا، وبخلي قائمة عملائي صغيرة عشان كل تعاقد ياخد اهتمام كامل. تواصل عبر صفحة التواصل بتاعتي لاستشارة مجانية مدتها 30 دقيقة، احضر أبطأ URL عندك وهنمشي على التشخيص مع بعض. مفيش سكريبت مبيعات، مفيش التزام، بس تقييم صادق لإيه اللي بيخلي موقعك بطيء وإيه اللي محتاج عشان يتصلّح.