أداء الواجهة الأمامية 2021: تحسينات الأصول

تم دعم هذا الدليل من قبل أصدقائنا في LogRocket ، وهي خدمة تجمع بين مراقبة أداء الواجهة الأمامية وإعادة تشغيل الجلسة وتحليلات المنتج لمساعدتك في بناء تجارب أفضل للعملاء. LogRocket يتتبع المقاييس الرئيسية ، بما في ذلك. اكتمل DOM ، الوقت حتى البايت الأول ، تأخير الإدخال الأول ، استخدام وحدة المعالجة المركزية للعميل والذاكرة. احصل على نسخة تجريبية مجانية من LogRocket اليوم.

جدول المحتويات

1. الاستعداد: التخطيط والقياسات
2. تحديد أهداف واقعية
3. تعريف البيئة
4. تحسينات الأصول
5. بناء التحسينات
6. تحسينات التسليم
7. الشبكات ، HTTP / 2 ، HTTP / 3
8. الاختبار والمراقبة
9. انتصارات سريعة
10. كل شيء في صفحة واحدة
11. قم بتنزيل قائمة التحقق (PDF ، Apple Pages ، MS Word)
12. اشترك في النشرة الإخبارية عبر البريد الإلكتروني حتى لا تفوت الأدلة التالية.

تحسينات الأصول

1. استخدم Brotli لضغط النص العادي.
   في عام 2015 ، قدمت Google تنسيق Brotli ، وهو تنسيق بيانات جديد مفتوح المصدر بدون فقدان البيانات ، وهو مدعوم الآن في جميع المتصفحات الحديثة. مكتبة Brotli مفتوحة المصدر ، والتي تنفذ برنامج تشفير وفك تشفير لـ Brotli ، لديها 11 مستوى جودة محدد مسبقًا لبرنامج التشفير ، مع مستوى جودة أعلى يتطلب المزيد من وحدة المعالجة المركزية في مقابل نسبة ضغط أفضل. سيؤدي الضغط الأبطأ في النهاية إلى معدلات ضغط أعلى ، ومع ذلك ، لا يزال Brotli يفك الضغط بسرعة. تجدر الإشارة إلى أن Brotli بمستوى الضغط 4 أصغر حجمًا ويتم ضغطه بشكل أسرع من Gzip.

   من الناحية العملية ، يبدو أن Brotli أكثر فعالية من Gzip. تختلف الآراء والتجارب ، ولكن إذا تم تحسين موقعك بالفعل باستخدام Gzip ، فقد تتوقع تحسينات من رقم واحد على الأقل وفي أحسن الأحوال تحسينات مكونة من رقمين في تقليل الحجم وتوقيت FCP. يمكنك أيضًا تقدير مدخرات ضغط Brotli لموقعك.

   لن تقبل المتصفحات Brotli إلا إذا كان المستخدم يزور موقع ويب عبر HTTPS. Brotli مدعوم على نطاق واسع ، والعديد من شبكات CDN تدعمه (Akamai ، Netlify Edge ، AWS ، KeyCDN ، Fastly (حاليًا فقط كمرور) ، Cloudflare ، CDN77) ويمكنك تمكين Brotli حتى على شبكات CDN التي لا تدعمها بعد (مع عامل خدمة).

   المهم هو أنه نظرًا لأن ضغط جميع الأصول باستخدام Brotli عند مستوى ضغط مرتفع أمر مكلف ، لا يمكن للعديد من مزودي الاستضافة استخدامه في fule scall لمجرد التكلفة الضخمة التي ينتجها. في الواقع ، عند أعلى مستوى من الضغط ، يكون Brotli بطيئًا للغاية بحيث يمكن إبطال أي مكاسب محتملة في حجم الملف بمقدار الوقت الذي يستغرقه الخادم لبدء إرسال الاستجابة أثناء انتظار ضغط الأصل ديناميكيًا. (ولكن إذا كان لديك وقت أثناء وقت الإنشاء باستخدام الضغط الثابت ، فبالطبع ، يفضل استخدام إعدادات ضغط أعلى.)

   

   قد يتغير هذا بالرغم من ذلك. يتضمن تنسيق ملف Brotli قاموسًا ثابتًا مضمنًا ، وبالإضافة إلى احتوائه على سلاسل متنوعة بلغات متعددة ، فإنه يدعم أيضًا خيار تطبيق تحويلات متعددة على هذه الكلمات ، مما يزيد من تعدد استخداماتها. اكتشف فيليكس هاناو في بحثه طريقة لتحسين الضغط عند المستويات من 5 إلى 9 باستخدام "مجموعة فرعية أكثر تخصصًا من القاموس من الافتراضي" والاعتماد على رأس Content-Type لإخبار الضاغط إذا كان يجب أن يستخدم قاموس HTML أو JavaScript أو CSS. وكانت النتيجة "تأثير ضئيل على الأداء (1٪ إلى 3٪ أكثر من وحدة المعالجة المركزية مقارنة بـ 12٪ عادةً) عند ضغط محتوى الويب بمستويات ضغط عالية ، باستخدام أسلوب استخدام قاموس محدود."

   

   علاوة على ذلك ، من خلال بحث Elena Kirilenko ، يمكننا تحقيق إعادة ضغط Brotli بسرعة وكفاءة باستخدام أدوات الضغط السابقة. وفقًا لإيلينا ، "بمجرد أن يكون لدينا أحد الأصول مضغوطًا عبر Brotli ، ونحاول ضغط المحتوى الديناميكي أثناء التنقل ، حيث يشبه المحتوى المحتوى المتاح لنا مسبقًا ، يمكننا تحقيق تحسينات كبيرة في أوقات الضغط. "

   كم مرة هذا هو الحال؟ على سبيل المثال ، عند تسليم مجموعات فرعية من حزم JavaScript (على سبيل المثال ، عند تخزين أجزاء من الشفرة مؤقتًا بالفعل على العميل أو مع خدمة الحزمة الديناميكية مع WebBundles). أو باستخدام HTML الديناميكي المستند إلى القوالب المعروفة مسبقًا ، أو خطوط WOFF2 المنقسمة ديناميكيًا . وفقًا لإيلينا ، يمكننا الحصول على تحسين بنسبة 5.3٪ على الضغط وتحسين بنسبة 39٪ على سرعة الضغط عند إزالة 10٪ من المحتوى ، ومعدلات ضغط أفضل بنسبة 3.2٪ وضغط أسرع بنسبة 26٪ ، عند إزالة 50٪ من المحتوى.

   يتحسن ضغط Brotli ، لذلك إذا كان بإمكانك تجاوز تكلفة ضغط الأصول الثابتة ديناميكيًا ، فمن المؤكد أن الأمر يستحق كل هذا الجهد. وغني عن القول أنه يمكن استخدام Brotli لأي حمولة نص عادي - HTML و CSS و SVG و JavaScript و JSON وما إلى ذلك.

   ملاحظة : اعتبارًا من أوائل عام 2021 ، يتم تسليم ما يقرب من 60٪ من استجابات HTTP بدون ضغط مستند إلى نص ، مع ضغط بنسبة 30.82٪ باستخدام Gzip ، وضغط بنسبة 9.1٪ باستخدام Brotli (سواء على الهاتف المحمول أو على سطح المكتب). على سبيل المثال ، 23.4٪ من الصفحات ذات الزاوية غير مضغوطة (عبر gzip أو Brotli). ومع ذلك ، يعد تشغيل الضغط في كثير من الأحيان أحد أسهل المكاسب لتحسين الأداء بضغطة بسيطة على مفتاح.

   الاستراتيجية؟ قم بضغط الأصول الثابتة مسبقًا باستخدام Brotli + Gzip على أعلى مستوى وضغط HTML (ديناميكي) سريعًا باستخدام Brotli في المستوى 4-6. تأكد من أن الخادم يتعامل مع تفاوض المحتوى لـ Brotli أو Gzip بشكل صحيح.

