سؤال لماذا لا تعرض مواقع الويب على الفور نصها في هذه الأيام؟


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

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

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

انظر أدناه للحصول على مثال - تم تحميل كل شيء ولكن يستغرق بضع ثوانٍ قبل عرض النص في النهاية:

enter image description here


439
2018-02-07 06:22


الأصل


في هذه الحالة بالذات ، يستخدم PortableApps.com الخط "Ubuntu". حاول جون OpenSans أولاً ، لكننا تحولنا إلى أوبونتو بسرعة كبيرة. لقد كنت الداعم الرئيسي للتبديل ... إحدى الطرق التي يمكنك من خلالها إزالة المشكلة عن طريق تثبيت عائلة الخط بنفسك. إذا قمت بتثبيته من font.ubuntu.com سوف يعمل على الفور. - Chris Morgan
الجواب من قبل دانيال هو فتحت العين. اعتقدت أن هذا يتم عن قصد حتى نتمكن من عرض جميع الإعلانات على الصفحة. - Manoj R
كما أشار العديد من الأشخاص هنا ، هناك أسباب لا حصر لها لتقديم النص بطرق غير متوقعة ، حيث أن عرض الصفحة محدود فقط بخيال المطور / المصمم ، والذي كان هو الحال على الأقل منذ أن سمحت رموز موقف ANSI بنشرات 1980s لوحات لتنفيذ دردشات متعددة المستخدمين و UIs مع نوافذ متداخلة مع الظلال المسقطة. كان Meebo من أوائل الذين قاموا بإعادة إنتاج بعض هذه التأثيرات في مستعرض بدون تطبيق صغير. "يعمل العكس كما اعتاد" على المبالغة في تبسيط الإنترنت ولا يشير حتى إلى فترة زمنية محددة. - PJ Brunet
فلماذا نجري تعميمات كاسحة حول الإنترنت على أساس غطاء شاشة عشوائي واحد من موقع ويب ذو رتبة أليكسا منخفضة؟ تقدم أفضل إجابة أيضًا مطالبة جريئة: "يجب على المصممين في الوقت الحالي فعل XYZ" إجراء نسخ احتياطي مع بعض الأرقام الحقيقية ، مثل "5٪ من مواقع الويب تستخدم Google Web Fonts اعتبارًا من 2012" أو أيًا كانت. - PJ Brunet
ولكن يتم الاحتفاظ ملفات الخط في ذاكرة التخزين المؤقت ، هذا الموقع ينتظر طويلا لتحميل m.aspx قد تحقق من هذا الجزء - user613326


الأجوبة:


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

في السابق ، كانت الخطوط الوحيدة التي تم عرضها على الموقع هي الخطوط التي قام المستخدم بتثبيتها محليًا. على سبيل المثال لم يكن لدى مستخدمي 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;

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

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

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


إضافة

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

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

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

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

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

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

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

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

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

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


483
2018-02-07 07:54



هل حاول أي من المتصفحات عرض النص أولاً في خط متاح ، ثم إعادة عرضه بعد تنزيل الخط المفضل؟ - Steve Bennett
أوه ، دوه ، أعلق على الجواب التالي: paulirish.com/2009/fighting-the-font-face-fout - Steve Bennett
ratchetfreak سيكون من المقلق أن يتم إعادة تهيئة الصفحة لأن الخطوط قد لا تحتوي على نفس المقاييس - Samuel Edwin Ward
يفضل البعض الوصول إلى جزء القراءة في تصفح صفحة الويب بدلاً من انتظار الأعمار حتى يتم تحميل الخط - ratchet freak
SteveBennett أنا متأكد من أن هذا هو بالضبط ما يفعله Internet Explorer 10. لم أر أبداً أي نص يظهر في وقت لاحق. بالنسبة لي ، يظهر النص دائمًا في بعض "الخط القياسي" وبعد بضع ثوانٍ ، يتغير إلى النص الذي تم تنسيقه / تنزيله. لست متأكدا ما إذا كان اختيار CSS المقبل أو مجرد الافتراضي للنظام على الرغم من. تحرير: آه ، لطيفة ، لذلك هو مجرد Webikit مع النص المخفي؟ سأعتبر هذا السلوك المزعج والسيئ. هل هناك أي متصفح يتجاهل / يخفي تحميل الصور التدريجي؟ - Mario


