مقالات عملية مرتبة حسب المجال والمستوى، اختر المجال المناسب واقرأ من مستوى مبتدئ إلى محترف.
لو Lighthouse بيدّيك 96/100 لكن الزائر بيحس بتأخير ثانية في كل ضغطة زر، المشكلة مش في LCP. INP بيقيس أعلى زمن استجابة لكل تفاعل، وده اللي بيحدد إحساس الزائر بسرعة موقعك. مقال للمستوى المتوسط بمثال طاهي المطعم للمبتدئ، تعريف علمي لـ Long Tasks و Main Thread، 4 تكنيكات قابلة للنسخ (scheduler.yield, requestIdleCallback, Web Workers, debounce)، أرقام مقاسة من إنتاج (412ms → 96ms)، trade-offs الـ overhead، وحالات INP فيها مش أولوية.
لو الصفحة عندك فيها 80 كارد منتج ومدوّنة طويلة وأول رسم بياخد 4.2 ثانية، المتصفح بيرسم كل حاجة حتى اللي مش ظاهر. content-visibility: auto بسطر CSS واحد بيخلّيه يتجاهل العناصر اللي بره الـ viewport ويوفّر 73% من زمن الرسم. مقال للمستوى المتوسط بمثال صفحات الكتاب للمبتدئ، تعريف علمي لـ containment وlayout skipping من W3C CSS Containment Module Level 2، كود CSS شغّال على صفحة 80 كارد، أرقام مقاسة من Lighthouse 12، 4 trade-offs حقيقية، وحالات لا تستخدمها فيها.
لو endpoint عندك بياخد 240ms من الـ DB كل request، Stale-While-Revalidate بيخلّيه يرد في 12ms من الكاش ويحدّث في الخلفية بدون انتظار. شرح للمستوى المتوسط بمثال محل العصير، تعريف علمي دقيق لـ RFC 5861، إعداد NGINX و Cloudflare قابل للنسخ، أرقام مقاسة من إنتاج، trade-offs، وحالات لا تستخدمه فيها.
لو dashboard فيه تقرير aggregation على جدول 18 مليون صف بياخد 12 ثانية كل request، المشكلة مش الـ DB ولا الـ index. المشكلة إنك بتعيد حساب نفس النتيجة كل مرة. Materialized View بينزّل الزمن ده لـ 80ms بسطر CREATE واحد. مقال للمستوى المتوسط بمثال محل البقالة، تعريف علمي دقيق، كود SQL شغّال على PostgreSQL 16، أرقام مقاسة فعليًا، استراتيجية الـ refresh، trade-offs، وحالات لا تستخدمه فيها.
لو تطبيقك بيكتب 1000 مفتاح في Redis في loop وبياخد 4 ثواني، Redis مش بطيء — الـ latency بياكل الأداء بين كل أمر والتاني. Pipelining بينزّل الزمن ده لـ 80ms على نفس السيرفر بسطر واحد. مقال للمستوى المتوسط بمثال السوبر ماركت، تعريف علمي دقيق، كود Python شغّال على redis-py، أرقام مقاسة فعليًا، trade-offs، وحالات ما تستخدمهوش فيها.
لو endpoint عندك بيرد في 40ms على أول صفحة وبياخد 8 ثواني على الصفحة 10000، المشكلة مش الـ DB ولا الـ index. المشكلة إنك بتستخدم LIMIT OFFSET. مقال للمستوى المتوسط بمثال طابور المخبز، تعريف علمي دقيق لـ Keyset Pagination و B-tree seek، كود SQL وPython شغّال، أرقام مقاسة على PostgreSQL 16 لجدول 500K صف، trade-offs واضحة، وحالات لا تستخدمه فيها.
لو جدول الـ events عندك بقى 800 مليون صف وB-tree index على عمود created_at بياكل 2.4GB ولسه بياخد 9 ثواني في range query، المشكلة مش الـ I/O. المشكلة إنك بتدفع تكلفة index مش مناسب لطبيعة الداتا. BRIN index بيوفّر 99% من الحجم على نفس الجدول وبيخلي الاستعلام يتنفذ في 380ms — بشرط تفهم هو بيشتغل إزاي وإمتى لا يصلح.
لو جدول React بـ 10,000 صف بياخد 4 ثواني في أول رسم وكل scroll بيعلّق نص ثانية، المشكلة مش React. المشكلة إنك بترسم 60,000 عقدة DOM دفعة واحدة. List Virtualization بيخلي الـ DOM فيه 30 صف فقط ويحافظ على scrollbar صحيح. مقال للمستوى المتوسط بمثال السينما، تعريف علمي، كود react-window شغّال، أرقام قياس فعلية، trade-offs، وحالات لا تنفع فيها.
لو سيرفر Node.js بيقع OOM لما حد يرفع ملف 500MB والذاكرة بتطلع لـ 4GB، المشكلة مش الذاكرة ولا حجم الملف. المشكلة إن الكود بيتجاهل backpressure في الستريم. شرح للمستوى المتوسط بمثال المطبخ، تعريف علمي، كود pipe vs pipeline، أرقام قياس فعلية، trade-offs، وحالات لا تستخدم فيها.