1. هل نستخدم تحميل الوسائط التكيفية وتلميحات العميل؟
   إنها تأتي من أرض الأخبار القديمة ، لكنها دائمًا تذكير جيد لاستخدام الصور المتجاوبة مع srcset sizes والعنصر <picture> . خاصة بالنسبة للمواقع ذات البصمة الإعلامية الثقيلة ، يمكننا أن نخطو خطوة إلى الأمام من خلال تحميل الوسائط التكيفية (في هذا المثال ، React + Next.js) ، حيث نقدم تجربة خفيفة لإبطاء الشبكات والأجهزة ذات الذاكرة المنخفضة وتجربة كاملة للشبكة السريعة والعالية - أجهزة الذاكرة. في سياق React ، يمكننا تحقيق ذلك من خلال تلميحات العميل على الخادم والخطافات التكيفية للتفاعل على العميل.

   قد يتغير مستقبل الصور سريعة الاستجابة بشكل كبير مع تبني تلميحات العميل على نطاق واسع. تلميحات العميل هي حقول رأس طلب HTTP ، مثل DPR و Viewport-Width و Width و Save-Data و Accept (لتحديد تفضيلات تنسيق الصورة) وغيرها. من المفترض أن يبلغوا الخادم بخصائص متصفح المستخدم وشاشته واتصاله وما إلى ذلك.

   نتيجة لذلك ، يمكن للخادم تحديد كيفية ملء التخطيط بالصور ذات الحجم المناسب ، وتقديم هذه الصور فقط بالتنسيقات المرغوبة. مع تلميحات العميل ، ننقل اختيار المورد من ترميز HTML إلى مفاوضات الاستجابة للطلب بين العميل والخادم.

   

   كما لاحظ Ilya Grigorik منذ فترة ، فإن تلميحات العميل تكمل الصورة - فهي ليست بديلاً للصور سريعة الاستجابة. "يوفر عنصر <picture> التحكم الضروري في الاتجاه الفني في ترميز HTML. توفر تلميحات العميل تعليقات توضيحية على طلبات الصور الناتجة التي تتيح أتمتة اختيار الموارد. يوفر عامل الخدمة إمكانات إدارة الطلبات والاستجابة الكاملة على العميل."

   يمكن لعامل الخدمة ، على سبيل المثال ، إلحاق قيم رؤوس تلميحات العميل الجديدة بالطلب ، وإعادة كتابة عنوان URL وتوجيه طلب الصورة إلى CDN ، وتكييف الاستجابة بناءً على الاتصال وتفضيلات المستخدم ، وما إلى ذلك. إلى حد كبير لجميع الطلبات الأخرى أيضًا.

   بالنسبة للعملاء الذين يدعمون تلميحات العميل ، يمكن قياس توفير 42٪ بايت على الصور و 1 ميجا بايت + بايت أقل للشريحة 70 + المئوية. في مجلة Smashing ، يمكننا قياس تحسن بنسبة 19 إلى 32٪ أيضًا. يتم دعم تلميحات العميل في المتصفحات المستندة إلى Chromium ، لكنها لا تزال قيد الدراسة في Firefox.

   ومع ذلك ، إذا قمت بتوفير كلٍ من ترميز الصور المتجاوبة العادي وعلامة <meta> لـ Client Hints ، فسيقوم المستعرض الداعم بتقييم ترميز الصور المتجاوبة ويطلب مصدر الصورة المناسب باستخدام رؤوس Client Hints HTTP.

2. هل نستخدم الصور المتجاوبة لصور الخلفية؟
   يجب علينا بالتأكيد! مع image-set ، المدعومة الآن في Safari 14 وفي معظم المتصفحات الحديثة باستثناء Firefox ، يمكننا تقديم صور خلفية سريعة الاستجابة أيضًا:

   background-image: url("fallback.jpg"); background-image: image-set( "photo-small.jpg" 1x, "photo-large.jpg" 2x, "photo-print.jpg" 600dpi);

   يمكننا أساسًا تقديم صور خلفية منخفضة الدقة بشكل مشروط مع واصف 1x وصور عالية الدقة مع واصف 2x وحتى صورة بجودة الطباعة مع واصف 600dpi نقطة في البوصة. احذر على الرغم من ذلك: لا تقدم المتصفحات أي معلومات خاصة عن صور الخلفية للتقنية المساعدة ، لذلك من الأفضل أن تكون هذه الصور مجرد زخرفة.

3. هل نستخدم WebP؟
   غالبًا ما يُعتبر ضغط الصور فوزًا سريعًا ، ومع ذلك لا يزال غير مستغل بشكل كبير في الممارسة العملية. بالطبع لا تمنع الصور العرض ، لكنها تساهم بشكل كبير في نقاط LCP الضعيفة ، وغالبًا ما تكون ثقيلة جدًا وكبيرة جدًا بالنسبة للجهاز الذي يتم استهلاكها عليه.

   لذلك على الأقل ، يمكننا استكشاف استخدام تنسيق WebP لصورنا. في الواقع ، اقتربت ملحمة WebP من نهايتها العام الماضي مع إضافة Apple الدعم لـ WebP في Safari 14. لذلك بعد سنوات عديدة من المناقشات والمناقشات ، اعتبارًا من اليوم ، يتم دعم WebP في جميع المتصفحات الحديثة. لذلك يمكننا تقديم صور WebP مع عنصر <picture> و JPEG احتياطيًا إذا لزم الأمر (انظر مقتطف رمز Andreas Bovens) أو باستخدام تفاوض المحتوى (باستخدام Accept الرؤوس).

   لا يخلو WebP من سلبياته بالرغم من ذلك. في حين أن أحجام ملفات صور WebP مقارنة بأحجام Guetzli و Zopfli المكافئة ، فإن التنسيق لا يدعم العرض التدريجي مثل JPEG ، وهذا هو السبب في أن المستخدمين قد يرون الصورة النهائية بشكل أسرع باستخدام تنسيق ol 'JPEG الجيد على الرغم من أن صور WebP قد تزداد سرعة عبر الشبكة. باستخدام JPEG ، يمكننا تقديم تجربة مستخدم "لائقة" بنصف أو حتى ربع البيانات وتحميل الباقي لاحقًا ، بدلاً من الحصول على صورة نصف فارغة كما هو الحال في WebP.

   سيعتمد قرارك على ما تسعى إليه: باستخدام WebP ، ستقلل من الحمولة ، وباستخدام JPEG ستحسن الأداء الملحوظ. يمكنك معرفة المزيد عن WebP في WebP Rewind talk بواسطة باسكال ماسيمينو من Google.

   للتحويل إلى WebP ، يمكنك استخدام WebP Converter أو cwebp أو libwebp. لدى Ire Aderinokun برنامجًا تعليميًا مفصلاً للغاية حول تحويل الصور إلى WebP أيضًا - وكذلك فعل Josh Comeau في مقالته حول تبني تنسيقات الصور الحديثة.

   

   يدعم Sketch أصلاً WebP ، ويمكن تصدير صور WebP من Photoshop باستخدام مكون WebP الإضافي لـ Photoshop. لكن الخيارات الأخرى متاحة أيضًا.

   إذا كنت تستخدم WordPress أو Joomla ، فهناك ملحقات لمساعدتك على تنفيذ دعم WebP بسهولة ، مثل Optimus و Cache Enabler for WordPress و Joomla's extension المدعوم (عبر Cody Arsenault). يمكنك أيضًا تجريد عنصر <picture> بعيدًا باستخدام React أو مكوّنات نمطية أو gatsby-image.

   آه - المكونات وقح! - نشر جيريمي واجنر كتاب Smashing على WebP والذي قد ترغب في التحقق مما إذا كنت مهتمًا بكل شيء يتعلق بـ WebP.