السبب في ذلك هو النص الذي لا يمكنك قراءته بعد خط الويب لا يزال في طريقه إلى أسفل الأنابيب إلى متصفحك.

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


117
2018-02-07 11:46



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


اجابة قصيرة: AJAX أو WOFF

هناك عدة اسباب مواقع الويب "بطيء لعرض نصهم". البطء على portableapps.com ينتج عن التنزيل WOFF الخطوط. ومع ذلك ، ما كنت تصفها "يبدأ النص في الظهور هنا وهناك" في كثير من الأحيان بسبب AJAX.

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

  • صفحة HTML الأولية
  • CSS
  • JS
  • صور
  • خطوط WOFF
  • طلبات AJAX
  • التلاعب DOM

مواقع الويب التقليدية:

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


مواقع WOFF:

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


مواقع AJAX:

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


تحديد السبب

لتحديد سبب موقع معين يتطلب التحليل باستخدام أدوات مثل الحرائق أو أدوات مطوري Chrome. أو بدلاً من ذلك ، يمكنك فتح الموقع باستخدام Internet Explorer 8والتي تدعم AJAX ولكن ليس WOFF. إذا كان الموقع لا يزال بطيئا ، فإن المشكلة هي AJAX وليس WOFF.


19
2018-02-08 13:40





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


14
2018-02-07 08:26



تسع مرات من أصل عشرة لن تكون متعمدة ، إنه ببساطة أحد الآثار الجانبية لتضمين خطوط الويب بأبسط طريقة ممكنة. في الواقع ، يتطلب الأمر القليل من الجهد الإضافي لتقديم بديل مرئي بينما تنزل خطوط الويب إلى أسفل الأنبوب. نرى developers.google.com/webfonts/docs/webfont_loader - Marcel
Marcel - يمكن أن يحدث هذا بسبب بطء أوراق الشجرة وكذلك الخطوط البطيئة ، راجع phpied.com/css-and-the-critical-path - r3m0t
رمز لمنع "فلاش من محتوى مفيد" ، يميل إلى منع ظهور الصور وكذلك النص. - Jon Hanna
أكافح من أجل فهم السبب في أن النص غير المنضبط أسوأ من عدم وجود نص على الإطلاق. أفضل أن أكون قادراً على البدء في قراءة القبول الذي قد يزعج قليلاً. أجده أكثر توترًا عندما يظهر فجأة في أي مكان ومن المحبط جدًا عند تحميل الصفحة وإجبارك على الانتظار للحصول على الخط. - Richard Le Poidevin


كما لاحظ آخرون ، من المرجح أن تساهم الخطوط المخصصة في التأخير.

لإعطاء مزيد من المعلومات الأساسية ، يقوم المتصفح بما يلي تقريبًا قبل أن يتمكن من عرض محتويات الصفحة على الشاشة:

  1. جلب HTML (عدة رحلات مستديرة لـ DNS ، TCP ، طلب / استجابة)
  2. البدء في تحليل HTML ، واكتشاف موارد خارجية مثل CSS الخارجية و JS. لاحظ أن CSS يحظر التخطيط ، وتحظر JS التحليل. لذا ، فإن الموارد الخارجية مثل CSS و JS المحملة مبكرًا في المستند (على سبيل المثال في الرأس) تعمل على إبطاء الوقت الذي تستغرقه الصفحة لعرض المحتوى على الشاشة.
  3. جلب CSS خارجي و JS (عدة رحلات مستديرة: DNS و TCP إذا كانت هذه الموارد موجودة في نطاق مختلف مثل CDN ، بالإضافة إلى RTT للطلب / الاستجابة)
  4. مرة واحدة الانتهاء من CSS الخارجية و JS التحميل ، تحليل / تنفيذ JS ، تحليل / تطبيق الأنماط
  5. إذا كان CSS يشير إلى الخطوط المخصصة ، فيجب تنزيل تلك الخطوط الآن أيضًا ، مما يؤدي إلى تأخيرات إضافية في الرحلة ذهابًا وإيابًا لعرض أي أجزاء من الصفحة تعتمد على الخطوط المخصصة

