دراسة حالة: متجر أزياء مثقل بالصور، أسرع 3.5x من الحافة

المشكلة: كل صورة منتج هي طلب

تجارة الأزياء الإلكترونية تعيش على التصوير. صفحة هذا المتجر الرئيسية وحدها تشير إلى أكثر من 130 صورة — شرائح عرض تتجاوز 300 KB، ولقطات منتجات بين نحو 50 و350 KB — وصفحات الفئات والمنتجات تكرّر النمط نفسه. بلا CDN، يسحب كل زائر كل واحد من تلك الملفات من الخادم الأصلي: الصور نفسها، آلاف المرات يوميًا، تتنافس على عمّال PHP وعرض النطاق أنفسهما اللذين يُفترض أن يخدما السلات وعمليات الدفع.

لم يكن الهدف غريبًا: إخراج ترافيك الصور المتكرر من الأصل كليًا، وإبقاء HTML طازجًا بما يكفي لمتجر، وفعل ذلك دون لمس قالب WordPress.

قاعدة الصور: كاش لسنة، وتقديم في أجزاء من الثانية

قلب الإعداد قاعدة توصيل واحدة تطابق امتدادات الصور (jpg وjpeg وpng وgif وwebp وsvg وico). تخزّن الاستجابات الناجحة في كاش الحافة لسنة كاملة، وتضيف ترويسة CORS كي يمكن تضمين الصور حيث يلزم، وتضغط ما يستفيد من الضغط بـBrotli وgzip.

تبدو السنة مبالغةً حتى تتذكر كيف تتغير صور المنتجات فعلًا: إنها لا تتغير. الصورة المرفوعة لمنتج تحتفظ برابطها حتى يموت المنتج؛ وإعادة التصميم ترفع ملفات جديدة بأسماء جديدة. تعني مدد الصلاحية (TTL) الطويلة أن الحافة لا تكاد تعاود سؤال الأصل أبدًا — في عيّنتنا، كانت كل صورة في الصفحة الرئيسية HIT بالفعل. وللحالة النادرة التي يجب فيها تغيير صورة في مكانها، يمسح تفريغ موجّه ذلك المُدخَل بعينه.

قاعدة HTML: يوم واحد، مع حيلة لترافيك الحملات

يعامَل HTML معاملة مختلفة: الصفحة الرئيسية مخزَّنة في الكاش ليوم واحد — مدة كافية لتمتص الحافة كل الترافيك المجهول تقريبًا، وقصيرة بما يكفي لتظهر تغييرات العرض التجاري في اليوم نفسه، ويتولى التفريغ أي أمر عاجل.

التفصيلة التي تستحق الاقتباس هي تطبيع الاستعلام. يصل ترافيك حملات الشبكات الاجتماعية بمعاملات تتبّع — كل نقرة فيسبوك تحمل fbclid فريدًا. لو خُزِّن بسذاجة، لكانت كل نقرة رابطًا "مختلفًا"، وكل زائر حملة MISS في الكاش، ولتحمّل الأصل كامل ذروة الإعلانات في أسوأ لحظة. تستبعد القاعدة fbclid من مفتاح الكاش، فتصبح عشرة آلاف نقرة حملة مُدخَل كاش واحدًا. ما يزال المعامل يصل إلى التحليلات؛ لكنه فقط يتوقف عن تفتيت الكاش.

ما الذي قسناه

أرقام من الموقع الحي، مقاسة عبر الإنترنت العام (أي أنها تتضمن مسافة شبكة حقيقية، لا ظروف مختبر). الصورة المخزَّنة في الكاش تجيب بزمن وصول أول بايت (TTFB) وسيطه نحو 0.15 ثانية. وإجبار الحافة على جلب الملف نفسه من الأصل يضع الوسيط عند نحو 0.54 ثانية — أي أبطأ بنحو 3.5 مرة. أما HTML الصفحة الرئيسية، المقدَّم كـHIT من الكاش مع ضغط Brotli، فيبدأ بالوصول في نحو 0.27 ثانية.

اضرب تلك الفجوة في أكثر من 130 صورة لكل عرض صفحة ولن يكون الأثر على السرعة المحسوسة خفيًا: يبدأ المتصفح برسم صور المنتجات بينما كان الإعداد غير المخزَّن سينتظر أولاها بعد. وكل HIT هو طلب لا يراه الأصل أبدًا — وأثناء ذروة حملة، تتقلص مهمة الأصل إلى خدمة السلات.

بقية المكدّس: Redis وWAF بلا جهد إضافي

قطعتان أخريان تعملان إلى جانب الكاش، وكلتاهما فُعِّلت تفعيلًا ولم تُبنَ بناءً. في طبقة الاستضافة، يدعم كاش كائنات Redis ووردبريس، محوّلًا استعلامات قاعدة البيانات المتكررة — الخيارات والقوائم وبيانات المنتجات الوصفية — إلى قراءات من الذاكرة للطلبات التي تصل فعلًا إلى PHP. وفي المقدمة، يفحص إعداد WAF المسبق للحساب الترافيك الوارد على الحافة نفسها التي تقدّم الكاش، فتُرشَّح أنماط الهجوم الشائعة قبل أن تصطف أصلًا في طابور الأصل.

هامش صدق: هذا العميل لا يستخدم تحسين الصور WebP/AVIF لدينا — الأرقام أعلاه كاش وضغط خالصان. ثمة هامش تحسين قابل للقياس متروك على الطاولة (الصيغ الحديثة تقلّص وزن الصور تقليصًا كبيرًا عادةً)، وهذا يجعل النتيجة أكثر قابلية للنقل لا أقل: هذا ما يفعله كاش الحافة وحده.

ما الذي تنسخه لمتجرك أنت

ينتقل النمط إلى أي موقع مثقل بالصور عبر أربع قواعد عملية. خزّن الصور حسب الامتداد بمدة صلاحية (TTL) طويلة وفرّغ عند التغيير، بدل مدد قصيرة "احتياطًا" — الاحتياط هو ما وُجد التفريغ لأجله. خزّن HTML لساعات أو ليوم، لا لصفر، ودَع تفريغًا وقت النشر يتولى الطزاجة. طبّع معاملات التتبّع (fbclid، وutm_* حيث تسمح التحليلات) خارج مفتاح الكاش قبل حملتك القادمة، لا بعد أن تُذيب الأصل. وتحقق بالقياسات لا بالانطباعات: أمر curl واحد بكاسر كاش مقابل آخر بدونه يخبرك بالضبط بما تساويه الحافة على صفحاتك أنت.