لماذا لا تعرض صفحات الويب نصها على الفور؟

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

تأتي جلسة الأسئلة والأجوبة اليوم مقدمة من SuperUser-a subdivision of Stack Exchange ، وهي مجموعة مجتمعية مدفوعة من مواقع Q & A.

السؤال

قارئ SuperUser لوران فضولي للغاية حول سبب ظهور الصفحات بالتحميل بشكل مختلف تمامًا عما كانت عليه في المرة الواحدة. هو يكتب:

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

وهي تعمل بشكل أساسي على عكس ما كانت عليه ، عندما تم عرض النص أولاً ، ثم تم تحميل الصور والباقي بعد ذلك. ما هي التقنية الجديدة التي تنشئ هذه المشكلة؟ اي فكرة?

لاحظ أنني على اتصال بطيء ، وهو ما يبرز المشكلة على الأرجح.

انظر [أعلاه] على سبيل المثال - تم تحميل كل شيء ولكن يستغرق بضع ثوانٍ قبل عرض النص أخيرًا.

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

الاجابة

يقدم مساعدي SuperUser Daniel Andersson إجابة مفصّلة رائعة تصل مباشرة إلى الجزء السفلي من سبب لغز الحمل الأخير:

سبب واحد هو أن مصممي الويب في الوقت الحاضر ترغب في استخدام خطوط الويب (عادة في تنسيق WOFF) ، على سبيل المثال. من خلال خطوط Google Web.

في السابق ، كانت الخطوط الوحيدة التي تم عرضها على الموقع هي الخطوط التي قام المستخدم بتثبيتها محليًا. على سبيل المثال لم يكن لدى مستخدمي Mac و Windows بالضرورة نفس الخطوط ، فالمصممين كانوا دائمًا يعرّفون القواعد كما هي

font-family: Arial، Helvetica، sans-serif؛ 

حيث ، إذا لم يتم العثور على الخط الأول على النظام ، فسيقوم المتصفح بالبحث عن الخط الثاني ، وأخيرًا خط "sans-serif" الاحتياطي.

الآن ، يمكن للمرء أن يعطي عنوان URL خطًا كقاعدة CSS للحصول على المتصفح لتنزيل خط ، على هذا النحو:

import url (http://fonts.googleapis.com/css؟family=Droid+Serif:400،700)؛ 

ثم قم بتحميل الخط لعنصر معين بواسطة eG:

font-family: 'Droid Serif'، sans-serif؛ 

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

على سبيل المثال: تستخدم إحدى صحفي الوطنية ، Dagens Nyheter ، خطوط الويب لعناوينها ، ولكن ليس خطوطها الرئيسية ، لذلك عندما يتم تحميل هذا الموقع ، عادةً ما أراها في المقدمة ، وبعد نصف ثانية يتم ملء جميع المساحات الفارغة أعلاه مع العناوين الرئيسية (هذا صحيح على Chrome و Opera ، على الأقل. لم يجرب الآخرين).

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

إضافة:

أصبحت هذه الإجابة مبشرة للغاية ، على الرغم من أنني لم أخوض في تفاصيل كثيرة ، أو ربما لان من هذا. كانت هناك العديد من التعليقات في موضوع السؤال ، لذلك سأحاول توسيع بعض الشيء […]

وتعرف الظاهرة على ما يبدو بأنها "فلاش من المحتوى غير المنضبط" بشكل عام ، و "وميض للنصوص غير الثابتة" على وجه الخصوص. البحث عن "FOUC" و "FOUT" يعطي المزيد من المعلومات.

يمكنني أن أوصي مصمم موقع بول الايرلندية على FOUT فيما يتعلق بخطوط الويب.

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

في أي الحالات سوف تحصل على FOUT

• سوف: تحميل وعرض ttf / otf / woff عن بعد
• سوف: عرض ttf / otf / woff المخبأ
• سوف: تنزيل وعرض بيانات ttf / otf / wow
• سوف: عرض بيانات تخزين مؤقت - uri ttf / otf / woff
• سوف لن: عرض خط تم تثبيته بالفعل وتسميةه في مجموعة الخطوط التقليدية
• سوف لن: عرض خط يتم تثبيته وتسميةه باستخدام الموقع () المحلي

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

لدى Irish أيضًا بعض التحديثات المتعلقة بسلوك المتصفح اعتبارًا من 2011-04-14 في أسفل المشاركة:

• ثعلب النار (اعتبارا من FFb11 و FF4 النهائي) لم يعد لديه FOUT! Woohoo! http: //bugzil.la/499292 بشكل أساسي ، النص غير مرئي لمدة 3 ثوانٍ ، ثم يعيد الخط الاحتياطي. من المحتمل أن يتم تحميل webfont في غضون تلك الثواني الثلاث على الرغم من ... نأمل ...
• يدعم IE9 كل من WOFF و TTF و OTF (على الرغم من أنه يتطلب تضمين عنصر bitset - غالباً ما يكون موضوعًا إذا كنت تستخدم WOFF). ومع ذلك!!! IE9 لديه FOUT. :(
• يحتوي Webkit على حزمة تصحيح تنتظر الهبوط لعرض النص الاحتياطي بعد 0.5 ثانية. نفس السلوك مثل FF ولكن 0.5S بدلا من 3S.

إذا كان هذا السؤال موجها للمصممين ، يمكن للمرء أن يذهب إلى طرق لتجنب هذه الأنواع من المشاكل مثل webfontloader, لكن هذا سيكون سؤال آخر. يشرح الرابط الأيرلندي Paul المزيد من التفاصيل حول هذه المسألة.

هل لديك شيء تضيفه إلى الشرح؟ الصوت قبالة في التعليقات. هل ترغب في قراءة المزيد من الإجابات من مستخدمي Stack Exchange الآخرين المحترفين بالتكنولوجيا؟ تحقق من موضوع المناقشة الكامل هنا.