4. هل نستخدم AVIF؟
   ربما سمعت الخبر الكبير: لقد هبط AVIF. إنه تنسيق صورة جديد مشتق من الإطارات الرئيسية لفيديو AV1. إنه تنسيق مفتوح وخالي من حقوق الملكية يدعم ضغطًا ضياعًا وخاليًا من الضياع والرسوم المتحركة وقناة ألفا مع فقدان البيانات ويمكنه التعامل مع الخطوط الحادة والألوان الصلبة (التي كانت تمثل مشكلة مع JPEG) ، مع توفير نتائج أفضل في كليهما.

   في الواقع ، مقارنةً بـ WebP و JPEG ، يعمل AVIF بشكل أفضل بشكل ملحوظ ، مما يؤدي إلى توفير متوسط ​​في حجم الملف يصل إلى 50٪ في نفس التشابه DSSIM ((dis) بين صورتين أو أكثر باستخدام خوارزمية تقترب من الرؤية البشرية). في الواقع ، في رسالته الشاملة حول تحسين تحميل الصور ، أشار Malte Ubl إلى أن AVIF "يتفوق باستمرار على JPEG بطريقة مهمة للغاية. وهذا يختلف عن WebP الذي لا ينتج دائمًا صورًا أصغر من JPEG وقد يكون في الواقع شبكة- الخسارة بسبب نقص الدعم للتحميل التدريجي. "

   

   ومن المفارقات أن AVIF يمكن أن يؤدي أداءً أفضل من SVGs الكبيرة على الرغم من أنه بالطبع لا ينبغي أن يُنظر إليه على أنه بديل لـ SVGs. وهو أيضًا أحد تنسيقات الصور الأولى التي تدعم دعم ألوان HDR ؛ تقدم سطوعًا أعلى وعمق بت لوني وتدرجات لونية أعلى. الجانب السلبي الوحيد هو أن AVIF حاليًا لا يدعم فك تشفير الصورة التدريجي (حتى الآن) ، وعلى غرار Brotli ، فإن ترميز معدل الضغط المرتفع حاليًا بطيء جدًا ، على الرغم من أن فك التشفير سريع.

   يتم دعم AVIF حاليًا في Chrome و Firefox و Opera ، ومن المتوقع أن يتوفر الدعم في Safari قريبًا (نظرًا لأن Apple عضو في المجموعة التي أنشأت AV1).

   ما هي أفضل طريقة لتقديم الصور هذه الأيام ؟ بالنسبة إلى الرسوم التوضيحية والصور المتجهة ، يعد SVG (المضغوط) هو الخيار الأفضل بلا شك. بالنسبة للصور ، نستخدم طرق التفاوض على المحتوى مع عنصر picture . إذا كان AVIF مدعومًا ، نرسل صورة AVIF ؛ إذا لم يكن الأمر كذلك ، فنعود إلى WebP أولاً ، وإذا لم يكن WebP مدعومًا أيضًا ، فسننتقل إلى JPEG أو PNG كبديل احتياطي (تطبيق شروط @media إذا لزم الأمر):

   <picture> <source type="image/avif"> <source type="image/webp"> <img src="image.jpg" alt="Photo" width="450" height="350"> </picture>

   بصراحة ، من الأرجح أننا سنستخدم بعض الشروط داخل عنصر picture على الرغم من:

   <picture> <source type="image/avif" /> <source type="image/webp" /> <source type="image/jpeg" /> <img src="fallback-image.jpg" alt="Photo" width="450" height="350"> </picture>
   <picture> <source type="image/avif" /> <source type="image/webp" /> <source type="image/jpeg" /> <img src="fallback-image.jpg" alt="Photo" width="450" height="350"> </picture>

   يمكنك الذهاب إلى أبعد من ذلك عن طريق تبديل الصور المتحركة بالصور الثابتة للعملاء الذين يختارون الحركة الأقل مع الحركة prefers-reduced-motion :

   <picture> <source media="(prefers-reduced-motion: reduce)" type="image/avif"></source> <source media="(prefers-reduced-motion: reduce)" type="image/jpeg"></source> <source type="image/avif"></source> <img src="motion.jpg" alt="Animated AVIF"> </picture>
   <picture> <source media="(prefers-reduced-motion: reduce)" type="image/avif"></source> <source media="(prefers-reduced-motion: reduce)" type="image/jpeg"></source> <source type="image/avif"></source> <img src="motion.jpg" alt="Animated AVIF"> </picture>

   على مدار الشهرين ، اكتسب AVIF بعض الجذب:

   • يمكننا اختبار احتياطات WebP / AVIF في لوحة العرض في DevTools.
   • يمكننا استخدام Squoosh و AVIF.io و libavif لترميز ملفات AVIF وفك تشفيرها وضغطها وتحويلها.
   • يمكننا استخدام مكون AVIF Preact الخاص بـ Jake Archibald الذي يقوم بفك تشفير ملف AVIF في العامل ويعرض النتيجة على قماش ،
   • لتقديم AVIF للمتصفحات الداعمة فقط ، يمكننا استخدام ملحق PostCSS مع نصي 315B لاستخدام AVIF في إعلانات CSS الخاصة بك.
   • يمكننا تقديم تنسيقات صور جديدة بشكل تدريجي باستخدام CSS و Cloudlare Workers لتغيير مستند HTML الذي تم إرجاعه ديناميكيًا ، واستنتاج المعلومات من عنوان accept ، ثم إضافة webp/avif وما إلى ذلك حسب الاقتضاء.
   • يتوفر AVIF بالفعل في Cloudinary (مع حدود الاستخدام) ، ويدعم Cloudflare AVIF في تغيير حجم الصورة ، ويمكنك تمكين AVIF مع رؤوس AVIF المخصصة في Netlify.
   • عندما يتعلق الأمر بالرسوم المتحركة ، فإن AVIF يعمل مثل <img src=mp4> Safari ، متفوقًا على GIF و WebP بشكل عام ، لكن MP4 لا يزال يعمل بشكل أفضل.
   • بشكل عام ، بالنسبة إلى الرسوم المتحركة ، AVC1 (h264)> HVC1> WebP> AVIF> GIF ، بافتراض أن المتصفحات القائمة على Chromium ستدعم <img src=mp4> .
   • يمكنك العثور على مزيد من التفاصيل حول AVIF في AVIF من أجل حديث ترميز الصور من الجيل التالي بواسطة Aditya Mavlankar من Netflix ، و تحدث تنسيق صورة AVIF بواسطة Kornel Lesinski من Cloudflare.
   • مرجع رائع لكل شيء AVIF: لقد وصل منشور Jake Archibald الشامل على AVIF.

   إذن هل المستقبل AVIF إذن ؟ لا يوافق جون سنيرز على ذلك: إن أداء AVIF أسوأ بنسبة 60٪ من أداء JPEG XL ، وهو تنسيق مجاني ومفتوح آخر طورته Google و Cloudinary. في الواقع ، يبدو أن أداء JPEG XL يعمل بشكل أفضل في جميع المجالات. ومع ذلك ، لا يزال JPEG XL في المراحل النهائية للتوحيد القياسي ، ولا يعمل حتى الآن في أي متصفح. (عدم الخلط مع Microsoft JPEG-XR الذي يأتي من Internet Explorer 9 مرات).

