ทำไมวันนี้ถึงไม่แสดงข้อความในเว็บไซต์ทันที

ฉันสังเกตเห็นว่าเมื่อเร็ว ๆ นี้หลายเว็บไซต์ช้าที่จะแสดงข้อความของพวกเขา โดยปกติแล้วจะโหลดพื้นหลังภาพและอื่น ๆ แต่ไม่มีข้อความ หลังจากเวลาผ่านไปข้อความจะเริ่มปรากฏขึ้นที่นี่และตรงนั้น (อาจไม่พร้อมกันทุกข้อความในเวลาเดียวกัน)

มันใช้งานได้ตรงกันข้ามกับที่เคยใช้เมื่อข้อความปรากฏขึ้นก่อนจากนั้นภาพและส่วนที่เหลือจะโหลดหลังจากนั้น เทคโนโลยีใหม่ใดที่สร้างปัญหานี้ ความคิดใด ๆ

โปรดทราบว่าฉันใช้การเชื่อมต่อที่ช้าซึ่งอาจเน้นปัญหา

ดูตัวอย่างด้านล่าง - ทุกอย่างถูกโหลด แต่ใช้เวลาไม่กี่วินาทีก่อนที่ข้อความจะปรากฏขึ้นในที่สุด:

เหตุผลหนึ่งคือนักออกแบบเว็บในปัจจุบันต้องการที่จะใช้แบบอักษรเว็บ (โดยปกติในWOFFรูปแบบ) เช่นผ่านอักษรเว็บของ Google

ก่อนหน้านี้ฟอนต์เดียวที่สามารถแสดงบนไซต์ได้คือฟอนต์ที่ผู้ใช้ติดตั้งไว้ในเครื่อง เนื่องจากเช่นผู้ใช้ Mac และ Windows ไม่จำเป็นต้องมีแบบอักษรเหมือนกันนักออกแบบจึงกำหนดกฎไว้โดยสัญชาตญาณเสมอ

font-family: Arial, Helvetica, sans-serif;

โดยที่หากไม่พบตัวอักษรตัวแรกในระบบเบราว์เซอร์จะมองหาตัวที่สองและสุดท้ายก็คือตัวอักษร "sans-serif" ทางเลือกสุดท้าย

ตอนนี้หนึ่งสามารถให้ URL แบบอักษรเป็นกฎ CSS เพื่อรับเบราว์เซอร์เพื่อดาวน์โหลดแบบอักษรเช่น:

@import url(http://fonts.googleapis.com/css?family=Droid+Serif:400,700);

จากนั้นโหลดแบบอักษรสำหรับองค์ประกอบเฉพาะโดยเช่น:

font-family: 'Droid Serif',sans-serif;

สิ่งนี้เป็นที่นิยมอย่างมากที่จะสามารถใช้แบบอักษรที่กำหนดเองได้ แต่มันก็นำไปสู่ปัญหาที่ไม่มีข้อความใดแสดงจนกว่าเบราว์เซอร์จะโหลดทรัพยากรซึ่งรวมถึงเวลาในการดาวน์โหลดเวลาในการโหลดแบบอักษรและเวลาการแสดงผล ฉันคาดหวังว่านี่คือสิ่งประดิษฐ์ที่คุณกำลังประสบ

ตัวอย่างเช่นหนึ่งในหนังสือพิมพ์ระดับชาติของฉันDagens Nyheterใช้แบบอักษรบนเว็บสำหรับพาดหัวของพวกเขา แต่ไม่ใช่โอกาสในการขายของพวกเขาดังนั้นเมื่อโหลดไซต์นั้นฉันมักจะเห็นลูกค้าที่มุ่งหวังคนแรกและครึ่งวินาทีต่อมาช่องว่างด้านบนทั้งหมด พร้อมพาดหัว (เป็นจริงใน Chrome และ Opera อย่างน้อยก็ยังไม่ได้ลองเลย)

(เช่นนักออกแบบโรย JavaScript ทุกวันดังนั้นอาจมีบางคนพยายามทำสิ่งที่ฉลาดด้วยข้อความซึ่งเป็นสาเหตุว่าทำไมมันถึงล่าช้านั่นอาจเป็นเรื่องเฉพาะของไซต์ แต่: แนวโน้มทั่วไปของข้อความที่จะล่าช้าในสิ่งเหล่านี้ ครั้งคือปัญหาแบบอักษรของเว็บที่อธิบายข้างต้นฉันเชื่อว่า.)

ส่วนที่เพิ่มเข้าไป

คำตอบนี้กลายเป็น upvote มากแม้ว่าฉันจะไม่ได้ลงรายละเอียดมากหรืออาจเป็นเพราะเหตุนี้ มีความคิดเห็นมากมายในเธรดคำถามดังนั้นฉันจะพยายามขยายความคิดเห็นเล็กน้อย (ความคิดเห็นจำนวนมากดูเหมือนจะหายไปครู่หนึ่งหลังจากหัวข้อได้รับการปกป้อง - ผู้ดูแลบางคนอาจทำความสะอาดด้วยตนเอง) นอกจากนี้อ่านคำตอบอื่น ๆ ในชุดข้อความนี้ขณะที่พวกเขาขยายในรูปแบบของตนเอง

เห็นได้ชัดว่าปรากฏการณ์นี้เป็นที่รู้จักกันในนาม "แฟลชของเนื้อหาที่ไม่มีการจัดสไตล์" โดยทั่วไปและ "แฟลชของข้อความที่ไม่มีการจัดรูปแบบ" โดยเฉพาะ การค้นหา "FOUC" และ "FOUT" ให้ข้อมูลเพิ่มเติม

ฉันสามารถขอแนะนำโพสต์นักออกแบบเว็บไซต์พอลไอริชใน fout ในการเชื่อมต่อกับเว็บแบบอักษร

สิ่งที่สามารถสังเกตได้คือเบราว์เซอร์ที่แตกต่างกันจัดการสิ่งนี้แตกต่างกัน ฉันเขียนไว้ข้างต้นว่าฉันได้ทดสอบ Opera และ Chrome แล้วซึ่งทั้งสองคนมีพฤติกรรมคล้ายกัน คนที่ใช้ WebKit ทั้งหมด (Chrome, Safari, ฯลฯ ) เลือกที่จะหลีกเลี่ยง FOUT โดยไม่แสดงข้อความตัวอักษรบนเว็บด้วยแบบอักษรสำรองในระหว่างระยะเวลาการโหลดแบบอักษรบนเว็บ แม้ว่าตัวอักษรเว็บแคชมีจะมีความล่าช้าทำให้ มีความคิดเห็นจำนวนมากในกระทู้คำถามนี้ที่พูดเป็นอย่างอื่นและมันไม่ถูกต้องว่าแบบอักษรที่แคชไว้มีลักษณะเช่นนี้ แต่เช่นจากลิงค์ด้านบน:

คุณจะได้รับอะไรในกรณีใดบ้าง

• จะ: การดาวน์โหลดและแสดง ttf / otf / woff ระยะไกล
• จะ:แสดงแคช ttf / otf / woff
• จะ: การดาวน์โหลดและแสดง data-uri ttf / otf / woff
• จะ:แสดงแคชข้อมูล -turi ttf / otf / woff
• จะไม่:แสดงแบบอักษรที่ติดตั้งแล้วและตั้งชื่อแล้วในแบบอักษรสแต็กดั้งเดิมของคุณ
• จะไม่:แสดงแบบอักษรที่ติดตั้งและตั้งชื่อโดยใช้ตำแหน่ง local ()

เนื่องจาก Chrome รอจนกระทั่งความเสี่ยง FOUT หายไปก่อนที่จะแสดงผลสิ่งนี้จึงล่าช้า ซึ่งขอบเขตผลกระทบที่จะมองเห็นได้ (โดยเฉพาะอย่างยิ่งเมื่อโหลดจากแคช) ดูเหมือนว่าจะขึ้นอยู่กับหมู่สิ่งอื่น ๆ จำนวนของข้อความที่จะต้องมีการแสดงผลและบางทีอาจจะมีปัจจัยอื่น ๆ แต่แคชไม่สมบูรณ์ลบผลกระทบ

Irish ยังมีการอัปเดตบางอย่างเกี่ยวกับพฤติกรรมของเบราว์เซอร์ตั้งแต่ 2011–04–14 ที่ด้านล่างของโพสต์:

• Firefox (ตั้งแต่ FFb11 และ FF4 Final) จะไม่มี FOUT! Wooohoo! http://bugzil.la/499292โดยทั่วไปข้อความจะไม่ปรากฏเป็นเวลา 3 วินาทีจากนั้นจะนำแบบอักษรสำรองกลับมา webfont อาจโหลดภายในสามวินาทีแม้ว่า ... หวังว่า ..
• IE9 รองรับ WOFF และ TTF และ OTF (แม้ว่าจะต้องใช้ชุดบิตฝัง - ส่วนใหญ่จะ moot ถ้าคุณใช้ WOFF) อย่างไรก็ตาม !!! IE9 มีข้อผิดพลาด :(
• Webkit มีโปรแกรมแก้ไขที่รอลงจอดเพื่อแสดงข้อความทางเลือกหลังจาก 0.5 วินาที พฤติกรรมเช่นเดียวกับ FF แต่ 0.5 วินาทีแทนที่จะเป็น 3 วินาที
• เพิ่มเติม : Blink มีข้อผิดพลาดในการลงทะเบียนเช่นกันแต่ดูเหมือนว่าฉันทามติขั้นสุดท้ายยังไม่ได้รับการพิจารณาเกี่ยวกับสิ่งที่ต้องทำกับมัน - ขณะนี้การใช้งานแบบเดียวกับ WebKit

หากนี่เป็นคำถามสำหรับนักออกแบบเราสามารถหาวิธีหลีกเลี่ยงปัญหาเหล่านี้ได้เช่นwebfontloaderแต่นั่นจะเป็นอีกคำถามหนึ่ง ลิงค์ Paul Irish มีรายละเอียดเพิ่มเติมเกี่ยวกับเรื่องนี้

เหตุผลนี้เป็นข้อความที่คุณอ่านไม่ออก แต่มีการแสดงผลด้วยแบบอักษรบนเว็บที่ยังคงไหลลงสู่เบราว์เซอร์ของคุณ

นอกจากนี้เนื่องจากเบราว์เซอร์ของคุณคือ Google Chrome ซึ่งใช้ WebKit เพื่อแสดงผลหน้าเว็บพวกเขาจึงตัดสินใจ (WebKit นั่นคือ) ซึ่งเป็นการดีที่สุดสำหรับคุณที่จะไม่เห็นข้อความใด ๆ เลยจนกว่าจะดาวน์โหลดแบบอักษรเว็บ อย่างไรก็ตามหากคุณเป็นนักพัฒนาซอฟต์แวร์ที่ต้องการให้ข้อความอ่านได้ในแบบอักษรระบบถอยกลับที่เหมาะสมคุณสามารถใช้WebFont Loader ของ Googleเพื่อทำสิ่งนี้ได้

คำตอบสั้น ๆ : AJAXหรือWOFF

มีสาเหตุหลายประการของเว็บไซต์เป็น"ช้าเพื่อแสดงข้อความของพวกเขา" ความช้าในพกพานั้นเกิดจากการดาวน์โหลดฟอนต์WOFF แต่สิ่งที่คุณอธิบายเป็นข้อความ "เริ่มปรากฏที่นี่และมี"มากขึ้นมักจะมีสาเหตุมาจากอาแจ็กซ์

เว็บไซต์ประกอบด้วยหลายส่วน วิธีชิ้นส่วนเหล่านี้จะมีการดาวน์โหลดและประกอบเป็นทางเลือกการออกแบบภายใต้การควบคุมของนักออกแบบเว็บไซต์ ความเชื่องช้าเกิดจากการที่นักพัฒนาเลือกที่จะประกอบแบบต่อไปนี้:

• หน้า HTML เริ่มต้น
• CSS
• JS
• ภาพ
• แบบอักษร WOFF
• คำขอ AJAX
• การจัดการ DOM

เว็บไซต์ตามเนื้อผ้า:

ตามเนื้อผ้ามันเป็นเรื่องธรรมดาสำหรับนักพัฒนาที่จะนำเนื้อหาข้อความในหน้า HTML เริ่มต้นและแสดงเร็วที่สุดเท่าที่มีอยู่ HTML จะอ้างอิงทรัพยากรหลายอย่างที่จะดาวน์โหลด เบราว์เซอร์จะวาดหน้าจอใหม่อย่างต่อเนื่องเพื่อรวมสไตล์และรูปภาพเมื่อพร้อมใช้งาน AJAX และ WOFF ไม่สามารถใช้ได้

เว็บไซต์ WOFF:

แบบอักษร WOFF ช่วยให้เว็บไซต์เพื่อใช้แบบอักษรที่ไม่สามารถใช้ได้ตามปกติเพื่อให้เบราว์เซอร์โดยการดาวน์โหลดแบบอักษรกับเว็บไซต์ นักพัฒนาบางคนแนะนำให้เบราว์เซอร์ไม่แสดงเนื้อหาข้อความจนกว่าจะดาวน์โหลดฟอนต์ WOFF ทั้งหมด จากประสบการณ์ของฉันวิธีการนี้ยังไม่ได้รับการใช้อย่างกว้างขวาง

เว็บไซต์ AJAX:

นักพัฒนาบางคนเลือกที่จะไม่รวมเนื้อหาข้อความในหน้า HTML เริ่มต้น แต่พวกเขาเลือกที่จะดาวน์โหลดเนื้อหาข้อความโดยใช้ AJAX สิ่งนี้เกิดขึ้นหลังจากโหลดหน้าพื้นฐานแล้ว จากประสบการณ์ของฉันวิธีนี้ได้รับการยอมรับอย่างกว้างขวางมากกว่าแบบอักษร WOFF และส่วนใหญ่มักเป็นสาเหตุของความเชื่องช้าที่คุณอธิบาย

การหาสาเหตุ

เพื่อหาสาเหตุสำหรับเว็บไซต์ที่เฉพาะเจาะจงต้องใช้การวิเคราะห์โดยใช้เครื่องมือเช่นFirebugหรือChrome เครื่องมือสำหรับนักพัฒนา หรือมิฉะนั้นคุณสามารถเปิดไซต์โดยใช้Internet Explorer 8ซึ่งรองรับ AJAX แต่ไม่ใช่ WOFF หากเว็บไซต์ยังคงช้าปัญหาคือ AJAX และไม่ใช่ WOFF

ฉันมักจะเป็นทางเลือกโดยเจตนาเพื่อหลีกเลี่ยง "แฟลชของเนื้อหาที่ไม่มีการจัดรูปแบบ" หากข้อความที่แสดงก่อนที่จะโหลด CSS คุณจะเห็นข้อความสั้น ๆ ว่ามันดูดิบและแฟลชในขณะที่เบราว์เซอร์วาดใหม่ โดยการใส่สไตล์อินไลน์พื้นฐานเพื่อซ่อนเนื้อหาในขั้นต้นซึ่งถูกแทนที่ในสไตล์ชีทจริงหรือใช้ JS ผู้พัฒนาหลีกเลี่ยงแฟลชนี้

ดังที่คนอื่น ๆ ได้สังเกตเห็นว่าแบบอักษรที่กำหนดเองมีส่วนทำให้เกิดความล่าช้า

เพื่อให้พื้นหลังเพิ่มขึ้นเล็กน้อยเบราว์เซอร์กำลังดำเนินการอย่างคร่าวๆต่อไปนี้ก่อนที่จะสามารถแสดงเนื้อหาของหน้าเว็บไปที่หน้าจอ:

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 -หนึ่งวินาที/

คำตอบสั้น ๆ : นักพัฒนา

เมื่อลิงค์และแท็กสคริปต์ที่อ้างถึงเอกสารภายนอก (เช่นไฟล์. css หรือ. js) ถูกวางไว้ที่ส่วนหัวของเอกสาร (ในโฟลว์สูงกว่าเนื้อความและองค์ประกอบ) จะถูกโหลดก่อน JavaScript เรียกใช้จากมาร์กอัพที่อ้างอิง หากมีรหัสจำนวนมากที่ต้องดำเนินการหรือเป็นรหัสที่ยุ่งยากหรือมากกว่าปกติหากข้อความที่คุณคาดว่าจะเห็นมีการแสดงผลบนเซิร์ฟเวอร์และบรรจุลงในเอกสารขณะโหลด - และรหัสฝั่งเซิร์ฟเวอร์ก็ยุ่งยากเช่นกัน ใหญ่หรือปิดกั้น I / O เนื่องจากการประมวลผลคำขอหลาย ๆ อย่างพร้อมกันคุณอาจสังเกตเห็นการหยุดทำงานก่อนที่ HTML จะมีโอกาสแสดงผลได้ นักพัฒนาบางคนเลือกที่จะโหลด JavaScript ที่ไม่เกี่ยวข้องกับมุมมองหลังจากมาร์กอัปและสไตล์ (ที่ส่วนท้ายของเนื้อหา)

ความเร็วการเชื่อมต่ออินเทอร์เน็ตมีบทบาทในการดาวน์โหลดข้อมูลที่ช้าเห็นได้ชัด แต่รหัสที่เขียนไม่ดีหรือสแต็คเทคโนโลยีที่ออกแบบมาไม่ดี (สำหรับประเภทของเว็บไซต์) มีบทบาทสำคัญมากขึ้นในการโหลดเนื้อหาแบบไดนามิกที่ช้าลง วิธีการแพร่หลาย

สรุปวัตถุที่โหลดได้จำนวนมากเกินไปที่ต้องโหลดจาก HTTP GET แยกต่างหากก่อนจึงจะสามารถแสดงหน้าเว็บได้และการพึ่งพาความหน่วงแฝงมากกว่าโดยเฉลี่ยเพื่อวัดความสมบูรณ์ของไซต์

อันดับแรกอ้างถึง. css, .js และ webfonts ทั้งหมดที่หน้าโหลดไม่ต้องพูดถึงความจริงที่ว่าหลาย ๆ ไซต์จำเป็นต้องดึงข้อมูลวัตถุ JSON viea XHR ร้องขอจากนั้นสร้าง HTML จากการใช้ templating บางประเภท

แต่ทำไมพวกเขาไม่สังเกตเห็นว่าเว็บไซต์ช้า?

อาจเป็นเพราะพวกเขามี memecache ในนั้นเพื่อเพิ่มความเร็ว (หรือพึ่งแคชของระบบไฟล์) และกำลังวัดความสมบูรณ์ของไซต์โดยใช้เวลาแฝงเฉลี่ย ดังนั้นวัตถุที่แคชจะถูกส่งคืนด้วยความหน่วงแฝง 6 มิลลิวินาทีและปกปิดความจริงที่ว่าคำขอ GET จำนวนมากใช้เวลา 5,000 มิลลิวินาทีในการทำให้เสร็จสมบูรณ์ ค่าเฉลี่ยจะต้องตาย ลองใช้การนับ RTT สดกว่าขีด จำกัด สูงสุดที่ยอมรับได้! หมายเลขนั้นควรเป็น 0 หรือโดยนิยาม RTT ไม่สามารถยอมรับได้

มีหลายเหตุผล เหตุผลหนึ่งก็คือคำสั่งเพื่อกำหนดพื้นหลังหรือด้านบนของหน้า html บ่อยครั้งหรือดึงใน CSS แยกต่างหากที่โหลดครั้งแรก ก่อนที่จะโหลดเนื้อหาของเอกสารซึ่งมีข้อความ

อีกสาเหตุคือแม้ว่ามันจะเป็นไปได้ที่จะพิมพ์ขนาดของภาพในกรณีส่วนใหญ่นักออกแบบเว็บไซต์ไม่ได้ใช้ประโยชน์จากมัน ดังนั้นนักบีบอัดจึงต้องโหลดภาพทั้งหมดก่อนในหน้าเว็บเพื่อที่จะได้รู้วิธีตัดข้อความรอบ ๆ

นักออกแบบบางคนยังต้องการแสดงรูปภาพแรกและข้อความถัดไปพวกเขาประสบความสำเร็จด้วยจาวาสคริปต์บางอย่างตัวอย่างเช่นหน้าเว็บที่เรียบง่ายจะแสดงแบนเนอร์ก่อนจากนั้นทุกอย่างอื่นจะอยู่ในนั้น

แต่ถ้าคุณสงสัยว่าทำไมมันถึงมีโฆษณาสแปมในหน้าเว็บของฉันในขณะที่ฉันแค่ต้องการอ่านข่าวก็มีทางออกสำหรับคุณ คุณสามารถใช้ประโยชน์จากตัวป้องกันสแปมหากคุณใช้ Firefox ด้วยโปรแกรมเสริมดังกล่าว webrowser จะรู้ไซต์ที่ให้สแปมและบล็อกพวกมันทำให้การโหลดหน้าเว็บเร็วขึ้นในขณะที่คุณยังสามารถเห็นภาพสำคัญที่เกี่ยวข้องกับบทความที่คุณอ่าน

ฉันขอแนะนำให้ทุกท่านที่จัดการกับการโหลดหน้าช้าเพื่อลอง fidler fidler สามารถใช้กับ IEexplorer หรือกับ FireFox (โดยใช้ฟังก์ชั่นพร็อกซีของมัน) Fidler จะแสดงให้คุณเห็นว่าใช้เวลานานแค่ไหนและเมื่อส่วนต่าง ๆ ของหน้าเว็บถูกโหลด มันเป็นเครื่องมือแก้จุดบกพร่อง HTML