Tại sao các trang web không ngay lập tức hiển thị văn bản của họ những ngày này?

Tôi đã nhận thấy rằng gần đây nhiều trang web chậm hiển thị văn bản của họ. Thông thường, hình nền, hình ảnh sẽ được tải, nhưng không có văn bản. Sau một thời gian, văn bản bắt đầu xuất hiện ở đây và ở đó (không phải lúc nào cũng là tất cả của nó cùng một lúc).

Về cơ bản, nó hoạt động ngược lại như trước đây, khi văn bản được hiển thị đầu tiên, sau đó các hình ảnh và phần còn lại được tải sau đó. Công nghệ mới nào đang tạo ra vấn đề này? Ý tưởng nào không?

Lưu ý rằng tôi đang kết nối chậm, có thể làm nổi bật vấn đề.

Xem ví dụ dưới đây - mọi thứ đã được tải nhưng phải mất thêm vài giây trước khi văn bản cuối cùng được hiển thị:

Một lý do là các nhà thiết kế web hiện nay thích sử dụng phông chữ web (thường ở định dạng WOFF ), ví dụ như thông qua phông chữ Google Web .

Trước đây, các phông chữ duy nhất có thể được hiển thị trên một trang web là những phông chữ mà người dùng đã cài đặt cục bộ. Vì người dùng Mac và Windows không nhất thiết phải có cùng một phông chữ, theo bản năng, các nhà thiết kế luôn xác định các quy tắc là

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

trong đó, nếu phông chữ đầu tiên không được tìm thấy trên hệ thống, trình duyệt sẽ tìm phông chữ thứ hai và cuối cùng là phông chữ "sans-serif" dự phòng.

Bây giờ, người ta có thể cung cấp một URL phông chữ dưới dạng quy tắc CSS để khiến trình duyệt tải xuống một phông chữ, như sau:

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

và sau đó tải phông chữ cho một phần tử cụ thể bằng cách:

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

Điều này rất phổ biến để có thể sử dụng phông chữ tùy chỉnh, nhưng nó cũng dẫn đến một vấn đề là không có văn bản nào được hiển thị cho đến khi tài nguyên được trình duyệt tải, bao gồm thời gian tải xuống, thời gian tải phông chữ và thời gian kết xuất. Tôi hy vọng rằng đây là hiện vật mà bạn đang trải nghiệm.

Ví dụ: một trong những tờ báo quốc gia của tôi, Dagens Nyheter , sử dụng phông chữ web cho tiêu đề của họ, nhưng không phải là khách hàng tiềm năng của họ, vì vậy khi trang web đó được tải, tôi thường thấy các khách hàng tiềm năng trước và nửa giây sau tất cả các khoảng trống ở trên được điền với các tiêu đề (điều này đúng với Chrome và Opera, ít nhất là. Đã không thử người khác).

(Ngoài ra, các nhà thiết kế đã rắc JavaScript hoàn toàn ở mọi nơi trong những ngày này, vì vậy có thể ai đó đang cố gắng làm điều gì đó thông minh với văn bản, đó là lý do tại sao nó bị trì hoãn. Tuy nhiên, đó sẽ là một trang web cụ thể bị trì hoãn trong những điều này lần này là vấn đề phông chữ web được mô tả ở trên, tôi tin.)

Thêm vào

Câu trả lời này đã trở nên rất khích lệ, mặc dù tôi không đi sâu vào chi tiết, hoặc có lẽ vì điều này. Đã có nhiều bình luận trong chuỗi câu hỏi, vì vậy tôi sẽ cố gắng mở rộng một chút (rất nhiều ý kiến ​​dường như đã biến mất một thời gian ngắn sau khi chủ đề được bảo vệ - một số người điều hành có thể tự làm sạch chúng). Ngoài ra, đọc các câu trả lời khác trong chủ đề này vì tất cả đều mở rộng theo cách riêng của họ.

Hiện tượng này rõ ràng được gọi là "flash của nội dung chưa được lọc" nói chung và "flash của văn bản chưa được lọc" nói riêng. Tìm kiếm "FOUC" và "FOUT" cung cấp thêm thông tin.

Tôi có thể đề xuất bài đăng của nhà thiết kế web Paul Irish về FOUT liên quan đến phông chữ web .

