مقالات عملية مرتبة حسب المجال والمستوى، اختر المجال المناسب واقرأ من مستوى مبتدئ إلى محترف.
لو PostgreSQL بتاعك بياكل 8GB RAM مع 200 connection فقط، المشكلة مش في حجم البيانات. كل connection بيفتح process كامل بيستهلك 10MB ذاكرة. pgbouncer بيخدم 1000 client متزامن بـ 50MB ذاكرة بدلاً من 10GB. مقال للمتوسط بمثال موظف البنك للمبتدئ، تعريف علمي لـ process-per-connection model من توثيق PostgreSQL، إعداد pgbouncer 1.22 شغّال، أرقام مقاسة على PostgreSQL 16، 4 trade-offs حقيقية، ومتى لا تستخدمه أصلاً.
صورة LCP candidate لو ما اتحطّش عليها fetchpriority=high بتنزل في الموجة الثانية مع باقي الصور غير المهمة. سطر HTML واحد بيخلّي LCP ينزل من 2.4 ثانية لـ 1.6 ثانية. مقال للمتوسط بمثال طابور الكاشير، تعريف علمي من HTML Living Standard، كود img و link rel=preload شغّال، أرقام مقاسة من Etsy وShopify، 4 trade-offs حقيقية، وحالات لا تستخدم فيها.
لو الـ login endpoint بيستقبل آلاف المحاولات بأسماء غير موجودة، انت بتحرق DB في حسابات بترجّع صفر. Bloom Filter في 50 سطر Python بيرفض المحاولات دي قبل ما توصل لـ DB، بـ 16KB ذاكرة لـ 100 ألف مستخدم. مقال للمتوسط بمثال بوّاب الفندق للمبتدئ، تعريف علمي من ورقة Bloom 1970، كود pybloom-live + Redis شغّال، أرقام مقاسة (P99 من 38ms لـ 22ms، CPU من 71% لـ 9%)، 4 trade-offs، ومتى لا تستخدمه أصلاً.
دليل عملي للمستوى المتوسط لتفعيل HTTP/3 و QUIC على NGINX 1.25 وقطع زمن التحميل بنسبة 35% على شبكات 4G ضعيفة. شرح Head-of-Line Blocking بمثال طابور الكاشير، تعريف علمي من RFC 9000 و RFC 9114، 6 خطوات قابلة للنسخ مع كود NGINX و sysctl، أرقام مقاسة من Cloudflare على 25 مليون طلب يومي، 4 trade-offs حقيقية، وحالات لا تستخدم HTTP/3 فيها مع المصادر الرسمية.
لو الـ endpoint عندك بيرجّع 200 منتج ووقت الاستجابة 4.2 ثانية مع إن الـ DB قوية، المشكلة مش في السيرفر. الـ ORM بيعمل query واحد للقائمة وبعدين 200 query تاني لجلب التصنيف لكل منتج. مقال للمستوى المتوسط بمثال محل البيتزا للمبتدئ، تعريف علمي دقيق، كود Django ORM شغّال، أرقام مقاسة من إنتاج، الفرق بين select_related و prefetch_related، trade-offs الـ JOIN، ومتى ما تركّزش على المشكلة دي.
لو 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، وحالات لا تستخدمه فيها.