1. هل تم تحسين ملفات JPEG / PNG / SVG بشكل صحيح؟
   عندما تعمل على صفحة مقصودة يكون من المهم فيها تحميل صورة بطل بسرعة فائقة ، تأكد من أن ملفات JPEG تقدمية ومضغوطة باستخدام mozJPEG (الذي يحسن وقت بدء العرض من خلال معالجة مستويات المسح) أو Guetzli ، المصدر المفتوح من Google برنامج تشفير يركز على الأداء الإدراكي ، والاستفادة من الدروس المستفادة من Zopfli و WebP. الجانب السلبي الوحيد: بطء أوقات المعالجة (دقيقة لوحدة المعالجة المركزية لكل ميجابيكسل).

   بالنسبة إلى PNG ، يمكننا استخدام Pingo و SVG ، يمكننا استخدام SVGO أو SVGOMG. وإذا كنت بحاجة إلى معاينة جميع أصول SVG ونسخها أو تنزيلها بسرعة من أحد مواقع الويب ، فيمكن لـ svg-grabber القيام بذلك نيابةً عنك أيضًا.

   ستوضح كل مقالة تحسين صورة واحدة ، لكن الحفاظ على أصول المتجهات نظيفة وضيقة يستحق دائمًا الذكر. تأكد من تنظيف الأصول غير المستخدمة وإزالة البيانات الوصفية غير الضرورية وتقليل عدد نقاط المسار في العمل الفني (وبالتالي رمز SVG). ( شكرا جيريمي! )

   هناك أيضًا أدوات مفيدة متاحة عبر الإنترنت على الرغم من:

   • استخدم Squoosh لضغط الصور وتغيير حجمها ومعالجتها بمستويات الضغط المثلى (ضياع أو بدون فقدان) ،
   • استخدم Guetzli.it لضغط وتحسين صور JPEG باستخدام Guetzli ، والذي يعمل بشكل جيد مع الصور ذات الحواف الحادة والألوان الصلبة (ولكن قد يكون أبطأ قليلاً)).
   • استخدم منشئ نقاط توقف الصور المتجاوبة أو خدمة مثل Cloudinary أو Imgix لأتمتة تحسين الصورة. أيضًا ، في كثير من الحالات ، سيحقق استخدام srcset sizes وحدها فوائد كبيرة.
   • للتحقق من كفاءة الترميز سريع الاستجابة ، يمكنك استخدام imaging-heap ، وهي أداة سطر أوامر تقيس الكفاءة عبر أحجام منفذ العرض ونسب بكسل الجهاز.
   • يمكنك إضافة ضغط تلقائي للصور إلى تدفقات عمل GitHub ، لذلك لا يمكن لأي صورة أن تصل إلى الإنتاج غير مضغوط. يستخدم الإجراء mozjpeg و libvips اللذان يعملان مع PNGs و JPG.
   • لتحسين التخزين بشكل داخلي ، يمكنك استخدام تنسيق Lepton الجديد من Dropbox لضغط ملفات JPEG بدون خسارة بمعدل 22٪.
   • استخدم BlurHash إذا كنت ترغب في إظهار صورة عنصر نائب مبكرًا. يأخذ BlurHash صورة ، ويمنحك سلسلة قصيرة (20-30 حرفًا فقط!) تمثل العنصر النائب لهذه الصورة. السلسلة قصيرة بما يكفي لإضافتها بسهولة كحقل في كائن JSON.

   

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

   • ضع في اعتبارك تحميل الصور المهمة مسبقًا ، حتى لا يكتشفها المتصفح بعد فوات الأوان. بالنسبة لصور الخلفية ، إذا كنت تريد أن تكون أكثر عدوانية من ذلك ، يمكنك إضافة الصورة كصورة عادية باستخدام <img src> ، ثم إخفائها عن الشاشة.
   • ضع في اعتبارك تبديل الصور بسمة الأحجام عن طريق تحديد أبعاد عرض مختلفة للصور بناءً على استعلامات الوسائط ، على سبيل المثال لمعالجة sizes لتبديل المصادر في مكون المكبر.
   • راجع تناقضات تنزيل الصور لمنع التنزيلات غير المتوقعة لصور المقدمة والخلفية. احترس من الصور التي يتم تحميلها افتراضيًا ، ولكن قد لا يتم عرضها مطلقًا - على سبيل المثال في الدوارات ، والأكورديون ، ومعارض الصور.
   • تأكد دائمًا من ضبط width height على الصور. احترس من خاصية aspect-ratio في CSS والسمة intrinsicsize التي ستسمح لنا بتعيين نسب العرض إلى الارتفاع والأبعاد للصور ، بحيث يمكن للمتصفح حجز فتحة تخطيط محددة مسبقًا في وقت مبكر لتجنب قفزات التخطيط أثناء تحميل الصفحة.

   

   إذا كنت تشعر بالمغامرة ، فيمكنك قطع وإعادة ترتيب تدفقات HTTP / 2 باستخدام عمال Edge ، وهو مرشح في الوقت الفعلي يعيش على CDN ، لإرسال الصور بشكل أسرع عبر الشبكة. يستخدم عمال Edge تدفقات JavaScript التي تستخدم أجزاء يمكنك التحكم فيها (في الأساس هم JavaScript يتم تشغيله على حافة CDN التي يمكنها تعديل استجابات الدفق) ، بحيث يمكنك التحكم في تسليم الصور.

   مع عامل الخدمة ، فات الأوان لأنك لا تستطيع التحكم في ما هو على السلك ، لكنه يعمل مع عمال Edge. لذا يمكنك استخدامها فوق ملفات JPEG الثابتة المحفوظة تدريجيًا لصفحة مقصودة معينة.

   

   ليس جيدا بما فيه الكفاية؟ حسنًا ، يمكنك أيضًا تحسين الأداء المتصور للصور باستخدام تقنية صور الخلفية المتعددة. ضع في اعتبارك أن اللعب بالتباين وطمس التفاصيل غير الضرورية (أو إزالة الألوان) يمكن أن يقلل حجم الملف أيضًا. آه ، تحتاج إلى تكبير صورة صغيرة دون فقدان الجودة؟ ضع في اعتبارك استخدام Letsenhance.io.

   

   تغطي هذه التحسينات حتى الآن الأساسيات فقط. نشرت Addy Osmani دليلاً مفصلاً للغاية حول Essential Image Optimization والذي يتعمق في تفاصيل ضغط الصور وإدارة الألوان. على سبيل المثال ، يمكنك طمس الأجزاء غير الضرورية من الصورة (عن طريق تطبيق مرشح ضباب غاوسي عليها) لتقليل حجم الملف ، وفي النهاية قد تبدأ في إزالة الألوان أو تحويل الصورة إلى أبيض وأسود لتقليل الحجم بدرجة أكبر . بالنسبة لصور الخلفية ، يمكن أن يكون تصدير الصور من Photoshop بجودة من 0 إلى 10٪ مقبولًا تمامًا أيضًا.

   في مجلة Smashing ، نستخدم خيار postfix -opt الصور - على سبيل المثال ، brotli-compression-opt.png ؛ كلما احتوت الصورة على هذا postfix ، يعلم كل فرد في الفريق أن الصورة قد تم تحسينها بالفعل.

   آه ، ولا تستخدم JPEG-XR على الويب - "تؤدي معالجة جانب برنامج فك تشفير JPEG-XRs على وحدة المعالجة المركزية إلى إبطال التأثير الإيجابي المحتمل لتوفير حجم البايت ، خاصة في سياق SPA" (لا لخلطها مع Cloudinary / Google's JPEG XL بالرغم من ذلك).

1. هل تم تحسين مقاطع الفيديو بشكل صحيح؟
   لقد غطينا الصور حتى الآن ، لكننا تجنبنا الحديث عن صور GIF الجيدة. على الرغم من حبنا لملفات GIF ، فقد حان الوقت حقًا للتخلي عنها نهائيًا (على الأقل في مواقعنا الإلكترونية وتطبيقاتنا). بدلاً من تحميل صور GIF متحركة ثقيلة تؤثر على كل من أداء العرض والنطاق الترددي ، من المستحسن التبديل إما إلى WebP المتحرك (مع كون GIF احتياطيًا) أو استبدالها بمقاطع فيديو HTML5 متكررة تمامًا.

   على عكس الصور ، لا تقوم المتصفحات بتحميل محتوى <video> مسبقًا ، لكن مقاطع فيديو HTML5 تميل إلى أن تكون أخف وأصغر بكثير من ملفات GIF. ليس خيارا؟ حسنًا ، على الأقل يمكننا إضافة ضغط ضائع إلى ملفات GIF باستخدام ملف GIF أو gifsicle أو giflossy.

   تُظهر الاختبارات التي أجراها Colin Bendell أن مقاطع الفيديو المضمنة ضمن علامات img في Safari Technology Preview تعرض على الأقل 20 × أسرع وفك تشفير 7 × أسرع من مكافئ GIF ، بالإضافة إلى كونها جزءًا صغيرًا من حجم الملف. ومع ذلك ، فهو غير مدعوم في المتصفحات الأخرى.

   في أرض الأخبار السارة ، شهدت تنسيقات الفيديو تقدمًا هائلاً على مر السنين. لفترة طويلة ، كنا نأمل أن يصبح WebM هو التنسيق الذي يحكمهم جميعًا ، وسيصبح WebP (وهو في الأساس صورة ثابتة داخل حاوية فيديو WebM) بديلاً لتنسيقات الصور المؤرخة. في الواقع ، يدعم Safari الآن WebP ، ولكن على الرغم من حصول WebP و WebM على الدعم هذه الأيام ، فإن الاختراق لم يحدث حقًا.

   ومع ذلك ، يمكننا استخدام WebM لمعظم المتصفحات الحديثة:

   <!-- By Houssein Djirdeh. https://web.dev/replace-gifs-with-videos/ --> <!-- A common scenartio: MP4 with a WEBM fallback. --> <video autoplay loop muted playsinline> <source src="my-animation.webm" type="video/webm"> <source src="my-animation.mp4" type="video/mp4"> </video>

   لكن ربما يمكننا إعادة النظر فيه تمامًا. في عام 2018 ، أصدر تحالف Open Media تنسيق فيديو جديدًا واعدًا يسمى AV1 . يحتوي AV1 على ضغط مشابه لبرنامج الترميز H.265 (تطور H.264) ولكن على عكس الأخير ، فإن AV1 مجاني. دفع تسعير ترخيص H.265 بائعي المستعرضات إلى اعتماد AV1 ذو الأداء المماثل بدلاً من ذلك: يضغط AV1 (تمامًا مثل H.265) مرتين مثل WebM .

   

   في الواقع ، تستخدم Apple حاليًا تنسيق HEIF و HEVC (H.265) ، ويتم حفظ جميع الصور ومقاطع الفيديو على أحدث إصدار من iOS بهذه التنسيقات ، وليس JPEG. بينما لم يتم عرض HEIF و HEVC (H.265) بشكل صحيح على الويب (حتى الآن) ، فإن AV1 - وهو يكتسب دعم المتصفح. لذا فإن إضافة مصدر AV1 في علامة <video> الخاصة بك أمر معقول ، حيث يبدو أن جميع بائعي المستعرضات على متنها.

   في الوقت الحالي ، الترميز الأكثر استخدامًا ودعمًا هو H.264 ، والذي يتم تقديمه بواسطة ملفات MP4 ، لذا قبل تقديم الملف ، تأكد من معالجة ملفات MP4 الخاصة بك بترميز متعدد المسارات ، غير واضح مع تأثير frei0r iirblur (إن أمكن) و يتم نقل البيانات الوصفية لـ moov atom إلى رأس الملف ، بينما يقبل الخادم خدمة البايت. يوفر Boris Schapira إرشادات دقيقة لـ FFmpeg لتحسين مقاطع الفيديو إلى أقصى حد. بالطبع ، قد يساعد توفير تنسيق WebM كبديل أيضًا.

   هل تحتاج إلى بدء عرض مقاطع الفيديو بشكل أسرع ولكن ملفات الفيديو لا تزال كبيرة جدًا ؟ على سبيل المثال ، متى كان لديك مقطع فيديو كبير في الخلفية على صفحة مقصودة؟ الأسلوب الشائع الذي يجب استخدامه هو إظهار الإطار الأول كصورة ثابتة أولاً ، أو عرض مقطع حلقة قصيرة مُحسَّن بشكل كبير يمكن تفسيره كجزء من الفيديو ، وبعد ذلك ، كلما تم تخزين الفيديو مؤقتًا بدرجة كافية ، ابدأ التشغيل الفيديو الفعلي. يحتوي دوج سيلارز على دليل تفصيلي مكتوب لأداء الفيديو في الخلفية والذي يمكن أن يكون مفيدًا في هذه الحالة. ( شكرا ، جاي بودجارني! ).

   بالنسبة للسيناريو أعلاه ، قد ترغب في تقديم صور ملصقات سريعة الاستجابة . بشكل افتراضي ، تسمح عناصر video بصورة واحدة فقط كملصق ، وهذا ليس بالضرورة هو الأمثل. يمكننا استخدام Respive Video Poster ، وهي مكتبة JavaScript تتيح لك استخدام صور ملصقات مختلفة لشاشات مختلفة ، مع إضافة تراكب انتقالي وتحكم كامل في التصميم لعناصر الفيديو النائبة.

   أظهر البحث أن جودة بث الفيديو تؤثر على سلوك المشاهد. في الواقع ، يبدأ المشاهدون في التخلي عن الفيديو إذا تجاوز تأخير بدء التشغيل ثانيتين تقريبًا. بعد هذه النقطة ، تؤدي زيادة التأخير بمقدار ثانية واحدة إلى زيادة بنسبة 5.8٪ تقريبًا في معدل التخلي. لذلك ليس من المستغرب أن يكون متوسط ​​وقت بدء الفيديو هو 12.8 ثانية ، مع وجود 40٪ من مقاطع الفيديو بها توقف واحد على الأقل ، و 20٪ على الأقل 2 ثانية من توقف تشغيل الفيديو. في الواقع ، لا يمكن تجنب أكشاك الفيديو على شبكة الجيل الثالث ، حيث يتم تشغيل مقاطع الفيديو بشكل أسرع من قدرة الشبكة على توفير المحتوى.

   إذن ما الحل؟ عادة لا تستطيع الأجهزة ذات الشاشات الصغيرة التعامل مع 720p و 1080 p نحن نخدم سطح المكتب. وفقًا لـ Doug Sillars ، يمكننا إما إنشاء إصدارات أصغر من مقاطع الفيديو الخاصة بنا ، واستخدام Javascript لاكتشاف المصدر للشاشات الأصغر لضمان التشغيل السريع والسلس على هذه الأجهزة. بدلاً من ذلك ، يمكننا استخدام دفق الفيديو. ستوفر تدفقات الفيديو HLS فيديو بالحجم المناسب للجهاز - مما يلخص الحاجة إلى إنشاء مقاطع فيديو مختلفة لشاشات مختلفة. سيتفاوض أيضًا على سرعة الشبكة ، وسيتكيف معدل بت الفيديو مع سرعة الشبكة التي تستخدمها.

   لتجنب إهدار النطاق الترددي ، يمكننا فقط إضافة مصدر الفيديو للأجهزة التي يمكنها بالفعل تشغيل الفيديو بشكل جيد. بدلاً من ذلك ، يمكننا إزالة سمة autoplay من علامة video تمامًا واستخدام JavaScript لإدراج autoplay للشاشات الأكبر حجمًا. بالإضافة إلى ذلك ، نحتاج إلى إضافة preload="none" على video لإخبار المتصفح بعدم تنزيل أي من ملفات الفيديو حتى يحتاج إلى الملف بالفعل:

   <!-- Based on Doug Sillars's post. https://dougsillars.com/2020/01/06/hiding-videos-on-the-mbile-web/ --> <video preload="none" playsinline muted loop width="1920" height="1080" poster="poster.jpg"> <source src="video.webm" type="video/webm"> <source src="video.mp4" type="video/mp4"> </video>

   ثم يمكننا استهداف المتصفحات التي تدعم AV1 على وجه التحديد:

   <!-- Based on Doug Sillars's post. https://dougsillars.com/2020/01/06/hiding-videos-on-the-mbile-web/ --> <video preload="none" playsinline muted loop width="1920" height="1080" poster="poster.jpg"> <source src="video.av1.mp4" type="video/mp4; codecs=av01.0.05M.08"> <source src="video.hevc.mp4" type="video/mp4; codecs=hevc"> <source src="video.webm" type="video/webm"> <source src="video.mp4" type="video/mp4"> </video>

   يمكننا بعد ذلك إعادة إضافة autoplay فوق حد معين (مثل 1000 بكسل):

   /* By Doug Sillars. https://dougsillars.com/2020/01/06/hiding-videos-on-the-mbile-web/ */ <script> window.onload = addAutoplay(); var videoLocation = document.getElementById("hero-video"); function addAutoplay() { if(window.innerWidth > 1000){ videoLocation.setAttribute("autoplay",""); }; } </script>

   

   يعد أداء تشغيل الفيديو قصة بحد ذاتها ، وإذا كنت ترغب في التعمق فيها بالتفصيل ، فقم بإلقاء نظرة على سلسلة أخرى لـ Doug Sillars حول الحالة الحالية للفيديو وأفضل ممارسات توصيل الفيديو التي تتضمن تفاصيل حول مقاييس توصيل الفيديو والتحميل المسبق للفيديو والضغط والتدفق. أخيرًا ، يمكنك التحقق من مدى بطء أو سرعة دفق الفيديو الخاص بك باستخدام Stream or Not.

1. هل تم تحسين توصيل خطوط الويب؟
   السؤال الأول الذي يستحق السؤال هو ما إذا كان بإمكاننا الابتعاد عن استخدام خطوط نظام واجهة المستخدم في المقام الأول - نحتاج فقط إلى التأكد مرة أخرى من ظهورها بشكل صحيح على أنظمة أساسية مختلفة. إذا لم يكن الأمر كذلك ، فمن المحتمل أن تشتمل خطوط الويب التي نقدمها على صور رمزية وميزات وأوزان إضافية لا يتم استخدامها. يمكننا أن نطلب من مسبك النوع لدينا مجموعة فرعية من خطوط الويب أو إذا كنا نستخدم خطوطًا مفتوحة المصدر ، فقم بتجميعها بمفردنا باستخدام Glyphhanger أو Fontsquirrel. يمكننا حتى أتمتة سير العمل بالكامل باستخدام خط Peter Muller الفرعي ، وهو أداة سطر أوامر تحلل صفحتك بشكل ثابت من أجل إنشاء مجموعات فرعية من خطوط الويب المثلى ، ثم إدخالها في صفحاتنا.

   يعد دعم WOFF2 رائعًا ، ويمكننا استخدام WOFF كبديل للمتصفحات التي لا تدعمه - أو ربما يمكن تقديم خطوط النظام للمتصفحات القديمة. هناك العديد والعديد من الخيارات لتحميل خطوط الويب ، ويمكننا اختيار إحدى الاستراتيجيات من "الدليل الشامل لاستراتيجيات تحميل الخطوط" من Zach Leatherman (تتوفر مقتطفات التعليمات البرمجية أيضًا كوصفات تحميل خطوط الويب).

   ربما تكون أفضل الخيارات التي يجب مراعاتها اليوم هي Critical FOFT مع preload وطريقة "The Compromise". يستخدم كلاهما عرضًا من مرحلتين لتقديم خطوط الويب بخطوات - أولاً مجموعة فرعية صغيرة مطلوبة لعرض الصفحة بسرعة وبدقة مع خط الويب ، ثم تحميل بقية المجموعة غير متزامنة. الفرق هو أن تقنية "التسوية" تقوم بتحميل polyfill بشكل غير متزامن فقط إذا كانت أحداث تحميل الخط غير مدعومة ، لذلك لا تحتاج إلى تحميل polyfill افتراضيًا. هل تحتاج إلى ربح سريع؟ يحتوي Zach Leatherman على برنامج تعليمي سريع مدته 23 دقيقة ودراسة حالة لترتيب الخطوط الخاصة بك.

   بشكل عام ، قد يكون من الجيد استخدام تلميح مورد preload لتحميل الخطوط مسبقًا ، ولكن في الترميز الخاص بك قم بتضمين التلميحات بعد الارتباط إلى CSS و JavaScript المهمين. مع preload ، هناك لغز من الأولويات ، لذا ضع في اعتبارك حقن عناصر rel="preload" في DOM قبل البرامج النصية للحظر الخارجي مباشرةً. وفقًا لـ Andy Davies ، "يتم إخفاء الموارد التي يتم حقنها باستخدام برنامج نصي من المتصفح حتى يتم تنفيذ البرنامج النصي ، ويمكننا استخدام هذا السلوك للتأخير عندما يكتشف المستعرض تلميح preload ." خلاف ذلك ، سيكلفك تحميل الخط في وقت العرض الأول.

   

   إنها لفكرة جيدة أن تكون انتقائيًا وتختار الملفات الأكثر أهمية ، على سبيل المثال تلك التي تعتبر بالغة الأهمية للعرض أو التي من شأنها أن تساعدك على تجنب إعادة تدفق النص المرئي والمزعج. بشكل عام ، ينصح Zach بالتحميل المسبق لخط أو خطين من كل عائلة - من المنطقي أيضًا تأخير تحميل بعض الخطوط إذا كانت أقل أهمية.

   أصبح من الشائع جدًا استخدام القيمة local() (التي تشير إلى خط محلي بالاسم) عند تحديد مجموعة font-family في قاعدة @font-face :

    /* Warning! Not a good idea! */ @font-face { font-family: Open Sans; src: local('Open Sans Regular'), local('OpenSans-Regular'), url('opensans.woff2') format ('woff2'), url('opensans.woff') format('woff'); }

   الفكرة معقولة: بعض الخطوط الشائعة مفتوحة المصدر مثل Open Sans تأتي مثبتة مسبقًا مع بعض برامج التشغيل أو التطبيقات ، لذلك إذا كان الخط متاحًا محليًا ، فلن يحتاج المستعرض إلى تنزيل خط الويب ويمكنه عرض الخط المحلي الخط على الفور. كما لاحظ برام شتاين ، "على الرغم من أن الخط المحلي يتطابق مع اسم خط الويب ، إلا أنه على الأرجح ليس نفس الخط . تختلف العديد من خطوط الويب عن إصدار" سطح المكتب ". قد يتم تقديم النص بشكل مختلف ، وقد تقع بعض الأحرف بالعودة إلى الخطوط الأخرى ، فقد تكون ميزات OpenType مفقودة تمامًا ، أو قد يكون ارتفاع السطر مختلفًا. "

   أيضًا ، نظرًا لتطور الخطوط بمرور الوقت ، قد تكون النسخة المثبتة محليًا مختلفة تمامًا عن خط الويب ، حيث تبدو الأحرف مختلفة تمامًا. لذلك ، وفقًا لـ Bram ، من الأفضل عدم مزج الخطوط المثبتة محليًا وخطوط الويب في قواعد @font-face . اتبعت Google Fonts حذوها من خلال تعطيل local() في نتائج CSS لجميع المستخدمين ، بخلاف طلبات Android لـ Roboto.

   لا أحد يحب انتظار عرض المحتوى. باستخدام واصف CSS font-display ، يمكننا التحكم في سلوك تحميل الخط وتمكين المحتوى ليكون قابلاً للقراءة على الفور (مع font-display: optional ) أو على الفور تقريبًا (مع مهلة 3 ثوانٍ ، طالما يتم تنزيل الخط بنجاح - باستخدام font-display: swap ). (حسنًا ، الأمر أكثر تعقيدًا من ذلك بقليل).

   ومع ذلك ، إذا كنت ترغب في تقليل تأثير إعادة تدفق النص ، فيمكننا استخدام Font Loading API (مدعومة في جميع المتصفحات الحديثة). هذا يعني على وجه التحديد بالنسبة لكل خط ، أننا سننشئ كائن FontFace ، ثم نحاول جلبهم جميعًا ، وبعد ذلك فقط نطبقهم على الصفحة. بهذه الطريقة ، نقوم بتجميع جميع المعاد رسمها عن طريق تحميل جميع الخطوط بشكل غير متزامن ، ثم التبديل من الخطوط الاحتياطية إلى خط الويب مرة واحدة بالضبط. ألق نظرة على شرح زاك ، بدءًا من 32:15 ، ومقتطف الشفرة):

   /* Load two web fonts using JavaScript */ /* Zach Leatherman: https://noti.st/zachleat/KNaZEg/the-five-whys-of-web-font-loading-performance#sWkN4u4 */ // Remove existing @font-face blocks // Create two let font = new FontFace("Noto Serif", /* ... */); let fontBold = new FontFace("Noto Serif, /* ... */); // Load two fonts let fonts = await Promise.all([ font.load(), fontBold.load() ]) // Group repaints and render both fonts at the same time! fonts.forEach(font => documents.fonts.add(font));
   /* Load two web fonts using JavaScript */ /* Zach Leatherman: https://noti.st/zachleat/KNaZEg/the-five-whys-of-web-font-loading-performance#sWkN4u4 */ // Remove existing @font-face blocks // Create two let font = new FontFace("Noto Serif", /* ... */); let fontBold = new FontFace("Noto Serif, /* ... */); // Load two fonts let fonts = await Promise.all([ font.load(), fontBold.load() ]) // Group repaints and render both fonts at the same time! fonts.forEach(font => documents.fonts.add(font));

   لبدء عملية جلب الخطوط مبكرًا باستخدام Font Loading API قيد الاستخدام ، يقترح Adrian Bece إضافة مسافة غير منقسمة nbsp; في الجزء العلوي من body ، وإخفائه بصريًا مع aria-visibility: hidden .hidden

   <body class="no-js"> <!-- ... Website content ... --> <div aria-visibility="hidden" class="hidden"> <!-- There is a non-breaking space here --> </div> <script> document.getElementsByTagName("body")[0].classList.remove("no-js"); </script> </body>
   <body class="no-js"> <!-- ... Website content ... --> <div aria-visibility="hidden" class="hidden"> <!-- There is a non-breaking space here --> </div> <script> document.getElementsByTagName("body")[0].classList.remove("no-js"); </script> </body>

   يتماشى هذا مع CSS الذي يحتوي على مجموعات خطوط مختلفة تم الإعلان عنها لحالات تحميل مختلفة ، مع التغيير الذي تم تشغيله بواسطة Font Loading API بمجرد تحميل الخطوط بنجاح:

   body:not(.wf-merriweather--loaded):not(.no-js) { font-family: [fallback-system-font]; /* Fallback font styles */ } .wf-merriweather--loaded, .no-js { font-family: "[web-font-name]"; /* Webfont styles */ } /* Accessible hiding */ .hidden { position: absolute; overflow: hidden; clip: rect(0 0 0 0); height: 1px; width: 1px; margin: -1px; padding: 0; border: 0; }
   body:not(.wf-merriweather--loaded):not(.no-js) { font-family: [fallback-system-font]; /* Fallback font styles */ } .wf-merriweather--loaded, .no-js { font-family: "[web-font-name]"; /* Webfont styles */ } /* Accessible hiding */ .hidden { position: absolute; overflow: hidden; clip: rect(0 0 0 0); height: 1px; width: 1px; margin: -1px; padding: 0; border: 0; }

   إذا تساءلت يومًا عن السبب في أنه بالرغم من كل التحسينات التي أجريتها ، لا يزال Lighthouse يقترح التخلص من موارد حظر العرض (الخطوط) ، في نفس المقالة ، يوفر Adrian Bece بعض التقنيات لإسعاد Lighthouse ، جنبًا إلى جنب مع Gatsby Omni Font Loader ، وهو خط فعال غير متزامن تحميل و Flash Of Unstyled Text (FOUT) يتعامل مع البرنامج المساعد لـ Gatsby.

   الآن ، قد يستخدم الكثير منا CDN أو مضيفًا تابعًا لجهة خارجية لتحميل خطوط الويب من. بشكل عام ، من الأفضل دائمًا الاستضافة الذاتية لجميع أصولك الثابتة إن أمكن ، لذا ضع في اعتبارك استخدام google-webfonts-helper ، وهي طريقة خالية من المتاعب للاستضافة الذاتية لخطوط Google. وإذا لم يكن ذلك ممكنًا ، فيمكنك ربما وكيل ملفات Google Font من خلال أصل الصفحة.

   تجدر الإشارة إلى أن Google تقوم بعمل قليل جدًا خارج الصندوق ، لذلك قد يحتاج الخادم إلى القليل من التغيير والتبديل لتجنب التأخير ( شكرًا ، Barry! )

   هذا مهم للغاية خاصة أنه منذ إصدار Chrome v86 (تم إصداره في أكتوبر 2020) ، لا يمكن مشاركة الموارد عبر المواقع مثل الخطوط على نفس CDN بعد الآن - بسبب ذاكرة التخزين المؤقت للمتصفح المقسمة. كان هذا السلوك افتراضيًا في Safari لسنوات.

   ولكن إذا لم يكن ذلك ممكنًا على الإطلاق ، فهناك طريقة للوصول إلى أسرع خطوط Google Fonts باستخدام مقتطف Harry Roberts:

   <!-- By Harry Roberts. https://csswizardry.com/2020/05/the-fastest-google-fonts/ - 1. Preemptively warm up the fonts' origin. - 2. Initiate a high-priority, asynchronous fetch for the CSS file. Works in - most modern browsers. - 3. Initiate a low-priority, asynchronous fetch that gets applied to the page - only after it's arrived. Works in all browsers with JavaScript enabled. - 4. In the unlikely event that a visitor has intentionally disabled - JavaScript, fall back to the original method. The good news is that, - although this is a render-blocking request, it can still make use of the - preconnect which makes it marginally faster than the default. --> <!-- [1] --> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin /> <!-- [2] --> <link rel="preload" as="style" href="$CSS&display=swap" /> <!-- [3] --> <link rel="stylesheet" href="$CSS&display=swap" media="print" onload="this.media='all'" /> <!-- [4] --> <noscript> <link rel="stylesheet" href="$CSS&display=swap" /> </noscript>

   تتمثل إستراتيجية Harry في إجراء إحماء استباقي لأصل الخطوط أولاً. ثم نبدأ عملية جلب غير متزامنة ذات أولوية عالية لملف CSS. بعد ذلك ، نبدأ عملية جلب غير متزامنة ذات أولوية منخفضة يتم تطبيقها على الصفحة فقط بعد وصولها (باستخدام خدعة ورقة أنماط الطباعة). أخيرًا ، إذا لم يتم دعم JavaScript ، فإننا نعود إلى الطريقة الأصلية.

   آه ، بالحديث عن Google Fonts: يمكنك حلق ما يصل إلى 90٪ من حجم طلبات Google Fonts عن طريق التصريح فقط بالأحرف التي تريدها مع &text . بالإضافة إلى ذلك ، تمت إضافة دعم عرض الخطوط مؤخرًا إلى Google Fonts أيضًا ، حتى نتمكن من استخدامه خارج الصندوق.

   كلمة تحذير سريعة بالرغم من ذلك. إذا كنت تستخدم font-display: optional ، فقد يكون استخدام preload دون المستوى الأمثل لأنه سيؤدي إلى تشغيل طلب خط الويب هذا مبكرًا (مما يتسبب في ازدحام الشبكة إذا كان لديك موارد مسار حرجة أخرى تحتاج إلى جلبها). استخدم preconnect لطلبات الخطوط عبر الأصل الأسرع ، ولكن كن حذرًا مع preload لأن تحميل الخطوط مسبقًا من أصل مختلف يؤدي إلى تنازع الشبكة. كل هذه التقنيات مغطاة في وصفات تحميل خطوط الويب الخاصة بزاك.

   من ناحية أخرى ، قد يكون من الجيد إلغاء الاشتراك في خطوط الويب (أو عرض المرحلة الثانية على الأقل) إذا قام المستخدم بتمكين تقليل الحركة في تفضيلات إمكانية الوصول أو اختار وضع توفير البيانات (انظر رأس Save-Data ) ، أو عندما يكون لدى المستخدم اتصال بطيء (عبر واجهة برمجة تطبيقات معلومات الشبكة).

   يمكننا أيضًا استخدام استعلام وسائط CSS prefers-reduced-data المختصرة المُفضلة لعدم تحديد تعريفات الخطوط إذا اختار المستخدم وضع توفير البيانات (هناك حالات استخدام أخرى أيضًا). قد يعرض الاستعلام عن الوسائط بشكل أساسي ما إذا كان رأس طلب Save-Data من امتداد HTTP Hint في وضع التشغيل / الإيقاف للسماح بالاستخدام مع CSS. مدعوم حاليًا فقط في Chrome و Edge خلف العلم.

   المقاييس؟ لقياس أداء تحميل خط الويب ، ضع في اعتبارك مقياس All Text Visible (اللحظة التي يتم فيها تحميل جميع الخطوط وعرض كل المحتوى في خطوط الويب) ، و Time to Real Italics وكذلك عدد إعادة تدفق خط الويب بعد العرض الأول. من الواضح أنه كلما انخفض كلا المقياسين ، كان الأداء أفضل.

   ماذا عن الخطوط المتغيرة ، قد تسأل؟ من المهم ملاحظة أن الخطوط المتغيرة قد تتطلب اعتبارًا كبيرًا للأداء. إنها توفر لنا مساحة تصميم أوسع بكثير لاختيارات الطباعة ، ولكنها تأتي على حساب طلب تسلسلي واحد مقابل عدد من طلبات الملفات الفردية.

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

   الآن ، ما الذي يجعل استراتيجية تحميل خط الويب المضاد للرصاص بعد ذلك؟ اجمع الخطوط وقم بإعدادها للعرض على مرحلتين ، وقم بتعريفها باستخدام واصف font-display ، واستخدم Font Loading API لتجميع إعادة رسم الخطوط وتخزينها في ذاكرة التخزين المؤقت لعامل الخدمة الثابتة. في الزيارة الأولى ، قم بحقن التحميل المسبق للنصوص قبل حظر البرامج النصية الخارجية. يمكنك الرجوع إلى برنامج Font Face Observer الخاص بـ Bram Stein إذا لزم الأمر. وإذا كنت مهتمًا بقياس أداء تحميل الخط ، فإن Andreas Marschke يستكشف تتبع الأداء باستخدام Font API و UserTiming API.

   أخيرًا ، لا تنسَ تضمين unicode-range لتقسيم خط كبير إلى خطوط أصغر خاصة باللغة ، واستخدم أداة مطابقة نمط الخط في Monica Dinculescu لتقليل التغيير المتناقض في التخطيط ، بسبب الاختلافات في الحجم بين الخيار الاحتياطي و خطوط الويب.

   بدلاً من ذلك ، لمحاكاة خط ويب لخط احتياطي ، يمكننا استخدام واصفات @ font-face لتجاوز مقاييس الخط (عرض تم تمكينه في Chrome 87). (لاحظ أن عمليات الضبط معقدة مع حزم الخطوط المعقدة.)

   هل يبدو المستقبل مشرقًا؟ من خلال تحسين الخط التدريجي ، قد نتمكن في النهاية من "تنزيل الجزء المطلوب فقط من الخط في أي صفحة معينة ، وللطلبات اللاحقة لهذا الخط من أجل" تصحيح "التنزيل الأصلي ديناميكيًا بمجموعات إضافية من الصور الرمزية كما هو مطلوب في الصفحة المتعاقبة المشاهدات "، كما يشرحها جايسون باتالي. العرض التوضيحي للتحويل التزايدي متاح بالفعل ، وجاري العمل عليه.

جدول المحتويات

1. الاستعداد: التخطيط والقياسات
2. تحديد أهداف واقعية
3. تعريف البيئة
4. تحسينات الأصول
5. بناء التحسينات
6. تحسينات التسليم
7. الشبكات ، HTTP / 2 ، HTTP / 3
8. الاختبار والمراقبة
9. انتصارات سريعة
10. كل شيء في صفحة واحدة
11. قم بتنزيل قائمة التحقق (PDF ، Apple Pages ، MS Word)
12. اشترك في النشرة الإخبارية عبر البريد الإلكتروني حتى لا تفوت الأدلة التالية.