Điều người ta có thể lưu ý là các trình duyệt khác nhau xử lý việc này khác nhau. Tôi đã viết ở trên rằng tôi đã thử nghiệm Opera và Chrome, cả hai đều cư xử tương tự nhau. Tất cả những cái dựa trên WebKit (Chrome, Safari, v.v.) chọn để tránh FOUT bằng cách không hiển thị văn bản phông chữ web bằng phông chữ dự phòng trong thời gian tải phông chữ web. Ngay cả khi phông chữ web được lưu trữ, sẽ có độ trễ kết xuất . Có rất nhiều ý kiến ​​trong chuỗi câu hỏi này nói khác đi và thật sai lầm khi các phông chữ được lưu trong bộ nhớ cache hoạt động như thế này, nhưng ví dụ từ liên kết trên:

Trong trường hợp nào bạn sẽ nhận được một KHÔNG

• Will: Tải xuống và hiển thị một ttf / otf / woff từ xa
• Will: Hiển thị một ttf / otf / woff được lưu trữ
• Will: Tải xuống và hiển thị dữ liệu-uri ttf / otf / woff
• Will: Hiển thị dữ liệu được lưu trong bộ nhớ cache-uri ttf / otf / woff
• Sẽ không: Hiển thị phông chữ đã được cài đặt và đặt tên trong ngăn xếp phông chữ truyền thống của bạn
• Sẽ không: Hiển thị phông chữ được cài đặt và đặt tên bằng vị trí local ()

Vì Chrome chờ cho đến khi hết rủi ro FOUT trước khi kết xuất, điều này sẽ gây ra sự chậm trễ. Mà mức độ hiệu quả là nhìn thấy được (đặc biệt là khi tải từ bộ nhớ cache) có vẻ là phụ thuộc vào trong số những thứ khác, số lượng văn bản mà cần phải được trả lại và các yếu tố có lẽ khác, nhưng bộ nhớ đệm không hoàn toàn loại bỏ các hiệu ứng.

Ailen cũng có một số cập nhật liên quan đến hành vi của trình duyệt kể từ 2011 2011041414 ở cuối bài:

• Firefox (kể từ FFb11 và FF4 Final) không còn FERE! Wooohoo! http://ormszil.la/499292 Về cơ bản văn bản là vô hình trong 3 giây, và sau đó nó mang lại phông chữ dự phòng. Webfont có thể sẽ tải trong vòng ba giây mặc dù rất hy vọng ..
• IE9 hỗ trợ WOFF và TTF và OTF (mặc dù nó yêu cầu một thứ thiết lập bit nhúng - chủ yếu là moot nếu bạn sử dụng WOFF). TUY NHIÊN!!! IE9 có một KHÔNG. :
• Webkit có một bản vá đang chờ hạ cánh để hiển thị văn bản dự phòng sau 0,5 giây. Vì vậy, hành vi tương tự như FF nhưng 0,5 giây thay vì 3 giây.
• Ngoài ra : Blink cũng có một lỗi được đăng ký cho vấn đề này , nhưng có vẻ như chưa đạt được sự đồng thuận cuối cùng về việc phải làm gì với nó - hiện đang thực hiện giống như WebKit.

Nếu đây là một câu hỏi dành cho các nhà thiết kế, người ta có thể tìm cách tránh các loại vấn đề này webfontloader, nhưng đó sẽ là một câu hỏi khác. Liên kết Paul Ailen đi sâu vào chi tiết hơn về vấn đề này.

Lý do cho điều này là văn bản bạn không thể đọc được đang được hiển thị với một phông chữ web vẫn đang trên đường dẫn đến trình duyệt của bạn.

Ngoài ra, vì trình duyệt của bạn là Google Chrome, sử dụng WebKit để hiển thị trang, nên họ đã quyết định rằng tốt nhất là bạn không nên xem bất kỳ văn bản nào cho đến khi phông chữ web được tải xuống. Tuy nhiên, nếu bạn là nhà phát triển muốn văn bản có thể đọc được bằng phông chữ hệ thống dự phòng phù hợp thay vào đó, thì bạn có thể sử dụng một cái gì đó như Trình tải WebFont của Google để đạt được điều này.

Câu trả lời ngắn: AJAX hoặc WOFF

Có một số nguyên nhân khiến các trang web "chậm hiển thị văn bản" . Các sự chậm chạp trên portableapps.com được gây ra bằng cách tải WOFF phông chữ. Tuy nhiên, những gì bạn mô tả là "văn bản bắt đầu xuất hiện ở đây và ở đó" thường do AJAX gây ra .

Một trang web được tạo thành từ nhiều phần. Làm thế nào các phần này được tải xuống và lắp ráp là một lựa chọn thiết kế dưới sự kiểm soát của nhà thiết kế web . Sự chậm chạp được gây ra bởi cách nhà phát triển chọn để lắp ráp các khối xây dựng sau:

• Trang HTML ban đầu
• CSS
• JS
• Hình ảnh
• Phông chữ WOFF
• Yêu cầu AJAX
• Thao tác DOM