على الرغم من أن الأمر لا يتعلق بالتأخيرات التي تسببها الخطوط المخصصة على وجه التحديد ، فقد كتبت مؤخرًا على مدونة تعطي معلومات إضافية حول أسباب تأخيرات العرض. يقدم بعض الاقتراحات لتقليل وقت الطلاء لأول مرة لصفحاتك. نأمل أن يكون هذا مفيدًا للقراء المهتمين بجعل صفحاتهم تعرض المحتوى بشكل أسرع ، بما في ذلك الصفحات التي ترغب في استخدام الخطوط المخصصة: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under-one-second/


8
2018-02-07 18:26





إجابة مختصرة: المطورين.

عند وضع علامات الارتباط والبرنامج النصي التي تشير إلى مستندات خارجية (مثل .css أو ملفات .js) في رأس المستند (أعلى في التدفق من الجسم ، وعناصره) ، يتم تحميلها أولاً. جافا سكريبت ينفذ من الترميز الذي يشير إليها ؛ إذا كان هناك الكثير من التعليمات البرمجية لمعالجة ، أو رمز مرهقة ، أو بشكل أكثر شيوعًا إذا تم عرض النص الذي تتوقع رؤيته على خادم ثم نشره في المستند على التحميل - وهذا رمز من جانب الخادم هو أيضا مرهقة ، كبيرة ، أو حظر I / O بسبب معالجة العديد من الطلبات المتزامنة ، قد تلاحظ بالتأكيد التوقف قبل أن تتاح لـ HTML فرصة حتى. يختار بعض المطورين تحميل جافا سكريبت غير ذات صلة بعد وضع العلامات والأنماط (في نهاية النص) ، وأفضل محاولة أن تكون أكثر إدراكًا لكيفية تأثير قرار التكنولوجيا على تجربة المستخدم الفوقية عند تنفيذها.

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


4
2018-02-07 10:04



كلا - ما يمكن وصفه يمكن أن يمنع عناصر DOM من العرض وليس النص فقط. الجواب هو القيام به مع استبدال الخط وهو خطأ المصممينوليس المطورين. - Toby
+1Toby لأنه في الواقع هو خطأ المصممين. انها مزعجة للغاية أيضا إذا كنت على رابط بطيء (مثل ، يا dunno ، هاتفي الخلوي أو الهاتف الثابت في المنزل). مثل هذه الأشياء فقط يجعل المواقع أبطأ ويهيج المستخدمين من دون فائدة على الإطلاق. - Magnus
إجابة طويلة: المطورين والمطورين والمطورين والمطورين. - iono
Toby يحدد المصممون الخطوط التي يجب استخدامها ، نعم ، ولكن مهمتها هي كل مطور جيد لاتخاذ الخيارات الصحيحة أثناء التنفيذ التقني. سيفهم المطور الجيد أيضًا سبب حدوثه (موضحًا في الإجابة أعلاه) ، وما هي الخيارات التي يمكن اتخاذها لتجنب المشكلة (Google Webfont Loader) ، وكيف يؤثر ذلك على التجربة. - arbales


باختصار ، هناك الكثير من الكائنات القابلة للتحميل والتي تحتاج إلى تحميلها من HTTP GET منفصلة قبل أن يتم عرض الصفحة ، والاعتماد أكثر على متوسط ​​زمن الوصول كمقياس لصحة الموقع.

يشير الأول إلى كل تلك .css و. js وخطوط الويب التي يتم تحميل الصفحة إليها ، ناهيك عن حقيقة أن العديد من المواقع تحتاج أيضًا إلى استرداد كائنات JSON viea XHR المطلوبة ثم إنشاء HTML من أولئك الذين يستخدمون نوعًا ما من templating.

لكن لماذا لا يلاحظون أن الموقع بطيء؟

ربما لأن لديهم memecache في مكان ما لتسريع الأمور (أو تعتمد فقط على ذاكرة التخزين المؤقت لنظام الملفات) ويقومون بقياس صحتهم للموقع باستخدام متوسط ​​زمن الانتقال. وبالتالي ، يتم إرجاع الكائنات المخزنة مؤقتًا بزاوية 6 mircrosecond وإخفاء حقيقة أن العديد من طلبات GET تستغرق 5000 ميلي ثانية لإكمالها. يجب أن يموت المتوسطات. يحيا عد RTTs على عتبة قصوى مقبولة! يجب أن يكون هذا الرقم 0 أو ، بحكم تعريفه ، RTT غير مقبول.


3
2018-02-13 04:25