الفيديو للويب: الحجم والسرعة والقرار الذي يسبقهما
الفيديو أثقل ما يمكن وضعه في صفحة، فالقرار الأول ليس الضغط بل هل تحتاج هذه الصفحة إلى فيديو أصلا. وإن كانت تحتاج فهناك أربع روافع حقيقية: ترميز صحيح، ومطابقة الدقة لحجم العرض، واستعمال ملصق بدل التحميل المسبق للملف، واستضافة الملف في مكان غير الخادم الذي يقدم HTML.
- الدرس 7 من 10
- متوسط
- مجاني، دون تسجيل
الروافع الأربع التي تخرج الفيديو من مسار التحميل
درجة الأداء في لايت هاوس من ٠ إلى ١٠٠، ونطاقها الأخضر يبدأ من ٩٠.
- ترميز صحيحلا خاصية على الوسم تعوض ملفا رمز بسوء.
- دقة بمقاس الإطارملف بـ1080 بكسل في إطار عرضه 360 بكسل على الهاتف بايتات مرمية.
- ملصق بدل التحميل المسبقالملصق نفسه مرشح LCP، فيجب أن يكون مضغوطا.
- استضافة بعيدا عن HTMLالفيديو الطويل على استضافة مشتركة هو حيث ينكسر القرار.
درجة لايت هاوس قياس مخبري ولا سلوك مستخدم فيها. الصفحة التي لا ينقر فيديوها أبدا تحصد درجة جيدة ولا تقول شيئا عن تجربة من ينقر.
آخر مراجعة: تُراجع الحقائق وأسماء الأدوات في هذا الدرس مقابل مصادرها في هذا التاريخ.
هل تحتاج هذه الصفحة إلى فيديو أصلا؟
موقفنا: أكثر صفحات الأعمال ينبغي ألا تشغل فيديو تلقائيا، وكثير منها ينبغي ألا يحمل فيديو أصلا.
هذا كلام يأتي من وكالة تصنع الفيديو وتبيعه، وهذا بالضبط ما يجعله جديرا بالثقة. الصفحة التي فيها فيديو خلفية قد سحبت ميغابايتات وشغلت معالج الزائر بفك الإطارات قبل أن يقرأ كلمة واحدة. فإن كان ذلك الفيديو يقول ما لا يقوله النص والصورة فالكلفة صحيحة. وإن كان أجواء فلا.
ثلاثة أسئلة، بهذا الترتيب، تحسم الأمر. أولا، ماذا يظهر هذا الفيديو مما لا تظهره صورة ثابتة وجملتان؛ فإن كان الجواب الحركة، كعرض منتج أو عملية، فالفيديو صحيح. ثانيا، أيريده الزائر أم نريده نحن؛ فمن جاء ليرى الأسعار لا يريد فيلم التعريف بالشركة. ثالثا، ماذا يضيع إن لم يشتغل أبدا؛ فإن كان الجواب لا شيء فالفيديو زينة.
على هذا الموقع أوصلتنا هذه الأسئلة الثلاثة إلى مكان لا يحوي فيه القالب وسم فيديو واحدا، وكل الأشكال ترسم بـHTML وCSS. نحن نبيع الفيديو، وفيديونا نحن في مكان آخر، لا في مسار تحميل صفحات البيع.
ماذا يظهر هذا الفيديو مما لا تظهره صورة ثابتة وجملتان؟
الفيديو هو القرار الصحيح
- عرض منتج أو عملية خطوة بخطوة
- شيء يتغير ولا تمسكه صورة
- شهادة عميل، حيث النبرة جزء من الرسالة
- ضع ملصقا، واجعل preload بقيمة none، والتشغيل بالنقر
احذف الفيديو
- فيديو خلفية في الهيرو لا يشاهده أحد
- فيلم التعريف بالشركة على صفحة الأسعار
- رسم متحرك قصير متكرر: استعمل بدله فيديو صامتا بتكرار
- أي فيديو لا يضيع شيء إن لم يشتغل أبدا
أين يضرب الفيديو سرعة الصفحة بالضبط؟
في موضعين، وواحد منهما فقط هو الذي يفكر فيه الجميع.
الأول الحجم وهو مألوف: البايتات التي تنزل تتنافس على النطاق نفسه مع بقية موارد الصفحة، وعلى الجوال باتصال متوسط يكسب الفيديو تلك المنافسة لأنه أكبر. والثاني أقل شهرة وأهم: الفيديو نفسه قد يكون عنصر LCP للصفحة. وثائق web.dev تدرج عنصر video ضمن مرشحي LCP، ويحسب له الأسبق من اثنين: زمن تحميل صورة الملصق أو زمن عرض الإطار الأول.
أي أنه إن كان أكبر شيء في أعلى الصفحة فيديو فالمقياس الذي تقيسه غوغل بوصفه تجربة الصفحة مرتبط به. والعتبة التي يذكرها web.dev لـLCP جيد هي ٢.٥ ثانية أو أقل عند المئين الخامس والسبعين للتحميلات، وما تجاوز ٤ ثوان يعد ضعيفا.
والنتيجة العملية في سطرين. إن كان الفيديو لا يشتغل تلقائيا فضع له ملصقا دائما، فتجلس عندئذ صورة محسنة على مسار LCP بدل تنزيل فيديو. وإن كان ذلك الملصق أكبر عنصر في الصفحة فيقترح web.dev رفع أولويته بـfetchpriority="high".
وفخ يظهر باستمرار: ملصق رديء، أو ملصق حجمه هو نفسه مئات الكيلوبايتات. الملصق صورة عادية وتسري عليه قواعد التحسين نفسها؛ فإن لم تضغطه فكل ما فعلته هو نقل المشكلة.
أي إعدادات وسم الفيديو تؤثر فعلا؟
أربعة، وأكبر أثر لواحد هو الأقل ضبطا: preload.
| قيمة preload | ماذا يفعل المتصفح | أين تصح |
|---|---|---|
none | لا يحمل شيء من الفيديو مسبقا | فيديو على المستخدم أن ينقره |
metadata | تجلب معلومات الملف فقط مثل المدة | الافتراضي الذي ينصح به MDN |
auto | قد ينزل الملف كله حتى لو لم يشتغل | لا مكان له تقريبا في صفحة بيع |
فصل الفيديو في web.dev يقول preload="none" صراحة للتشغيل الذي يبدأه المستخدم. هذه الخاصية وحدها تخرج أثقل تنزيل في الصفحة من مسار التحميل.
الملصق ثانيا. يقول MDN إنه بلا poster لا يعرض شيء حتى يتوفر الإطار الأول، ثم يعرض ذلك الإطار الأول ملصقا؛ أي أنك بلا ملصق إما أمام مستطيل فارغ أو مضطر إلى جلب الملف أبكر.
التشغيل التلقائي ثالثا وهو قرار أكثر منه إعدادا. يكتب web.dev أن autoplay ينبغي ألا يستعمل إلا عند الضرورة ونتيجة لحاجة متوقعة للمستخدم. وينبه MDN أيضا إلى أن المتصفحات الحديثة تمنع التشغيل التلقائي للفيديو ذي مسار صوت غير مكتوم، فالفيديو التلقائي الذي فيه صوت لن يشتغل عمليا.
واستبدال الجيف رابعا، وهو الموضع الوحيد الذي يكون فيه التشغيل التلقائي صحيحا دائما تقريبا. إن أردت رسما متحركا قصيرا متكررا فاستعمل فيديو صامتا بـautoplay وmuted وloop بدل GIF. ولهذه الحالة بالذات يقترح web.dev إزالة مسار الصوت كليا بعلم -an في ffmpeg، لأن إزالة مسار الصوت تقلل حجم الملف.
ونقطة لا تدخل القوائم: هذه الإعدادات الأربعة لا تفعل شيئا لملف رمز بسوء. أنزل الدقة إلى ما يعرض فعلا؛ فإرسال ملف بـ1080 بكسل إلى إطار عرضه 360 بكسل على الهاتف ليس مما تعوضه أي من هذه الخصائص.
أين يقيم الملف: خادمك أم منصة؟
كلا الخيارين صحيح وهما لموقفين مختلفين؛ وما يفصل بينهما هو التحكم مقابل الحمل.
حين تقدم الملف بنفسك يكون كل شيء لك: لا مشغل لأحد آخر، ولا سكربت إضافي، ولا شعار ولا اقتراح للفيديو التالي، ولا بيانات زائر تذهب إلى مكان آخر. والكلفة واضحة أيضا: النطاق والحركة يخرجان من الخادم نفسه الذي يقدم HTML، والفيديو الطويل على استضافة مشتركة هو حيث ينكسر هذا القرار.
وحين تستعمل منصة يحملون هم العبء وتحصل مجانا على بث متكيف ونسخ جودة متعددة. وفي المقابل ينضم إلى الصفحة مصدر ثالث بسكربته الخاص، ومظهر المشغل ليس لك، وما يجري داخل ذلك المشغل يتبع قواعد تلك الخدمة.
والقاعدة التي نستعملها بسيطة: كل ما هو أقصر من نحو عشر ثوان وكان زخرفيا أو عرضيا يذهب كملف عندنا بتشغيل تلقائي صامت؛ وكل ما هو طويل ويجلس أحد لمشاهدته يذهب إلى منصة خلف صورة ملصق وتحميل كسول، فلا يصل سكربت المشغل إلا بعد نقرة.
وفخ تقني يصيب الحالتين: وضع فيديو داخل صفحة لها هي نفسها تخزين صفحات. ملف الفيديو لا يأتي من كاش HTML وله مساره الخاص، فقد لا تعكس درجة السرعة التي تعطيك إياها أداة ما وضع الفيديو أصلا. لذلك بعد كل تغيير افتح الصفحة مرة بشبكة مخنوقة في أدوات مطور المتصفح وانظر ما الذي ينزل فعلا.
ملفك أم منصة: التحكم مقابل الحمل
الملف على خادمك
- لا سكربت طرف ثالث ولا مصدر ثالث ينضم إلى الصفحة
- مظهر المشغل وما يحدث عند النهاية لك أنت
- النطاق يخرج من الخادم نفسه الذي يقدم HTML
- مناسب للمقاطع القصيرة الصامتة المتكررة
مستضاف على منصة
- بث متكيف ونسخ جودة متعددة بلا عمل إضافي
- يرفع حمل النطاق عن خادمك
- أخر سكربت المشغل بالتحميل الكسول
- مناسب للفيديو الطويل الذي يجلس أحد لمشاهدته
لا واحد أفضل من الآخر؛ طول الفيديو وسعة الاستضافة هما ما يقرران، لا الذوق.
ماذا تعني درجة ٩٠ وما الذي لا تقوله؟
درجة الأداء في لايت هاوس تتراوح من ٠ إلى ١٠٠، ووثائق كروم نفسها تضع النطاقات هكذا: من ٠ إلى ٤٩ ضعيف، ومن ٥٠ إلى ٨٩ يحتاج تحسينا، ومن ٩٠ إلى ١٠٠ جيد. والرقم الذي نستهدفه هو الحافة الدنيا للنطاق الأخضر، أي ٩٠.
والآن ما لا تقوله الدرجة، وهو أهم من الدرجة. لايت هاوس اختبار مخبري: تشغيلة واحدة، على جهاز محاكى، عبر شبكة محاكاة. ومستخدموك الحقيقيون على هواتف مختلفة وشبكات مختلفة، وذلك يظهر في بيانات الميدان لا في هذا الرقم.
وفي الفيديو تكون الفجوة أوسع من المعتاد، لأن سلوك المستخدم جزء من المعادلة. الصفحة التي فيديوها preload="none" تحصد درجة ممتازة في المختبر لأن لا أحد ينقر. والتجربة الحقيقية لمن ينقر ليست في تلك الدرجة أصلا.
فاقرأ الدرجة إنذارا لا هدفا. تحت ٩٠ هناك شيء على مسار التحميل يستحق النظر. وفوق ٩٠ يعني فقط أن مسار التحميل نظيف؛ أما كم يستغرق الفيديو ليبدأ بعد النقر فتقيسه على حدة. وإن أردت أن ترى أين يقع هذا كله داخل مشروع سرعة فصفحة تسريع الموقع تشرح المسار.
المسار السريع مع الذكاء الاصطناعي
المسار السريع هنا ليس أن تسأل نموذجا كيف أخفف الفيديو. بل أن تستخرج أولا الجرد الحقيقي لملفات فيديو الصفحة بـffprobe، ثم تسلم ذلك الجرد إلى النموذج مع ميزانية الصفحة ليعيد لكل ملف قرارا محددا وأمرا جاهزا. والفرق عن السؤال المباشر أن النموذج يكف عن التخمين: الأرقام أمامه.
- خذ جردا. لكل ملف فيديو في الصفحة اقرأ الدقة والمدة ومعدل البت والحجم بـffprobe في سطر واحد. وهذا الجدول عادة يتخذ نصف القرار وحده.
- قس عرض العرض الحقيقي. في أدوات مطور المتصفح انظر عرض صندوق الفيديو على الجوال وعلى سطح المكتب. هذا الرقم هو ما يحدد الدقة المستهدفة، لا ما كان عليه الملف الأصلي.
- سلم الجدول والميزانية إلى نموذج بالوصفة أدناه. والناتج صف لكل ملف: يبقى أم يذهب، والدقة المستهدفة، وهل الصوت لازم أصلا.
- نفذ أوامر الترميز، واستخرج الملصق من ملف المخرجات نفسه، واكتب الوسم بالملصق وpreload الصحيحين. ثم افتح الصفحة بشبكة مخنوقة وانظر ما الذي ينزل فعلا.
وصفة جاهزة للنسخ
# نفذت الأوامر الأربعة كلها على هذا الخادم بـffmpeg 6.1.1 وفحصت مخرجاتها.
# ١. الجرد: الدقة والمدة ومعدل البت وحجم كل ملف
for f in *.mp4 *.mov; do
echo "== $f"
ffprobe -v error -show_entries stream=width,height,codec_name \
-show_entries format=duration,bit_rate,size -of default=nw=1 "$f"
done
# ٢. نسخة الويب. الرقم بعد scale هو الارتفاع المستهدف؛ و2- يترك العرض
# يحسب ويبقى زوجيا. وcrf أعلى يعني ملفا أصغر وجودة أقل.
ffmpeg -i source.mov -vf "scale=-2:720" -c:v libx264 -crf 26 -preset slow \
-profile:v high -pix_fmt yuv420p -c:a aac -b:a 128k \
-movflags +faststart web.mp4
# ٣. بديل الجيف: صامت وأخف
ffmpeg -i source.mov -an -vf "scale=-2:720" -c:v libx264 -crf 28 \
-preset slow -pix_fmt yuv420p -movflags +faststart loop.mp4
# ٤. الملصق، من ملف المخرجات لا من المصدر
ffmpeg -ss 2 -i web.mp4 -frames:v 1 -q:v 3 poster.jpg
# ٥. أمر القرار، لنموذج قوي
الدور: مهندس أداء ويب. الجدول أدناه جرد فيديوهات صفحة.
هدف الصفحة: {مثلا صفحة هبوط بيعية، LCP دون ٢.٥ ثانية}
العرض الحقيقي لصندوق الفيديو: {مثلا ٣٦٠ بكسل على الجوال، ٧٢٠ على سطح المكتب}
ماذا يفعل كل فيديو: {سطر لكل ملف}
جدول ffprobe:
{ضع مخرجات الخطوة ١ هنا}
أعط صفا لكل ملف بهذه الأعمدة:
١. اسم الملف
٢. يبقى / يحذف / يستبدل بصورة ثابتة، ولماذا في جملة واحدة
٣. الدقة المستهدفة، بناء على عرض الصندوق الحقيقي لا على الملف المصدر
٤. هل الصوت لازم؟ إن لم يكن فاكتب -an
٥. هل التشغيل التلقائي مسموح؟ فقط إن كان صامتا ومتكررا وقصيرا
٦. قيمة preload، وهل الملصق مطلوب
القواعد:
- لا تكتب حجما ولا معدل بت ليس في الجدول، ولا تخمن أي رقم.
- لا تعد بتوفير بنسبة مئوية. وإن أعطيت رقما فقل من أي سطر في الجدول جاء.
- إن كان ملف لا يناسب هدف الصفحة أصلا فضع «يحذف» في العمود الثاني ولا
تبحث عن إعداد.
- في النهاية اسرد الملفات التي تضع أكثر البايتات على مسار التحميل مرتبة.قبل أن تثق بالناتج: أمران عليك أن تراهما بنفسك. الأول الجودة: رقم crf إعداد لا ضمان، وعلى لقطات فيها حبيبات كثيرة أو تدرجات يعطي الرقم نفسه نتيجة أسوأ. شاهد المخرج بحجمه الكامل على الصفحة التي سيظهر فيها فعلا، لا في معاينة صغيرة. والثاني الصوت: علم -an يزيل الصوت كليا وهو غير قابل للتراجع؛ فإن تبين لاحقا أن ذلك المقطع يحتاج تعليقا صوتيا فعليك العودة إلى المصدر. وكالعادة تحقق من أي توفير ذكره النموذج بقياسك أنت، لأن الرقم الوحيد الذي يعتد به هو الذي خرج من ملفك الحقيقي.
الذكاء الاصطناعي في هذا العمل
في تحسين الفيديو لا يفعل الذكاء الاصطناعي شيئا غريبا، وهذا خبر جيد. ما يفعله فعلا هو الترجمة: من مخرجات الأدوات إلى قرار، ومن القرار إلى أمر. أما الضغط نفسه فيقوم به ffmpeg وهو مجاني وحتمي، ولا يحل نموذج محله. وموقفنا: أحضر النموذج لمرحلة القرار لا لمرحلة التنفيذ، لأن أداة التنفيذ الصحيحة موجودة أصلا.
أدوات تساعد فعلا
- Gemini اقتصادي للمرور الأول على مخرجات ffprobe وتقرير السرعة، لأن ذلك عمل آلي قابل للمراجعة: ترتيب الجدول وإيجاد أثقل الملفات. وإيران ليست في قائمة الدول المدعومة لدى غوغل؛ وطبقة الدفع في صفحة شراء الذكاء الاصطناعي على هذا الموقع.
- Claude أفضل لمرحلة القرار، حيث يكون الجواب أن ملفا ينبغي ألا يكون على الصفحة أصلا. وهو أقل ميلا إلى اقتراح إعداد حين يكون الجواب الصحيح الحذف. وإيران ليست في قائمة الدول المدعومة لدى أنثروبيك.
- ffmpeg ليس ذكاء اصطناعيا وهو في هذه القائمة عمدا: هو ما يفعل الشيء الذي يبحث عنه الجميع، مجانا ومحليا وبلا رفع. والنموذج يكتب سطر أمره فقط. ووثائق web.dev تحيل مباشرة إلى هذه الأداة لإزالة مسار الصوت.
اين ينقلب ضدك
الخطر الأساسي في هذا الموضوع هو الأرقام التي تذكرها النماذج بثقة تامة عن خفض الحجم. جملة «هذا الإعداد يقلل الحجم نحو أربعين في المئة» تشبه الجواب ولم تأت من أي قياس على ملفك؛ فالخفض الحقيقي يتوقف على محتوى ذلك الفيديو، والمشهد المزدحم بالتفاصيل والمشهد الساكن يعطيان نتائج شديدة الاختلاف من إعداد واحد. ولهذا يمنع الأمر أعلاه صراحة كتابة أي رقم ليس في الجدول. والخطر الثاني أوامر ffmpeg التي يؤلفها النموذج وتفعل الشيء الخطأ بصمت: علم لا أثر له في ذلك الموضع، أو مرشح لا يناسب الكودك المختار، أو علم يعيد الترميز بينما كانت النية النسخ. وهذه لا تعطي خطأ، بل تعطي شيئا يبدو صحيحا. فافحص دائما حجم ملف المخرجات وأبعاده بـffprobe. والخطر الثالث يعود إلى الخصوصية: رفع لقطات العميل إلى خدمة ضغط على الإنترنت هو القرار نفسه الموصوف في درس المونتاج ويسري هنا أيضا، بينما ffmpeg لا يحتاج رفعا أصلا.
المصادر: web.dev: video performance Chrome for Developers: Lighthouse performance scoring Anthropic: is my data used for model training
حدود هذه النصيحة
هذا الدرس عن الفيديو القصير في الصفحات العادية: عرض، إعلان قصير، شهادة عميل، رسم متحرك متكرر. أما إن كان عملك الفيديو الطويل أو الدورات المصورة أو المحتوى المدفوع فتلك مسألة أخرى بأجوبة أخرى: بث متكيف، وتغليف بمعدلات بت متعددة، وضبط وصول، ولا شيء منها مغطى في هذه الصفحة. وحد آخر بصدق: لا شيء هنا ينقذ فيديو لا يريد أحد مشاهدته. الملف المحسن الذي لا يشغله أحد يبقى قرارا خاطئا، لكنه أخف.
من عملنا نحن
إعداد لا يكاد أي دليل جاد يهتم به وهو يصنع أكبر فرق في سرعة بدء التشغيل: -movflags +faststart. ملف MP4 مبني من كتل، وكتلة moov هي خريطة الملف؛ فإن كانت في آخره وجب على المتصفح جلب معظم الملف قبل أن يعرف كيف يشغله. على هذا الخادم وبـffmpeg 6.1.1 أنتجنا مخرجين وقرأنا ترتيب الكتل: بلا العلم جاء الترتيب ftyp وfree وmdat وmoov، ومعه ftyp وmoov وfree وmdat. أي أن الخريطة انتقلت من آخر الملف إلى أوله. وهذا شيء يمكنك اختباره على ملفك في ثلاثين ثانية، وعنده تكتشف أن الفيديو البطيء في البدء بعد النقر ليس بالضرورة ثقيلا.
اسئلة متابعة حقيقية
للويب، أيهما أفضل MP4 أم WebM؟
إن كنت تنتج ملفا واحدا فقط فـMP4 بـH.264 هو ما يشتغل في أكثر الأماكن بلا متاعب. وإن أردته أخف دون أن تفقد التوافق فيمكنك وضع مصدرين داخل وسم فيديو واحد ويأخذ المتصفح أول ما يعرفه. والفرق بينهما في تفاصيل الكودك، ودرس صيغ الفيديو والكودك هو مكان ذلك.
هل فيديو الخلفية في قسم الهيرو مشكلة؟
المشكلة أنه يضع أثقل شيء في الصفحة تماما حيث يقاس LCP، ولا يعطي في المقابل أي معلومة عادة. وإن كنت لا تزال تحتاجه فاجعله على الأقل صامتا وقصيرا ومتكررا، وأزل مسار الصوت، وأعطه ملصقا محسنا كي لا تبقى الصفحة فارغة إن لم يشتغل. لكن الجواب الصادق في أكثر الحالات أن صورة جيدة تؤدي العمل نفسه بجزء يسير من الكلفة.
كيف تحمل الفيديو تحميلا كسولا؟
لملفك أنت، يؤدي preload="none" معظم العمل: لا يجلب المتصفح شيئا من الفيديو حتى يبدأ أحد التشغيل. أما الفيديو على منصة فالمسألة ليست الملف بل سكربت المشغل؛ والطريقة المعتادة أن تضع صورة ملصق بدل تضمين المشغل مباشرة، وتحمل المشغل بعد النقر على تلك الصورة فقط.