Các trang web truyền thống:

Theo truyền thống, thông thường các nhà phát triển sẽ đưa nội dung văn bản vào trang HTML ban đầu và hiển thị nội dung đó ngay khi có sẵn . HTML sẽ tham chiếu một số tài nguyên sau đó sẽ được tải xuống. Trình duyệt sau đó sẽ dần dần vẽ lại màn hình để bao gồm các kiểu và hình ảnh khi chúng có sẵn. AJAX và WOFF không có sẵn.

Trang web của WOFF:

Phông chữ WOFF cho phép một trang web sử dụng các phông chữ thường không có sẵn cho trình duyệt, bằng cách tải xuống các phông chữ với trang web . Một số nhà phát triển hướng dẫn trình duyệt không hiển thị nội dung văn bản cho đến khi tất cả các phông chữ WOFF đã được tải xuống. Theo kinh nghiệm của tôi, cách tiếp cận này chưa được sử dụng rất rộng rãi.

Trang web AJAX:

Một số nhà phát triển chọn không đưa nội dung văn bản vào trang HTML ban đầu. Thay vào đó, họ chọn tải xuống nội dung văn bản bằng AJAX. Điều này xảy ra sau khi trang cơ bản đã được tải . Theo kinh nghiệm của tôi, phương pháp này đã được áp dụng rộng rãi hơn nhiều so với phông chữ WOFF và thường là nguyên nhân của sự chậm chạp mà bạn mô tả.

Xác định nguyên nhân

Để xác định nguyên nhân cho một trang web cụ thể, cần phải phân tích bằng các công cụ như Fireorms hoặc Chrome Developer Tools . Hoặc cách khác, bạn có thể mở trang web bằng Internet Explorer 8 , hỗ trợ AJAX nhưng không hỗ trợ WOFF. Nếu trang web vẫn chậm, vấn đề là AJAX chứ không phải WOFF.

Tôi thường có thể là một sự lựa chọn có chủ ý để tránh "flash nội dung không được chỉnh sửa". Nếu văn bản được hiển thị trước khi CSS được tải, bạn sẽ thấy ngay khi nó xuất hiện ở dạng thô và sau đó là đèn flash khi trình duyệt vẽ lại. Bằng cách đưa vào một số kiểu nội tuyến cơ bản để ban đầu ẩn nội dung, được ghi đè trong biểu định kiểu thực tế hoặc sử dụng JS, các nhà phát triển sẽ tránh được đèn flash này.

Như những người khác đã lưu ý, phông chữ tùy chỉnh có thể góp phần vào sự chậm trễ.

Để cung cấp thêm một chút nền tảng, trình duyệt đang thực hiện các thao tác sau đây trước khi có thể hiển thị nội dung trang ra màn hình:

1. tìm nạp HTML (một số chuyến đi khứ hồi cho DNS, TCP, yêu cầu / phản hồi)
2. bắt đầu phân tích HTML, khám phá các tài nguyên bên ngoài như CSS và JS bên ngoài. Lưu ý rằng CSS chặn bố cục và phân tích khối JS. Vì vậy, các tài nguyên bên ngoài như CSS và JS được tải sớm trong tài liệu (ví dụ như trong phần đầu) làm chậm thời gian để một trang hiển thị nội dung trên màn hình.
3. tìm nạp CSS và JS bên ngoài (một số chuyến đi khứ hồi: DNS và TCP nếu các tài nguyên này nằm trên một miền khác như CDN, cũng như RTT cho yêu cầu / phản hồi)
4. khi CSS và JS bên ngoài đã tải xong, phân tích / thực thi JS, phân tích / áp dụng các kiểu
5. nếu CSS tạo tham chiếu đến các phông chữ tùy chỉnh, thì các phông chữ đó giờ cũng phải được tải xuống, dẫn đến độ trễ chuyến đi khứ hồi bổ sung để hiển thị bất kỳ phần nào của trang phụ thuộc vào phông chữ tùy chỉnh

Mặc dù đó không phải là về sự chậm trễ do phông chữ tùy chỉnh cụ thể, tôi đã viết một bài đăng blog gần đây cung cấp thông tin bổ sung về nguyên nhân của sự chậm trễ kết xuất. Nó đưa ra một số gợi ý để giảm thiểu thời gian vẽ đầu tiên cho các trang của bạn. Hy vọng rằng điều này hữu ích cho những người đọc quan tâm đến việc làm cho trang của họ hiển thị nội dung nhanh hơn, bao gồm cả những trang muốn sử dụng phông chữ tùy chỉnh: http://calWiki.perfplanet.com/2012/make-your-mobile-pages-render-in-under -một giây/

