التحميل غير المتزامن لـ Typekit ::فهل يستحق ذلك أم أنه من الأفضل عدم استخدامه على الإطلاق؟

Question

محاولة تقليل وقت تحميل الصفحة.

لقد اتبعت المثال الثالث المبين هنا لتحميل جافا سكريبت TypeKit بشكل غير متزامن.

لجعله يعمل عليك إضافة .wf-loading #some-element {visibility: hidden;} لكل عنصر يستخدم الخط، وبعد 1) تحميله أو 2) بعد فترة زمنية محددة (ثانية واحدة)، يصبح الخط مرئيًا.

الأمر هو أن CSS الذي أعمل معه يحتوي على الخط المخصص لحوالي 200 عنصر، أي 200 عنصر من .wf-loading{ } (ملحوظة:أنا لم أكتب هذا CSS).

أشعر أن هذا سيؤدي إلى إبطاء وقت التحميل أكثر من مجرد السماح له بالتحميل بانتظام، حيث أن DOM يجتاز الكثير من الأشياء.إذا كان هذا هو الحال، فسوف أقوم بإلغاء Typekit تمامًا وأستخدم الخط العادي.

هل هناك أي أدوات يمكنني استخدامها لإجراء اختبارات الأداء على هذا النوع من الأشياء؟أو هل قام أحد باختبار هذه الأشياء؟

Answer 1

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

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

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

Answer 2

المشكلة كما ذكروا في مدونة, ، المناسبات النادرة (ولكن هذا يحدث بالتأكيد - بالتأكيد أكثر من مرة بالنسبة لي) عندما يفشل Typekit CDN تمامًا ويرى المستخدمون صفحة فارغة فقط.هذا هو الوقت الذي تتمنى فيه استخدام التحميل غير المتزامن.