Câu trả lời ngắn gọn: Nhà phát triển.

Khi các thẻ liên kết và tập lệnh tham chiếu các tài liệu bên ngoài (như tệp .css hoặc .js) được đặt trong phần đầu của tài liệu (dòng cao hơn phần thân và các phần tử của nó), chúng sẽ được tải trước. JavaScript thực thi từ đánh dấu tham chiếu nó; nếu có nhiều mã để xử lý, hoặc đó là mã rườm rà hoặc phổ biến hơn nếu văn bản bạn muốn thấy được hiển thị trên máy chủ và được đưa vào tài liệu khi tải - và mã phía máy chủ đó cũng cồng kềnh, lớn hoặc chặn I / O do xử lý một số yêu cầu đồng thời, bạn chắc chắn có thể nhận thấy thời gian chết trước khi HTML có cơ hội kết xuất. Một số nhà phát triển chọn tải JavaScript không liên quan đến chế độ xem sau khi đánh dấu và kiểu (ở cuối phần thân),

Tốc độ kết nối Internet đóng vai trò trong việc tải xuống dữ liệu chậm, rõ ràng, nhưng mã được viết kém hoặc ngăn xếp công nghệ được thiết kế kém (đối với loại trang web) đóng vai trò ngày càng trung tâm trong việc tải nội dung động chậm, vì kết nối mạng nhanh hơn tiếp cận có mặt khắp nơi.

Tóm lại, có quá nhiều đối tượng có thể tải cần được tải từ các HTTP GET riêng biệt trước khi trang có thể được hiển thị và sự phụ thuộc quá mức vào độ trễ trung bình là thước đo sức khỏe của trang web.

Đầu tiên đề cập đến tất cả các .css, .js và webfont mà trang tải, chưa kể đến việc nhiều trang web cũng cần truy xuất các đối tượng JSON viea XHR và sau đó tạo HTML từ những người sử dụng một kiểu tạo khuôn mẫu nào đó.

Nhưng tại sao họ không nhận thấy rằng trang web chậm?

Có lẽ bởi vì họ có memecache ở đâu đó để tăng tốc mọi thứ (hoặc chỉ dựa vào bộ đệm hệ thống tập tin) và đang đo sức khỏe trang web của họ bằng độ trễ trung bình. Do đó, các đối tượng được lưu trong bộ nhớ cache được trả về với độ trễ 6 mircrosecond và che giấu thực tế là nhiều yêu cầu GET mất 5000 mili giây để hoàn thành. Trung bình phải chết. Sống lâu việc đếm RTT trên ngưỡng tối đa chấp nhận được! Con số đó phải là 0 hoặc theo định nghĩa, RTT là không thể chấp nhận được.

Vâng có nhiều lý do. Một lý do cũng là các lệnh để xác định nền hoặc trên đầu trang html thường xuyên hoặc được truy xuất trong một CSS riêng được tải trước tiên. trước khi phần thân của tài liệu được tải có chứa văn bản.

Một nguyên nhân khác là mặc dù có thể nhập kích thước của hình ảnh trong hầu hết các trường hợp, các nhà thiết kế web không sử dụng điều đó. Và vì vậy, brouwser phải tải toàn bộ hình ảnh đầu tiên trên các trang để nó biết cách bọc văn bản xung quanh nó.

Một số nhà thiết kế, cũng muốn hiển thị hình ảnh đầu tiên và văn bản tiếp theo, họ đạt được điều đó bằng một số javascript, ví dụ như một trang đơn giản sẽ hiển thị một biểu ngữ và sau đó mọi thứ khác trên đó.

Nhưng nếu bạn tự hỏi tại sao có quá nhiều thư rác thương mại trên các trang của tôi trong khi tôi chỉ muốn đọc tin tức, thì có một giải pháp cho bạn. Bạn có thể sử dụng các công cụ chặn thư rác nếu bạn sử dụng firefox. Với một addon như vậy, trình duyệt web biết các trang web cung cấp thư rác và chỉ cần chặn chúng, dẫn đến tải trang nhanh hơn nhiều, trong khi bạn vẫn có thể xem các hình ảnh quan trọng liên quan đến các bài viết bạn đọc.

Tôi sẽ giới thiệu với tất cả các bạn, những người đối phó với việc tải trang chậm để thử fidler. fidler có thể được sử dụng với IEexplorer hoặc với FireFox (sử dụng chức năng proxy của nó) Fidler thực sự sẽ cho bạn thấy thời gian thực sự mất bao lâu và khi các phần của trang web được tải. Nó là một công cụ gỡ lỗi HTML.