• Thời gian phản hồi của máy chủ (server response time) là lượng thời gian cần thiết để máy chủ web phản hồi yêu cầu (request) từ trình duyệt.

Không thành vấn đề trang web của bạn được tối ưu hóa tốc độ như thế nào, nếu máy chủ web của bạn phản hồi chậm thì trang web của bạn sẽ hiển thị chậm.

Google nói rằng: Bạn cần phải giảm thời gian phản hồi của máy chủ xuống dưới 200ms (0,2 giây). Xem thêm hướng dẫn tăng tốc website theo Google Speed Insights.

Làm thế nào để cải thiện thời gian phản hồi của máy chủ?

Có hai cách cơ bản:

• Học hỏi – để sử dụng hosting của bạn hiệu quả hơn (hãy tiếp tục đọc)
• Chi tiền – chi trả nhiều hơn cho hosting và phần cứng

Bài viết này sẽ giúp bạn xác định được điều gì là tốt nhất trong tình huống của bạn. Cũng như mọi thứ khác với người quản trị web, đây là quyết định giữa thời gian & tiền bạc.

Các yếu tố tác động đến thời gian phản hồi máy chủ?

Có bốn yếu tố chính kết hợp với nhau để xác định thời gian phản hồi máy chủ web của bạn:

• Lưu lượng truy cập web – Càng nhiều truy cập, càng nhiều vấn đề.
• Tài nguyên website sử dụng – Nếu mỗi trang web của bạn sử dụng ít tài nguyên hơn, bạn có thể cải thiện thời gian phản hồi máy chủ và không tốn kém tiền của.
• Phần mềm máy chủ web – Nếu bạn thay đổi phần mềm máy chủ web hoặc chỉnh sửa cấu hình đúng cách bạn có thể cải thiện thời gian phản hồi máy chủ và không tốn kém tiền của.
• Web hosting – Nếu bạn có thể cải thiện chất lượng của web hosting bạn có thể cải thiện thời gian phản hồi máy chủ nhưng lần này bạn sẽ phải chi thêm tiền.

Lưu lượng truy cập website

Khi một trang web có nhiều lưu lượng truy cập hơn, nó sử dụng nhiều tài nguyên máy chủ hơn. Một trang web khi có ít truy cập có thể lướt nhanh chóng, nhẹ nhàng, nhưng khi lưu lượng truy cập tăng lên nó có thể trở nên chậm chạp, ì ạch.

Lưu lượng truy cập ảnh hưởng đến thời gian phản hồi máy chủ như thế nào?

Giống như một cửa hàng bán đồ ăn, một máy chủ web chỉ có thể phục vụ một số người nhất định tại một thời điểm. Thời gian phục vụ cho mỗi người càng dài, càng có ít người được phục vụ. Càng nhiều nguồn tài nguyên được dùng để phục vụ mọi người sẽ có càng ít tài nguyên cho những thứ hỗ trợ đằng sau như PHP hoặc những thứ khác có thể cần để phục vụ người dùng của bạn.

Trong vấn đề cửa hàng ăn, nếu có càng nhiều người đứng ở quầy để nhận đơn hàng thì sẽ càng có ít người tương ứng ở bếp để nấu năn.

Sử dụng tài nguyên trang web

Từng thứ mà trang web của bạn sử dụng để hiển thị sẽ bổ sung thêm ít nhiều gánh nặng cho máy chủ đang dùng. Trung bình một theme WordPress có khả năng sẽ tải một số stylesheet, vài đoạn javascript và các tài nguyên khác từ máy chủ của bạn như ảnh chẳng hạn.

Điều đó có nghĩa là mỗi lượt truy cập website bạn có khả năng sử dụng máy chủ web hàng chục lần. Điều đó cộng dồn lại.

Giá trị của việc sử dụng ít nguồn tài nguyên cho mỗi lần xem trang

Bây giờ tôi sẽ đưa ra một ví dụ được đơn giản hóa đi rất nhiều. Giả dụ một máy chủ web có khả năng xử lý chính xác 100 yêu cầu mỗi giây. Trong một giây bạn có thể phục vụ…

• Bốn người ghé thăm trang, mỗi người sử dụng 25 tài nguyên
• Mười người ghé thăm trang, mỗi người sử dụng 10 tài nguyên
• Hai mươi năm người ghé thăm trang, mỗi người sử dụng 4 tài nguyên
• Một trăm người ghé thăm trang không sử dụng tài nguyên bổ sung

Trong ví dụ rất đơn giản hóa này, người quản trị web sử dụng tài nguyên trang một cách khôn ngoan có thể cải thiện sức chứa của máy chủ hơn rất nhiều. Không những máy chủ web có khả năng phục vụ được nhiều hơn, nó còn phản hồi nhanh hơn, bởi vì yêu cầu tải của nó đã giảm xuống.

Để biết được có bao nhiêu yêu cầu mà trang của bạn tạo ra, bạn có thể sử dụng công cụ này: https://varvy.com/tools/requests/ nó sẽ cho bạn biết có bao nhiêu nguồn tài nguyên trang sử dụng mỗi khi nó được tải.

Làm thế nào để giảm lượng tài nguyên trang sử dụng

Trang của bạn càng sử dụng ít tài nguyên như css, javascript, vân vân nó càng tải nhanh hơn và làm giảm căng thẳng cho máy chủ web.

• Kết hợp các file CSS ngoài – Nhiều theme và các thiết kế khác chia tách CSS thành nhiều file khác nhau, nhưng tất cả CSS có thể được kết nối thành một file, nhờ thế trang sẽ gọi ít tài nguyên hơn
• Kết hợp các file javascript ngoài – Cũng giống như CSS, javascript trang bạn sử dụng có thể được đặt hết vào trong html hoặc trong một file kết hợp bên ngoài. Nhưng thường thì chúng lại được chia tách và điều này có thể tạo ra các lần gọi tới máy chủ lãng phí
• Tải lười / Trì hoãn tải ảnh – Trì hoãn tải ảnh làm trang web của bạn hiển thị nhanh hơn do không phải tốn thời gian gọi và tải xuống từng bức ảnh trước khi hiển thị trang.
• Nội tuyến các CSS và Javscript nhỏ – Trong một số trường hợp, bạn thậm chí không cần có CSS và Javascript ở file bên ngoài làm gì. Nếu bạn thêm chúng vào trong chính file HTML, thì bạn đã giảm được nhiều lần gọi rồi. Tôi có thảo luận về cách làm điều này với CSS và Javascript ở các bài tương ứng.
• Sử dụng keep-alive một cách khôn ngoan – Đảm bảo rằng bạn biết máy chủ web của bạn đang sử dụng keep-alive như thế nào, vì nó có thể thực sự ảnh hưởng đến cách máy chủ của bạn đáp ứng yêu cầu.

Tuân thủ các thực hành đúng để tăng tốc độ website sẽ giúp bạn gia tăng số lượng người mà máy chủ của bạn có thể phục vụ. Giảm số lượng các file mỗi trang cần gọi sẽ giúp giảm gánh nặng công việc mà máy chủ cần làm.

Web hosting

Cần đảm bảo rằng bạn có máy chủ web thích hợp cho nhiệm vụ. Bước đầu tiên cần đảm bảo là bạn không làm các nguồn tài nguyên của mình quá mỏng manh.

Nếu bạn giống tôi, bạn cũng sẽ bắt đầu mua một host rẻ nhất có thể.

Nếu đúng như vậy, nếu giờ bạn có nhiều lưu lượng truy cập hơn bạn sẽ phải nâng cấp hosting của mình. Dưới đây là một số suy nghĩ và gợi ý tổng quan của tôi về vấn đề lựa chọn hosting.

WordPress hosting

Sự thật là nếu bạn sử dụng WordPress sẽ là khôn ngoan nếu bạn mua hosting chuyên cho WordPress. Hosting kiểu này sẽ được tối ưu hóa để giải quyết các vấn đề thường hay đi kèm với WordPress và rắc rối liên quan đến nội dung động. Một host WordPress tốt thường có giá khởi điểm từ 20 đến 30 đô la một tháng.

• WP Engine
• Dreampress

Share hosting

Share hosting là lựa chọn có tính kinh tế cho người mới. Nhìn chung tôi nghĩ rằng share host tốt sẽ có giá quanh mốc 5 đô la một tháng. Bạn có thể có gói hosting rẻ hơn, nhưng hãy cẩn thận với những lời quảng cáo kiểu như “hosting 99 cent” hoặc điều gì đó tương tự trừ khi nó là một giao dịch cụ thể.

Một công ty cung cấp dịch vụ share host có thể tin cậy được cần phải có mặt trong thị trường vài năm rồi và phải có số điện thoại để bạn có thể liên hệ trong trường hợp cần giúp đỡ. Một vài công ty bán share host mà tôi tin cậy là…

• Bluehost – Tôi từng sử dụng Bluehost nhiều năm rồi (trong thực tế chính website này lúc bắt đầu “lên sóng” năm 2006, tôi đã sử dụng gói share host của Bluehost cho nó) – ý là website Varvy, website gốc của bài tiêng Anh này.
• Siteground và Stablehost là hai công ty host khác tôi thấy chất lượng ổn và giá hợp lý /

VPS hosting

Virtual Private Server / Máy chủ ảo riêng, viết tắt là VPS là bước kế tiếp sau khi bạn bước ra khỏi thế giới share host. Nó có thể yêu cầu nhiều kiến thức, hiểu biết hơn nếu bạn dùng gói VPS tiết kiệm, kinh tế hoặc bạn cần chi phí nhiều hơn để trả cho gói “VPS được quản lý/Managed VPS host”. Giá của VPS giao động trong khoảng từ 20 đến 50 đô la một tháng cho dịch vụ thông thường, nhiều hơn nếu bạn cần nhiều tính năng hơn.

• KnownHost – Hiện tôi sử dụng VPS SSD của Knownhost cho trang này. Họ cung cấp gói VPS rất ổn định và chắn chắn.

Máy chủ chuyên dụng / Dedicated Server

Một máy chủ chuyên dụng là máy chủ của riêng bạn, và chỉ bạn sử dụng. Nó là bước kế tiếp sau khi bạn vượt qua giai đoạn sử dụng VPS. Giống như VPS, máy chủ chuyên dụng có hai loại là kiểu được quản lý và không được quản lý (nếu bạn biết cách làm việc với máy chủ). Máy chủ chuyên dụng có chất lượng thường có giá từ 90 đến 100 đô la trên tháng. Một số công ty ổn là:

• Wired Tree
• KnowHost

Cloud server / Máy chủ đám mây

Nếu bạn không cần giao diện điều khiển (như kiểu cPanel) và bạn biết cách thao tác thì bạn có thể dùng Cloud server. Đó là các lựa chọn tốt khi mà bạn muốn kiểm tra hoặc tạo một máy chủ cho các ứng dụng. Tôi đã từng sử dụng chúng toàn thời gian cho một số dự án. Lựa chọn tốt:

• Digital Ocean (gợi ý của Varvy)
• Vultr (gợi ý của Đức Anh)

Mạng phân phối nội dung / CDN

CDN sẽ lưu trữ các file của bạn khắp mọi nơi trên thế giới. Điều này cho phép người dùng ở mọi nơi truy cập được trang web của bạn nhanh hơn bởi vì họ nhận được file từ máy chủ gần hơn với vị trí địa lý của họ.

CDN là lựa chọn tốt khi người dùng của bạn ở khắp mọi nơi trên thế giới hoặc ở một quốc gia rộng lớn. Lấy ví dụ, nếu website của bạn được host ở bờ biển phía đông hoặc bờ biển phía tây Hoa Kỳ, bạn sẽ nhận ra là người dùng ở những nơi khác sẽ thấy sự cải thiện tốc độ nếu bạn bổ sung CDN.

WordPress / PHP sử dụng

Các trang WordPress đều sử dụng PHP. Hầu hết các trang này có thời gian phản hồi máy chủ thấp bởi vì thay vì chỉ xử lý một file, máy chủ phải thực hiện các bước kế tiếp khác, thu thập thêm tài nguyên và hoàn thành các nhiệm vụ trước khi phản hồi lại yêu cầu của trình duyệt.

Có càng nhiều thứ mà máy chủ của bạn phải làm để phục vụ người dùng, nó sẽ càng phản hồi chậm hơn cho những người khác. Vì thế nếu bạn có một đoạn mã php trên trang web, bạn cần đảm bảo rằng thứ mà PHP làm phải quan trọng hơn cái giá phải trả là làm trang tải chậm đi.

Cách PHP làm việc về cơ bản là nó sẽ phải hoàn thành hết các tác vụ PHP trước khi trang có thể được hiển thị. Thậm chí nếu bạn có cố “đẩy” nội dung cho người dùng, máy chủ vẫn phải đọc và làm theo các hướng dẫn PHP đó. Có một số lượng đáng ngạc nhiên các website sử dụng PHP không hiệu quả mà chúng có thể thậm chí không cần sử dụng đến nó.

Thời gian cho byte đầu tiên / TTFB / Time to first byte

Thời gian cho byte đầu tiên là lượng thời gian trình duyệt phải đợi để nhận được phản hồi từ máy chủ của bạn sau khi một yêu cầu được gửi đi.

Caching và cấu hình máy chủ web là các yếu tố chủ yếu trong TTFB. Tôi cũng đã viết một bài viết riêng về chủ đề này (xêm thêm: TTFB là gì).

Caching

Người dùng WordPress cần phải đảm bảo rằng họ có thực hiện giải pháp caching. Đây có thể là một bước hiệu quả nhất mà người dùng WordPress có thể thực hiện để đẩy nhanh tốc độ trang của họ và làm máy chủ web thoát khỏi những việc không cần thiết. Để cải thiện hiệu suất hãy thử plugin W3 Total Cache hoặc WP Super Cache.

Lựa chọn và Cấu hình phần mềm máy chủ web

Bạn có chắc là mình sử dụng đúng phần mềm máy chủ web không? Có một vài lựa chọn, và hầu hết chúng đều miễn phí. Ở đây tôi sẽ trình bày một số chọn lựa phổ biến hơn mà tôi từng có kinh nghiệm sử dụng.

• Apache
• Nginx
• Litespeed

Không thành vấn đề là bạn đang sử dụng phần mềm máy chủ web nào, nó đều có khả năng tinh chỉnh đề phù hợp tốt hơn cho mục tiêu riêng của bạn. Nếu bạn không có đủ kiến thức về máy chủ web đang dùng đủ để chỉnh sửa nó, bạn có thể phải thuê ai đó giúp mình.

Chúng ta sẽ cùng xem một số ưu và nhược điểm của từng máy chủ web.

Apache

Apache miễn phí và hiện được sử dụng nhiều nhất để làm máy chủ web. Bởi vì nó sử dụng rất tốt, ngoài ra nó cũng có nhiều tài liệu hướng dẫn phong phú. Một vài khóa học hướng dẫn khá hay trên kinda khuyên bạn nên dùng Apache bởi vì nó được sử dụng bởi tất cả mọi website cách đây không lâu. Cài đặt mặc định của Apache không cho hiệu năng tốt nhất, nhưng nó có nhiều người sử dụng và modules cũng như các add on bổ sung để có thể làm được bất cứ điều gì.

Mục tiêu hiện tại là cải thiện thời gian đáp ứng của máy chủ, và Apache có khả năng cấu hình (tinh chỉnh) cao và rất nhiều người biết cách làm nó thế nào. Apache là lựa chọn an toàn (safe bet) cho bất kỳ trang web nào, nhưng nó cần phải được cấu hình tốt bởi người có kiến thức để phần mềm máy chủ này phát huy tốt nhất khả năng. So với các phần mềm máy chủ web khác, PHP chạy trên Apache với tốc độ trung bình.

Nginx

Máy chủ web Nginx miễn phí và nó là con cưng của hầu hết các trang web có lưu lượng truy cập lớn và cho cả những người lập trình web, bởi vì nó có hiệu năng đáng mơ ước ngay cả khi chỉ sử dụng cài đặt mặc định. Nginx sử dụng ít tài nguyên và vì thế có thể xử lý nhiều lưu lượng truy cập hơn bất kỳ máy chủ web nào khác. Nginx thường có thời gian phản hồi máy chủ nhanh nhất theo kinh nghiệm của tôi. PHP chạy rất nhanh khi sử dụng cùng Nginx.

Litespeed

Máy chủ web Litespeed có cả phiên bản miễn phí và trả phí. Nó nhanh hơn nhiều và có hiệu năng tốt hơn Apache, kèm với lợi ích bổ sung là hoàn toàn tương thích với Apache. Bất kỳ chỉnh sửa cấu hình nào bạn thực hiện với Apache cũng được sử dụng lại bởi Litespeed và nó cũng sử dụng cùng file .htaccess giống như Apache. Điều này nghĩa là việc chuyển sang Litespeed sẽ ít phiền toái hơn nhiều cho người dùng Apache. PHP chạy nhanh hơn đến sáu lần với Litespeed.

Tôi có thể sử dụng điều này thế nào để cải thiện thời gian phản hồi máy chủ?

Tóm lại… Bạn có thể cải thiện đáng kể thời gian phản hồi máy chủ bằng cách thay đổi phần mềm máy chủ web hoặc tinh chỉnh cấu hình nó tốt hơn.

Nếu bạn có tiền, hãy thuê ai đó chỉnh cấu hình mà bạn có hoặc quyết định nên sử dụng cái gì. Nếu bạn không có tiền, bạn buộc phải học hỏi về chúng và tự quyết định lấy cho bản thân mình. Trong thực tế tôi sẽ nói rằng một trong các lợi thế lớn của người không có tiền vượt cả các công ty to bự là khả năng học hỏi, thay đổi và trải nghiệm.

Lựa chọn đúng máy chủ web có thể giải quyết nhiều vấn đề về tốc độ khác chỉ trong một bước và có thể cải thiện rất nhiều thời gian phản hồi máy chủ của bạn. Nó có nghĩa là bạn sẽ phải học hỏi và nghiên cứu. Nhưng bạn có thể làm điều đó.

Nên học cách sử dụng máy chủ nào?

Nhìn chung tôi khuyên bạn học Nginx (miễn phí). Nó là một kỹ năng rất tuyệt nếu bạn học được. Nó cũng có hiệu suất đáng kinh ngạc. Tôi không nghĩ ra được nhiều tình huống mà WordPress cài trên Apache sẽ không cải thiện được đáng kể hiệu năng chỉ bằng cách đơn giản là chuyển sang cài Nginx mà thôi. Tôi đã có được kết quả tuyệt vời với nó, và nó dường như đang chiếm lĩnh các trang web hàng đầu trên thế giới internet.

(Dịch từ bài viết: Server response time – Tác giả: Patrick Sexton – Website: Varvy)

The post Giảm thời gian phản hồi của máy chủ web như thế nào appeared first on Unest.

Máy bàn với màn hình rộng, khác biệt rất nhiều với thiết bị di động chỉ có kích cỡ tương đương bàn tay (ngay cả khi giờ đây màn hình di động đã lớn hơn nhiều so với ngày xưa).

Hệ quả của màn hình di động nhỏ là:

• Hầu hết các thiết kế cầu kỳ có cơ hội trình diễn trên máy bàn thì trên di động lại không thể hiện được nhiều, nếu không muốn nói là dư thừa trong phần đa trường hợp
• Các thông tin bên cột phải mà máy bàn thường có, và thường được ngó nghiêng ít nhiều thì trên di động lại trôi xuống tận cuối bài viết, nơi hầu như chẳng ai để ý tới (hầu hết mọi người không đọc hết bài viết của bạn đâu)
• Kết nối internet và phần cứng của thiết bị di động yếu hơn đáng kể so với máy bàn (sức mạnh của nó khác nhau như xe máy với ô tô vậy)

Chiến lược tối ưu

Từ những đặc điểm trên bạn có thể tiến hành ưu tiên cho di động, chẳng hạn như:

• Sử dụng theme đơn giản, ưu tiên tốc độ, vì các giao diện cầu kỳ không biểu hiện được gì nhiều trên di động (tuy nhiên bạn vẫn cần đảm bảo các chức năng căn bản phải có)
• Loại bỏ cột phải trên di động. Nếu thông tin cột phải bạn cho là rất quan trọng, hãy chèn nó vào giữa bài viết hoặc ở vị trí bạn cho là xứng đáng, còn nếu nó không quan trọng, bạn có thể chèn nó xuống bên cuối bài
• Trong phần lớn trường hợp không nên tiến hành lazy load trên di động, nó không hấp dẫn như chúng ta nghĩ.
• Đặc biệt để ý đến các kỹ thuật như critical CSS và defer, async JavaScript. Trên máy bàn bạn chẳng để ý đến các kỹ thuật đó web vẫn nhanh (hoặc ít nhất thì cũng không chậm), trong khi trên di động thì không- tốc độ sẽ giảm đi đáng kể
• WebP, định dạng ảnh mới giúp tiết kiệm khá nhiều dung lượng có thể rất rắc rối trên di động, vì số lượng trình duyệt di động hỗ trợ nó không cao như máy bàn, ngoài ra còn là các đoạn mã để giúp hiển thị ảnh tương ứng với trình duyệt phù hợp có thể là vấn đề mang tính kỹ thuật, khó nhằn với nhiều người
• Để ý đến AMP, nó có thể giúp tăng tốc website trên di động rất tốt khi nó truy cập từ máy tìm kiếm, tuy nhiên không phải website nào cũng phù hợp. Nó thường hợp với các trang tin tức, blog đơn giản hơn là các trang có cấu trúc, chức năng phức tạp

The post BAO NHIÊU % NGƯỜI TRUY CẬP WEBSITE CỦA BẠN LÀ TỪ DI ĐỘNG? appeared first on Unest.

Bạn có thể vào và kiểm tra tốc độ của trang web, nó sẽ đưa ra những điểm bạn chưa tối ưu dẫn đến tốc độ chậm và những điểm bạn đã tối ưu tốt. Với WordPress thì bạn hoàn toàn có thể cài một vài plugin là có thể thấy được điểm số thay đổi tích cực

Tuy nhiên để bạn hiểu bản chất vấn đề tôi sẽ đề cập đến các plugin cụ thể vào lúc khác và sẽ giải thích cơ chế tối ưu trước.

Tại sao phải khổ sở đi tìm các cơ chế bản chất trong tối ưu tốc độ làm gì trong khi có thể ăn sẵn nhờ plugin?

Bởi vì ăn sẵn có các nguy cơ sau:

• Bạn đơn giản làm theo các lời khuyên, nhưng các lời khuyên luôn có ngoại lệ, và nếu trang của bạn rơi vào ngoại lệ thì cách bạn tối ưu thậm chí là có hại.
• Bạn chỉ tối ưu hời hợt bề ngoài, tức là bạn làm được rất ít, không hết khả năng.
• Nếu không có các công cụ hỗ trợ tiện lợi thì bạn không biết làm gì cả!

Hiểu sâu bản chất giúp bạn tối ưu được rất nhiều & hiểu rằng bạn đã tối ưu trang đến đâu, mặc cho có thể tồn tại những điểm mà các báo cáo nói là có vấn đề về tốc độ.

Rồi, giờ chúng ta sẽ xem từng hướng dẫn cụ thể của PageSpeed Insights. Lưu ý là trong bài viết này tôi chỉ đề cập đến phần tốc độ trong lời khuyên của họ. Còn phần tối ưu tính khả dụng sẽ được viết trong bài khác.

1. Tránh chuyển hướng ở trang đích

Quy tắc này kích hoạt (this rule triggers) khi PageSpeed Insights phát hiện (detects) bạn có hơn một chuyển hướng từ url hiện tại đến trang landing page cuối cùng.

Tổng quan

Chuyển hướng tạo thêm một chu trình yêu cầu-phản hồi HTTP và làm trang trì hoãn quá trình hiển thị (rendering). Trong trường hợp tốt nhất, mỗi lần chuyển hướng sẽ thêm một vòng khứ hồi (yêu cầu-phản hồi HTTP), và trong trường hợp tệ nhất nó có thể tạo ra nhiều vòng lặp khứ hồi như thực hiện tra cứu DNS, “bắt tay” TCP, đàm phán TLS ngoài việc có thêm chu kỳ HTTP yêu cầu-hồi đáp. Do vậy bạn phải tối thiểu hoá việc sử dụng chuyển hướng để nâng cao hiệu năng của trang.

Dưới đây là một số ví dụ về các kiểu chuyển hướng điển hình (redirect patterns):

• example.com sử dụng thiết kế web đáp ứng, không cần chuyển hướng – nhanh và tối ưu! (bạn nên làm như thế này)
• example.com → m.example.com/home – xuất hiện nhiều chuyển hướng ảnh hưởng đến người dùng di động (xảy ra khi bạn định làm một url riêng cho phiên bản di động)
• example.com → www.example.com → m.example.com – trải nghiệm di động rất chậm (với đủ các kiểu chuyển hướng từ không có www đến có www rồi đến phiên bản di động)

Lời khuyên

Hãy tìm hiểu các nguyên tắc cơ bản của thiết kế đáp ứng để phân phối trải nghiệm tốt trên nhiều thiết bị và loại bỏ (eliminate) các chuyển hướng không cần thiết.

Nếu trang của bạn yêu cầu chuyển hướng, hãy đọc hướng dẫn chuyển hướng và phát hiện User-Agent của chúng tôi (Google).

Kinh nghiệm cá nhân với WordPress: Nếu bạn dùng WordPress, thông thường bạn sẽ không gặp vấn đề chuyển hướng kiểu như trên. Các giao diện dành cho WordPress (ngay cả miễn phí) hầu như đều là thiết kế đáp ứng.

2. Bật nén

Quy tắc này kích hoạt khi PageSpeed Insights phát hiện các nguồn nén đang thực thi (compressible resources were served) không có nén gzip.

Tổng quan

Tất cả các trình duyệt hiện đại đều hỗ trợ và tự động đàm phán nén gzip cho tất cả các yêu cầu HTTP. Bật gzip có thể giảm dung lượng truyền tải lên đến 90%, điều này có thể giảm đáng kể thời gian tải dữ liệu nguồn, giảm dữ liệu sử dụng cho người dùng và nâng cao thời gian xuất trang lần đầu. Xem nén văn bản với GZIP để hiểu thêm.

Lời khuyên

Bật và kiểm tra xem nén gzip có được hỗ trợ bởi web server của bạn hay là không. Dự án HTML5 Boilerplate bao gồm các tệp tin cấu hình mẫu cho tất cả máy chủ phổ biến nhất với các lời khuyên chi tiết cho việc cấu hình và thiết lập: tìm máy chủ ưa thích của bạn trong danh sách, tìm tới phần gzip, và xem xem máy chủ của bạn có được cấu hình với các thiết lập được khuyến cáo không. Ngoài ra hãy tham khảo tài liệu cho máy chủ web của bạn về cách bật nén:

• Apache: Sử dụng mod_deflate
• Nginx: Sử dụng ngx_http_gzip_module
• IIS: Configure HTTP Compression

Kinh nghiệm cá nhân với WordPress: Để kiểm tra xem trang của bạn đã được nén hay chưa, bạn có thể vào các trang web chuyên kiểm tra việc này rồi đưa tên miền của bạn vào. Gõ từ khóa “Check GZIP compression” để có được các trang như vậy.

Rất nhiều dịch vụ hosting mặc định bật gzip nên có thể bạn sẽ bất ngờ khi thấy trang của mình đã được bật rồi dù bản thân chưa làm gì cả. Bật gzip giúp các hãng hosting giảm tải băng thông.

Hiện nay một số hosting hỗ trợ kiểu nén còn tốt hơn tên là brotli, một chương trình do Google phát triển. Để kiểm tra xem hosting của bạn có hỗ trợ kiểu nén này không, bạn vào trang này: https://tools.keycdn.com/brotli-test

Các câu hỏi thường gặp (FAQ)

PageSpeed Insight báo là nhiều nội dung tĩnh của tôi (my static content) cần nén gzip, nhưng tôi đã cấu hình máy chủ web để nén gzip các file đó. Tại sao PageSpeed Insights không phát hiện được là tôi đã bật nén rồi?

Proxy servers và phần mềm chống virus có thể vô hiệu hoá nén khi các file này được tải về máy khách. Kết quả của PageSpeed Insight dựa trên headers, khi chúng thực sự được trả lại cho máy khách, vì vậy nếu bạn thực hiện phân tích trên máy khách sử dụng các phần mềm chống virus như vậy hoặc ngồi phía sau máy chủ proxy trung gian (nhiều máy chủ là vô hình, và bạn có thể thậm chí không ý thức được sự can thiệp của proxy giữa máy khách của bạn và máy chủ web), chúng có thể là nguyên nhân của vấn đề này.

Để xác định nếu proxy là nguyên nhân, bạn có thể sử dụng PageSpeed Insights Chrome extension để kiểm tra headers:

1. Chạy PageSpeed trên trang.
2. Click vào tab Hiển thị Nguồn (Show Resource).
3. Mở rộng URL của nguồn được gắn cờ là không bật nén. Các header đi kèm với nguồn được hiển thị. Nếu bạn thấy header gọi đến Via, Forwarded, or Proxy-Connection, điều đấy chỉ ra rằng một proxy đang phục vụ tài nguyên.

3. Cải thiện thời gian phản hồi của máy chủ

Quy tắc này được kích hoạt khi PageSpeed Insights phát hiện thời gian phản hồi máy chủ của bạn trên 200 ms.

Tổng quan

Thời gian phản hồi máy chủ (server response time) đo khoảng thời gian phải bỏ ra (how long it takes) cho việc tải HTML cần thiết để bắt đầu quá trình hiển thị trang từ máy chủ của bạn, trừ đi độ trễ mạng (network latency) giữa Google và máy chủ của bạn. Có thể có sự khác nhau ngay cả lần chạy tiếp theo, nhưng sự khác biệt không nên quá lớn. Trong thực tế, sự không ổn định của thời gian phản hồi máy chủ có thể biểu thị cho một vấn đề nghiêm trọng mang tính nền tảng về hiệu suất (underlying performance issue).

Lời khuyên

Bạn phải giảm thời gian phản hồi của máy chủ xuống dưới 200 ms. Có hàng tá yếu tố tiềm năng có thể gây chậm thời gian phản hồi của máy chủ: ứng dụng logic chậm, truy vấn cơ sở dữ liệu chậm, bộ định tuyến chậm, frameworks, các thư viện, thiếu CPU, hoặc thiếu RAM.

Bạn cần xem xét tất cả các yếu tố đó để cải thiện thời gian phản hồi của máy chủ. Bước đầu tiên để biết được lý do tại sao thời gian phản hồi của máy chủ lại tăng là đo đạc. Sau đó, với dữ liệu trong tay, tìm hiểu các hướng dẫn thích hợp để biết rắc rối nằm ở đâu. Một khi vấn đề được giải quyết, bạn phải tiếp tục đo thời gian phản hồi của máy chủ và xác định bất cứ sự tắc nghẽn cổ chai về hiệu suất nào trong trương lai.

1. Thu thập và kiểm tra các dữ liệu và thông tin hiệu suất có sẵn. Nếu không có, đánh giá bằng cách sử dụng một ứng dụng theo dõi web tự động (được hosted và có phiên bản nguồn mở cho hầu hết các nền tảng) hoặc thêm thiết bị tùy chỉnh.
2. Xác định và khắc phục các nguyên nhân hàng đầu gây tắc nghẽn cổ chai làm ảnh hưởng đến hiệu suất. Nếu bạn sử dụng framework web, hoặc nền tảng quản lý nội dung phổ biến, tham khảo tài liệu về các thực hành tốt nhất của nó để tối ưu hóa hiệu suất.
3. Theo dõi và cảnh báo cho bất cứ vấn đề suy giảm (regressions) về hiệu suất nào trong tương lai!

Kinh nghiệm cá nhân với WordPress: Đôi khi các plugin có khả năng xung đột với nhau và có thể ảnh hưởng đến tốc độ tải trang, có khả năng là do ảnh hưởng đến RAM hoặc CPU.

4. Tận dụng sức mạnh bộ nhớ đệm của trình duyệt

Quy tắc này kích hoạt khi PageSpeed Insights phát hiện hồi đáp từ máy chủ của bạn không bao gồm caching header hoặc nếu có thì chỉ được chỉ định thời gian cache ngắn (specified to be cached for only a short time).

Tổng quan

Tìm nạp nguồn qua mạng (fetching resources over the network) gặp hai bất lợi là chậm và đắt đỏ: dowload có thể cần nhiều vòng lặp giữa máy khách và máy chủ (server), điều này sẽ làm trì hoãn xử lý và có thể ngăn chặn quá trình hiển thị (rendering) nội dung của trang, nó cũng làm tăng chi phí dữ liệu (incurs data costs) cho người xem. Tất cả hồi đáp từ máy chủ phải chỉ rõ (specify) chính sách (thông số) caching để giúp máy khách xác định được khi nào nó có thể sử dụng lại (reuse) phản hồi tìm nạp đã có trước đó.

Lời khuyên

Mỗi tài nguyên nên chỉ định rõ ràng chính sách (thông số) caching để trả lời các câu hỏi sau: khi nào dữ liệu nguồn có thể lưu trữ, ai lưu trữ, trong bao lâu, và nếu được áp dụng thì làm thế nào để việc kiểm tra lại hiệu quả khi thời gian caching hết hạn (caching policy expires). Khi máy chủ trả về hồi đáp, nó phải cung cấp Cache-Control và ETag headers:

• Cache-Control định nghĩa cách thức và bao lâu một hồi đáp cụ thể được cache bởi trình duyệt và các bộ cache trung gian khác. Để biết thêm, xem caching với Cache-Control.
• ETag cung cấp mã thông báo kiểm tra lại (revalidation token), được tự động gửi đi bởi trình duyệt để kiểm tra nếu nguồn thay đổi kể từ lần yêu cầu cuối. Để biết thêm, xem xác nhận hồi đáp cache với ETags.

Để xác định được chính sách caching tối ưu cho trang của bạn, hãy sử dụng các hướng dẫn sau:

• Xác định chính sách Cache-Control tối ưu
• Hủy và cập nhật các hồi đáp của bộ nhớ cache
• Danh sách kiểm tra bộ nhớ đệm

Chúng tôi khuyên thời gian cache tối thiểu là một tuần và tốt nhất (preferably) là một năm cho nội dung tĩnh, hoặc các nội dung ít khi thay đổi. Nếu bạn cần kiểm soát chính xác khi tài nguyên không được xác nhận, chúng tôi khuyên sử dụng dấu vân tay URL – xem hủy và cập nhật hồi đáp cache ở liên kết trên.

Kinh nghiệm cá nhân với WordPress: Bạn có thể dễ dàng tạo hoặc tối ưu bộ nhớ đệm của trình duyệt thông qua chỉnh sửa file .htaccess. Nhiều plugin tạo bộ nhớ cache phổ biến cho WordPress như W3 Total Cache, WP Super Cache, WP Fastest Cache hoặc WP Rocket cho phép bạn làm điều này qua giao diện trực quan.

Nếu bạn không dùng các plugin trên mà chỉnh sửa thủ công, việc đó cũng không hề khó khăn đâu, bạn dễ dàng tìm các mẫu code chuẩn chỉnh dành cho máy chủ của mình, nó rất phổ biến trên mạng (trong đường link tối ưu bộ nhớ đệm của trình duyệt ở trên cũng có đoạn mã đó).

Cách thức tăng tốc này là điều rất đáng làm vì nó thực sự hiệu quả, rất đơn giản và không tốn kém gì.

5. Giảm thiểu tài nguyên (HTML, CSS và JavaScript)

Quy tắc này được kích hoạt khi PageSpeed Insights phát hiện ra một trong các nguồn của bạn có thể được giảm thiểu dung lượng.

Tổng quan

Giảm thiểu (minification) đề cập đến quá trình loại bỏ các dữ liệu không cần thiết (unnecessary) hoặc dư thừa (redundant) mà không làm ảnh hưởng đến việc trình duyệt xử lý nguồn nội dung – thí dụ như mã của bình luận, loại bỏ code không sử dụng, sử dụng các tên biến và tên hàm ngắn hơn và nhiều kỹ thuật khác nữa.

Xem tiền xử lý và tối ưu hóa theo ngữ cảnh cụ thể để biết thêm chi tiết.

Lời khuyên

Bạn nên giảm thiểu nguồn HTML, CSS và JavaScript:

• Để giảm thiểu HTML, thử dùng HTMLMinifier
• Để giảm thiểu CSS thử dụng CSSNano và csso
• Để giảm thiểu JavaScript thử dùng UglifyJS. Closure Compiler cũng rất hiệu quả. Bạn có thể tạo một quá trình xây dựng bằng cách sử dụng các công cụ này để giảm thiểu và thay đổi tên của các file phát triển và lưu chúng trong thư mục sản phẩm.

Ngoài ra, PageSpeed Module, tương hợp với cả máy chủ Apache hoặc Nginx sẽ tự động tối ưu trang của bạn, bao gồm cả việc tối thiểu hóa nguồn.

Kinh nghiệm cá nhân với WordPress: Bạn có thể thấy đây là cách thức rất dễ hiểu để cải thiện dung lượng của trang. Bạn đơn giản loại bỏ các dữ liệu không cần thiết. Hiện một trong các plugin rất mạnh trong công việc này của WordPress là Autoptimize kết hợp nhiều cách thức tối ưu trong đó có cả giảm thiểu dung lượng, nối file & tải không đồng bộ/trì hoãn JS. Ngoài ra thì nhiều plugin chuyên cho cache cũng có sẵn tính năng này, ví dụ như WP-Rocket.

Nếu giảm thiểu dung lượng không ảnh hưởng gì đến việc hiển thị thì nối file và tải không đồng bộ/trì hoãn CSS, JS có thể gây lỗi giao diện. Đây là nguyên nhân mà bạn cần kiểm tra kỹ lại trang sau khi dùng Autoptimize, đặc biệt là những trang có giao diện phức tạp, hoặc có nhiều tính năng. Trong đa số trường hợp tối ưu cho JS, CSS và HTML là cách thức rất an toàn.

Việc chỉnh sửa thủ công bằng các công cụ mà Google gợi ý ở trên cũng khá hay, nhưng đòi hỏi bạn phải tìm hiểu sâu hơn về WordPress chứ nó không đơn giản như cách dùng plugin.

Tuy nhiên nhược điểm của chỉnh sửa thủ công ngay cả khi bạn là người khá thành thạo đi nữa đó là nếu theme cập nhật thì bạn cũng phải cập nhật lại các thao tác thủ công của mình & điều này chẳng phải là công việc nhẹ nhàng, dễ nhớ hay thú vị gì. Dùng plugin thì không bị như thế, nó tự động làm cho bạn (tôi nghĩ có lẽ đó là lý do tại sao người phát triển plugin trên đặt tên của nó bắt đầu bằng tiền tố auto / tự động).

6. Tối ưu hóa ảnh

Quy tắc này được kích hoạt khi PageSpeed Insights phát hiện các hình ảnh trên trang của bạn có thể được tối ưu để giảm dung lượng (optimized to reduce their filesize) mà không ảnh hưởng đáng kể (without significantly impacting) đến chất lượng đồ họa (visual quality).

Tổng quan

Các hình ảnh thường chiếm phần lớn dung lượng tải trên trang. Hệ quả là: tối ưu hóa hình ảnh có thể tiết kiệm được rất nhiều dung lượng (băng thông) và nâng cao hiệu suất: càng ít dữ liệu trình duyệt phải tải xuống, thì sự cạnh tranh cho băng thông của khách hàng cũng ít theo và trình duyệt có thể tải và hiển thị nội dung trên màn hình nhanh hơn.

Lời khuyên

Tìm ra định dạng tối ưu (optimal format) và chiến lược tối ưu hóa hình ảnh của bạn có thể phải yêu cầu phân tích cẩn thận trên nhiều khía cạnh: kiểu dữ liệu được mã hóa, các định dạng hình ảnh có thể, cài đặt chất lượng, độ phân giải và nhiều điều khác nữa. Thêm vào đó, bạn cần xem xét liệu một số hình ảnh sẽ tốt nhất khi ở định dạng vector (SVG), một số hiệu ứng mong muốn có thể đạt được thông qua CSS, và làm thế nào phân phối các định dạng tài nguyên thích hợp cho từng thiết bị.

Tối ưu hóa cho tất cả các định dạng ảnh

• Theo các thực hành tốt nhất cho các hình ảnh đáp ứng
• Theo các checklist tối ưu hóa ảnh cho từng ảnh riêng lẻ (tôi đã dịch bài viết này sang tiếng Việt, bạn đọc ở đây: Cách tối ưu hóa ảnh cho web)

Tối ưu hóa cho ảnh GIF, PNG và JPEG

GIF, PNG và JPEG là các định dạng chiếm đến 96% toàn bộ lưu lượng ảnh trên Internet. Do sự phổ biến của chúng, PageSpeed Insights cung cấp các lời khuyên tối ưa hóa cụ thể. Để thuận tiện cho bạn, bạn có thể tải các ảnh được tối ưu hóa trực tiếp từ PageSpeed Insights (được xử lý bằng thư viện tối ưu hình ảnh của modpagespeed.com).

Bạn cũng có thể sử dụng các công cụ chuyển đổi nhị phân của ImageMagick để thực hiện các tối ưu hóa tương tự – xem các ví dụ hướng dẫn bên dưới.

Nếu bạn sử dụng công cụ tối ưu hình ảnh của bên thứ ba, hãy ý thức rằng quá trình chuyển đổi có thể làm hình ảnh lớn hơn nếu các ảnh của bạn đã được tối ưu sẵn từ trước rất tốt rồi (tôi cũng từng chia sẻ kinh nghiệm này trong bài viết thử chuyển JPG & PNG sang WebP). Nếu tình huống này xảy ra, hãy sử dụng lại bản gốc của bạn.

GIF và PNG là định dạng không mất dữ liệu, vì vậy quá trình xử lý nén sẽ không gây bất kỳ ảnh hưởng nào đến chất lượng hình ảnh. Đối với hình ảnh tĩnh, PNG đạt được tỷ lệ nén tốt hơn với chất lượng hình ảnh tốt hơn. Với hình ảnh động, xem xét sử dụng video thay vì GIF để nhận được khả năng nén tốt hơn.

• Luôn luôn chuyển đổi GIF sang PNG trừ khi ảnh gốc là ảnh động hoặc rất nhỏ (ít hơn vài trăm bytes).
• Với cả ảnh GIF và PNG, loại bỏ kênh alpha nếu tất cả các pixel không rõ ràng.

Lấy thí dụ, bạn có thể sử dụng chuyển đổi nhị phân để tối ưu ảnh GIF và PNG với các lệnh sau (các thông số bên trong dấu ngoặc là tùy chọn):

convert INPUT.gif_or_png -strip [-resize WxH] [-alpha Remove] OUTPUT.png

convert cuppa.png -strip cuppa_converted.png

JPEG là định dạng mất dữ liệu. Quá trình nén sẽ loại bỏ các chi tiết của bức hình, nhưng tỷ lệ nén có thể cao hơn 10 lần so với GIF hoặc PNG.

• Giảm chất lượng xuống 85 nếu dung lượng sau vẫn cao hơn. Với chất lượng cao hơn 85, dung lượng hình ảnh tăng lên nhanh chóng, trong khi chất lượng không cải thiện bao nhiêu.
• Giảm lấy mẫu Chroma xuống 4:2:0, bởi vì hệ thống thị giác của con người kém nhạy cảm với màu sắc khi so sánh với độ sáng (lumniance).
• Sử dụng định dạng progressive cho ảnh trên 10KB. Ảnh JPEG progressive thường có tỷ lện nén cao hơn so với JPEG baseline cho các ảnh lớn, và có lợi ích trong việc hiển thị dần dần (hiển thị toàn bộ ảnh mờ sau đó rõ dần ra).[2]
• Sử dụng không gian màu xám (grayscale color space) nếu ảnh là đen trắng.

[2]: Dưới đây là ví dụ về hai trường hợp so sánh ảnh tải theo kiểu baseline & progressive:

Lấy ví dụ, bạn có thể sử dụng chuyển đổi nhị phân để tối ưu các ảnh JPEG với các lệnh sau (các tham số bên trong dấu ngoặc vuông là tùy chọn):

convert INPUT.jpg -sampling-factor 4:2:0 -strip [-resize WxH] [-quality N] [-interlace JPEG] [-colorspace Gray/RGB] OUTPUT.jpg

convert puzzle.jpg -sampling-factor 4:2:0 -strip -quality 85 -interlace JPEG -colorspace RGB puzzle_converted.jpg

Kinh nghiệm cá nhân với WordPress: Cải thiện tốc độ tải trang bằng cách sử dụng ảnh thông minh & tối ưu là cách thức rất hiệu quả. Tuy nhiên đây là một trong những việc cần chuyên môn nhiều nhất so với các biện pháp khác.

Mặc dù có khá nhiều plugin hỗ trợ cho WordPress trong việc tối ưu hóa ảnh, có vài điều điều bạn cần lưu ý:

• Việc quan trọng nhất trong việc tối ưu hóa dung lượng ảnh là bạn biết bản thân thực sự cần chất lượng ảnh đến đâu. Đánh đổi chất lượng dư thừa là cần thiết nhưng nếu quá ham giảm dung lượng thấp bạn có thể biến trang web trông rất thiếu chuyên nghiệp.
• Nếu số lượng ảnh tối ưu không lớn thì các plugin dành cho WordPress rất dễ tìm hàng miễn phí nhưng nếu số lượng ảnh lớn đa số đều thu phí, mặc dù số tiền không lớn (10 USD / 10 ngàn ảnh, hoặc 1GB).
• Nếu không cẩn thận bạn sẽ làm chất lượng ảnh của trang giảm đi đáng kể hoặc làm dung lượng của ảnh tăng lên!
• Nên thận trọng với nén ảnh mất chất lượng.
• Ảnh định dạng mới như WebP (cũng do Google phát triển) rất đáng tham khảo & tìm hiểu kỹ.

7. Tối ưu hóa việc phân phối CSS

Quy tắc này kích hoạt khi PageSpeed Insights phát hiện (detects) trang bị chặn hiển thị có nguyên nhân từ việc chứa các stylesheet ngoài, điều này làm trì hoãn thời gian trang hiển thị nội dung phần đầu (còn gọi là CSS chặn hiển thị).

Tổng quan

Trước khi trình duyệt có thể hiển thị nội dung nó buộc phải xử lý tất cả thông tin style và layout cho trang hiện tại. Hệ quả là: trình duyệt sẽ chặn hiển thị (block rendering) cho đến khi các file stylesheet ngoài được tải và xử lý xong (downloaded and processed), điều này có thể yêu cầu nhiều vòng lặp (roundtrips) và trì hoãn lần hiển thị trang đầu tiên. Xêm thêm cấu trúc cây của quá trình hiển thị, layout và tạo trang (render-tree construction, layout, and paint) hoặc cách trình duyệt tải trang web của bạn (tiếng Việt) để biết thêm về quá trình xử lý hiển thị trang, và xem thêm render blocking CSS để có các mẹo mở chặn (unblock) hiển thị và nâng cao khả năng phân phối CSS.

Lời khuyên

Nếu file CSS bên ngoài nhỏ, bạn có thể chèn nó trực tiếp vào tài liệu HTML (inline), điều này được gọi là nội tuyến (khác với nội dòng – nội dòng là chèn thẳng vào thẻ HTML cụ thể). CSS nội tuyến nhỏ theo cách này cho phép trình duyệt xử lý với việc xuất trang tốt hơn. Nên nhớ rằng nếu file CSS lớn, để CSS nội tuyến có thể là nguyên nhân khiến PageSpeed Insights cảnh báo (warn) phần nội dung đầu (above-the-fold) [1] của trang quá lớn thông qua Ưu tiên nội dung hiển thị (prioritize visible content / được nói chi tiết trong phần 8 – ngay sau phần này). Trong trường hợp file CSS lớn, bạn sẽ cần xác định và đặt nội tuyến CSS cần thiết cho việc xử lý hiển thị trang ở phần đầu (critical CSS) và trì hoãn tải cho các style còn lại cho đến khi nội dung phần đầu được tải xong.

[1]: Above the fold: chỉ đến phần nội dung hiển thị ra bên ngoài màn hình đầu tiên khi người dùng tải trang, họ không phải cuộn chuột để xem nội dung thuộc Above the fold. Xem thêm bài viết nội dung thuộc màn hình đầu tiên để thấy ưu thế của phần nội dung này.

Ví dụ về việc đặt nội tuyến file CSS nhỏ

Lấy ví dụ, nếu tài liệu HTML giống như thế này:

<html>
  <head>
    <link rel="stylesheet" href="small.css">
  </head>
  <body>
    <div class="blue yellow big bold">
      Hello, world!
    </div>
  </body>
</html>

Và file nguồn small.css là như này:

.yellow {background-color: yellow;}
  .blue {color: blue;}
  .big { font-size: 8em; }
  .bold { font-weight: bold; }

Thì bạn có thể đặt nội tuyến CSS như bên dưới:

<html>
  <head>
    <style>
      .yellow {background-color: yellow;}
      .blue {color: blue;}
      .big { font-size: 8em; }
      .bold { font-weight: bold; }
    </style>
    </head>
  <body>
    <div class="blue yellow big bold">
      Hello, world!
    </div>
  </body>
</html>

Điều này sẽ loại bỏ yêu cầu của trình duyệt tới small.css bằng cách đặt CSS nội tuyến trong tài liệu HTML.

Hoặc cách này, phức tạp hơn:

<html>
  <head>
    <style>
      .blue{color:blue;}
    </style>
    </head>
  <body>
    <div class="blue">
      Hello, world!
    </div>
    <noscript id="deferred-styles">
      <link rel="stylesheet" type="text/css" href="small.css"/>
    </noscript>
    <script>
      var loadDeferredStyles = function() {
        var addStylesNode = document.getElementById("deferred-styles");
        var replacement = document.createElement("div");
        replacement.innerHTML = addStylesNode.textContent;
        document.body.appendChild(replacement)
        addStylesNode.parentElement.removeChild(addStylesNode);
      };
      var raf = requestAnimationFrame || mozRequestAnimationFrame ||
          webkitRequestAnimationFrame || msRequestAnimationFrame;
      if (raf) raf(function() { window.setTimeout(loadDeferredStyles, 0); });
      else window.addEventListener('load', loadDeferredStyles);
    </script>
  </body>
</html>

Bạn có thể thấy việc chuyển đổi này bao gồm việc xác định nội dung CSS nào quan trọng (critical) / không quan trọng (non-critical). Rồi sau đó đặt nội tuyến CSS quan trọng và trì hoãn tải các file CSS không quan trọng. Phương pháp này có thể được làm tự động bằng modules PageSpeed Optimization cho nginx, apache, IIS, ATS, và Open Lightspeed, khi bạn bật bộ lọc (filter) prioritize_critical_css (ưu tiên các CSS quan trọng – hay tổng quan hơn được gọi là tuyến hiển thị quan trọng).

Xem thêm hàm loadCSS để giúp bạn tải CSS không đồng bộ, nó có thể làm việc với Critical, một công cụ cho phép xuất ra file CSS quan trọng từ trang web.

Các định kiểu quan trọng cần cho việc định kiểu nội dung phần đầu nên được đưa nội tuyến và áp dụng lên tài liệu ngay lập tức (immediately). Bản đầy đủ của small.css sẽ được tải sau khi hiển thị xong phần đầu của trang. Style của nó được áp dụng lên trang một khi nó được tải xong, và không chặn render của phần nội dung quan trọng (critical content).

Lưu ý là các nền tảng web sẽ sớm hỗ trợ tải stylesheets theo cách thức (manner) không-chặn-hiển-thị, và không phải nhờ đến (resort) việc dùng JavaScript nữa, sử dụng HTML Imports.

Đừng đặt nội dòng lượng lớn dữ liệu URIs

Hãy cẩn thận khi đặt nội dòng dữ liệu URIs trong file CSS. Trong khi lựa chọn sử dụng dữ liệu nhỏ URIs trong CSS của bạn có thể có ý nghĩa, đặt nội dòng lượng lớn dữ liệu URIs có thể là nguyên nhân làm dung lượng của CSS phần đầu trang lớn thêm, cái sẽ làm chậm thời gian render trang.

Đừng đặt thuộc tính CSS trong dòng

Đặt thuộc tính CSS trong dòng trên các phần tử HTML (thí dụ: <p style=”…”>) phải tránh khi có thể (should be avoided where possible), bởi nó thường dẫn đến các đoạn mã lặp lại không cần thiết. Thêm nữa, CSS trong dòng trên phần tử HTML đã bị chặn theo mặc định với Chính sách Bảo mật Nội dung (CSP).

Kinh nghiệm cá nhân với WordPress: Phương pháp trên rõ ràng không dành cho dân không chuyên với việc phải xác định style quan trọng, rồi phải tách mã CSS ra làm hai phần để tối ưu. Hy vọng các trình duyệt sớm đưa vào tính năng mà nó vừa khoe: non-render-blocking để việc tối ưu này thành mặc định.

8. Ưu tiên nội dung hiển thị

Quy tắc này được kích hoạt khi PageSpeed Insight phát hiện thấy có thêm các vòng lặp yêu cầu trong quá trình hiển thị phần nội dung thuộc màn hình đầu tiên (above the fold content) của trang.

Tổng quan

Nếu dung lượng dữ liệu yêu cầu vượt quá (exceeds) ngưỡng nghẽn ban đầu (thông thường là 14,6KB đã nén), nó sẽ yêu cầu thêm vòng lặp giữa máy chủ và trình duyệt của người dùng. Với người dùng trên mạng có độ trễ cao (high latencies) như mạng điện thoại, điều này có thể là nguyên nhân gây ảnh hưởng đáng kể đến độ trễ của việc tải trang.

Lời Khuyên

Để trang tải nhanh hơn, cần giới hạn dung lượng dữ liệu (mã đánh dấu HTML, các hình ảnh, CSS, JavaScript) cần thiết để render phần nội dung đầu của trang. Có một số cách để làm điều đó:

• Cấu trúc HTML để tải nội dung quan trọng, ở phần đầu trước
• Giảm dung lượng dữ liệu sử dụng

Cấu trúc HTML để tải nội dung quan trọng, ở phần đầu trước

Tải phần nội dung chính (main content) trang của bạn trước. Cấu trúc trang của bạn để các phản hồi đầu tiên (initial response) từ máy chủ gửi dữ liệu cần thiết để render phần quan trọng của trang ngay lập tức và trì hoãn phần còn lại (defer the rest). Điều này có nghĩa là bạn phải chia CSS của bạn thành hai phần: phần inline để phản hồi lại định dạng cho phần ATF (viết tắt của Above The Fold) của nội dung (còn được gọi là critical CSS), và phần còn lại có thể được trì hoãn.

Xem xét các ví dụ sau về cách trang của bạn có thể cấu trúc lại (restructured) để tải nhanh hơn:

• Nếu trang HTML tải widget của bên thứ ba trước khi tải nội dung chính, hãy thay đổi thứ tự để nó tải nội dung chính trước.
• Nếu trang của bạn sử dụng thiết kế hai cột (two-column design) với sidebar điều hướng (sidebar navigation) và bài viết, nhưng trang HTML của bạn tải sidebar trước bài viết, hãy xem xét việc tải nội dung bài viết trước.

Giảm dung lượng dữ liệu sử dụng

Một khi trang của bạn được thiết kế lại để hoạt động tốt trên nhiều thiết bị khác nhau và ưu tiên tải nội dung quan trọng trước, sử dụng các kỹ thuật bên dưới để giảm lượng dữ liệu yêu cầu cho việc render trang của bạn:

• Giảm thiểu nguồn: HTML, CSS, và JavaScript có thể được giảm thiểu bằng cách loại bỏ các khoảng trắng (whitespace) và comments không cần thiết (unnecessary). Kỹ thuật tối ưu hóa gia tăng còn có thể áp dụng thông qua việc dùng các công cụ để thay đổi tên biến trong mã nguồn của bạn. (đã nói ở phần 5)
• Xem xét việc sử dụng CSS để thay thế hình ảnh khi có thể.
• Bật nén. (đã nói ở phần 2)

9. Loại bỏ JavaScript chặn hiển thị

Quy tắc này kích hoạt khi PageSpeed Insights phát hiện trang HTML của bạn tham chiếu đến file JavaScript bên ngoài chặn hiển thị nội dung đầu trang (nội dung nằm trong màn hình đầu tiên).

Tổng quan

Trước khi trình duyệt có thể hiển thị trang nó xây dựng cây DOM bằng cách phân tích (parsing) mã đánh dấu HTML. Trong suốt quá trình này, bất cứ khi nào trình xử lý (parser) bắt gặp script, nó phải dừng lại và thực thi nó trước khi có thể tiếp tục xử lý với HTML. Trong trường hợp mã script ngoài, trình xử lý buộc phải chờ nguồn tải xong, điều này có thể tạo thêm một hoặc nhiều truy vấn lặp và trì hoãn thời gian hiển thị phần đầu trang. Xem Thêm tương tác với JavaScript để hiểu hơn cách JavaScript ảnh hưởng đến hiển thị như thế nào.

Lời khuyên

Bạn cần phải tránh và tối thiểu hóa việc sử dụng JavaScript chặn hiển thị, đặc biệt là các script ngoại tuyến bắt buộc phải tải (fetched) trước khi được thực thi (executed). Script cần thiết để render nội dung trang có thể đặt nội tuyến để tránh gia tăng các yêu cầu mạng, dầu vậy nội dung nội tuyến cần nhỏ và phải thực thi nhanh để có được hiệu năng tốt. Scripts không quan trọng để hiển thị nội dung đầu trang nên tải không đồng bộ hoặc trì hoãn cho đến khi nội dung đầu trang hiển thị xong xuôi. Nên nhớ là để nâng cao thời gian tải, bạn phải thực hiện tối ưu phân phối CSS nữa.

JavaScript nội tuyến

Script ngoài chặn hiển thị bắt buộc trình duyệt phải đợi JavaScript tải xong, điều này sẽ tạo thêm nhiều vòng lặp mạng trước khi trang có thể được hiển thị. Nếu mã script ngoài là nhỏ, bạn có thể đặt nội tuyến trực tiếp đoạn mã trong tài liệu HTML và tránh được độ trễ của việc truy vấn mạng (giống kiểu với CSS). Lấy ví dụ, nếu tài liệu HTML giống như thế này:

<html>
  <head>
    <script type="text/javascript" src="small.js"></script>
  </head>
  <body>
    <div>
      Hello, world!
    </div>
  </body>
</html>

Và nguồn small.js giống như này:

  /* một đoạn mã JavaScript nhỏ */

Sau đó bạn có thể đặt nội tuyến mã như sau:

<html>
  <head>
    <script type="text/javascript">
      /* một đoạn mã JavaScript nhỏ */
    </script>
  </head>
  <body>
    <div>
      Hello, world!
    </div>
  </body>
</html>

Nội dung script nội tuyến giúp loại bỏ truy vấn ngoài đến file small.js và cho phép trình duyệt phân phối thời gian nhanh hơn cho việc hiển thị nội dung đầu trang. Dầu vậy, lưu ý là nội tuyến cũng có thể làm tăng kích cỡ tài liệu HTML và cùng một đoạn mã có thể cần đặt nội tuyến qua nhiều trang. Hệ quả, bạn chỉ nên đặt nội tuyến script nhỏ đế phân phối hiệu suất tối ưu cho trang.

Làm JavaScript tải không đồng bộ

Theo mặc định JavaScript ngăn chặn cấu trúc DOM và vì vậy trì hoãn thời gian hiển thị lần đầu (the time to first render). Để ngăn JavaScript chặn trình xử lý, chúng tôi khuyên bạn sử dụng thuộc tính async (không đồng bộ) trong HTML với các mã script ngoài (external scripts). Lấy thí dụ:

<script async src=”my.js”>

Xem thêm Chặn trình xử lý và JavaScript không đồng bộ để hiểu thêm về script không đồng bộ. Lưu ý là mã không đồng bộ không đảm bảo (guaranteed) thực hiện theo thứ tự chỉ định và không nên sử dụng document.write. Mã script phụ thuộc vào thứ tự thực thi (execution order) hoặc cần truy cập hoặc thay đổi (access or modify) DOM hoặc CSSDOM của trang có thể cần viết lại (rewritten) để khắc phục các khó khăn này.

Trì hoãn việc tải JavaScript

Việc tải và thực thi mã script không cần thiết cho việc hiển thị nội dung đầu trang (initial page render/tức là trang nằm trong màn hình đầu tiên) có thể được hoãn lại cho đến khi trang ban đầu được hiển thị hoặc các phần quan trọng khác (other critical parts) của trang được tải xong. Làm thế giúp giảm tranh chấp tài nguyên (reduce resource contention) và cải thiện hiệu suất (improve performance).

Các câu hỏi thường gặp (FAQ)

Nếu tôi sử dụng thư viện JavaScript như jQuery thì sao?

Nhiều thư viện JavaScript như jQuery, được sử dụng để cải tiến trang với việc thêm tương tác, hình động, và các hiệu ứng khác. Dầu vậy, nhiều hành vi có thể được thêm vào an toàn sau khi nội dung đầu trang được hiển thị đầy đủ. Bạn nên thử nghiệm (investigate) với cả tải không đồng bộ hoặc trì hoãn tải để xem có vấn đề gì xảy ra hay không.

Nếu tôi sử dụng JavaScript framework để xây dựng trang?

Nếu nội dung của trang được xây dựng bởi JavaScript phía máy khách, bạn phải xem xét đặt nội tuyến các module JavaScript thích hợp để tránh gia tăng vòng lặp mạng (extra network roundtrips). Tương tự như vậy, tận dụng sử dụng render phía máy chủ có thể tác động đáng kể đến hiệu suất tải trang lần đầu: render JavaScript templates trên máy chủ để phân phối render lần đầu nhanh hơn, và sau đó sử dụng templating phía máy khách một khi trang được tải xong. Để có thêm thông tin về việc rendering phía máy chủ (server-side rendering), xem video này: http://youtu.be/VKTWdaupft0?t=14m28s

Kinh nghiệm cá nhân với WordPress: Đến trước khi tôi sử dụng PageSpeed Insights để nhận các lời khuyên về cải thiện tốc độ thì tôi chưa bao giờ để ý đến việc sử dụng JavaScript không đồng bộ cả.

Xét về mặt kỹ thuật việc điều chỉnh thủ công để đạt chuẩn yêu cầu này không khó vì bạn chỉ cần thêm thuộc tính vào. Các plugin để chuyển các đoạn mã về không đồng bộ cũng dễ tìm được, thí dụ như Async JavaScript. Vấn đề quan trọng là bạn cần biết được việc chuyển như vậy ảnh hưởng đến đâu các chức năng của trang? Và điều chỉnh lại về trạng thái cũ khi cần. Nhiều plugin cache cũng tích hợp sẵn tính năng tải không đồng bộ này.

Theo chủ trang Varvy thì tải không đồng bộ (Async) không tốt bằng trì hoãn tải.

10. Sử dụng mã Script không đồng bộ

Quy tắc này kích hoạt khi PageSpeed Insights phát hiện bạn sử dụng phiên bản đồng bộ cho các script (kịch bản) thay vì sử dụng phiên bản không đồng bộ.

Tổng quan

Sử dụng mã không đồng bộ đồng nghĩa với việc trang của bạn có thể render nhanh hơn. Thay vì ép (forcing) người dùng đợi script tải xong trước khi trang được render thì bằng cách triển khai “mã không đồng bộ” script có thể được tải dưới nền.

Mặc dù hầu hết script mặc định ban đầu là đồng bộ (synchronous), các phiên bản mới của nó được thiết kế để tải không đồng bộ (asynchronously).

Lời khuyên

Để chắc chắn bạn sử dụng mã kịch bản (script) không đồng bộ. Các script phổ biến dưới đây hỗ trợ tải không đồng bộ:

• BuySellAds (s3.buysellads.com/ac/bsa.js) : blog post – mặc định là async
• ChartBeat (static.chartbeat.com/js/chartbeat.js) : doc, blog post – mặc định là async
• Clicky (static.getclicky.com/js) : blog post
• Disqus (disqus.com/count.js, disqus.com/embed.js) : doc, blog post – mặc định là async
• Facebook (connect.facebook.net/.../all.js) : doc, blog post – mặc định là async
• Google AdSense (pagead2.googlesyndication.com/pagead/show_ads.js) : doc, blog post
• Google Analytics (google-analytics.com/ga.js) : doc, blog post – mặc định là async
• Google DFP GPT (www.googletagservices.com/tag/js/gpt.js) : doc
• Google Plus (apis.google.com/js/plusone.js) : doc, blog post
• New Relic (d7p9czrvs14ne.cloudfront.net/11/eum/rum.js) : doc – mặc định là async
• Pinterest (assets.pinterest.com/js/pinit.js) : doc
• Shareaholic : doc – mặc định là async
• ShareThis (w.sharethis.com/button/buttons.js) : doc
• ScorecardResearch/Comscore (b.scorecardresearch.com/beacon.js) : doc – mặc định là async
• StumbleUpon (platform.stumbleupon.com/.../widgets.js)
• Quantcast (quantserve.com/quant.js) : doc – mặc định là async
• Twitter (platform.twitter.com/widgets.js) : doc – mặc định là async
• Tynt (cdn.tynt.com/tc.js)
• Yandex (mc.yandex.ru/metrika/watch.js)

Lưu ý: Chúng tôi nỗ lực hết sức để giữ (best effort to keep) danh sách trên được cập nhật (up-to-date). Dầu vậy, nếu bạn có câu hỏi đặc biệt nào về JavaScript của bên thứ ba hoặc bạn không tìm được phiên bản không đồng bộ (async) của họ ở đây, chúng tôi khuyến khích (encourage) bạn liên hệ trực tiếp với nhà cung cấp.

Chúng tôi có thêm thông tin giải thích tại sao loại bỏ JavaScript chặn hiển thị có thể tăng tốc độ tải trang của bạn (nó ở ngay phần 9 nếu bạn để ý!)

Kinh nghiệm cá nhân với WordPress: Khi mới đọc đến phần 9, tôi đã nghĩ phải điều chỉnh lại các đoạn mã JavaScript của Google Analystics và Facebook Fanpage thôi, nhưng tôi lo thừa rồi. Các hãng công nghệ lớn đều ý thức được ý nghĩa của việc tải không đồng bộ nên các đoạn mã của họ đã mặc định như thế rồi.

(Dịch từ các bài viết thuộc phần Speed Rules – PageSpeed Insights Rules – Make the Web Faster – Google Developers)

The post Tối ưu Google PageSpeed Insights để tăng tốc độ website appeared first on Unest.

Bắt đầu từ Chrome 76, bạn có thể sử dụng thuộc tính loading để lazy load các tài nguyên mà không cần viết riêng mã lazy-loading hoặc sử dụng riêng thư viện JavaScript (chẳng hạn như lazysizes). Chúng ta sẽ đi vào chi tiết ngay sau đây.

P/S: native trong cụm từ “native lazy-loading” có thể được dịch sát nghĩa là “tải lười kiểu bản địa” hoặc “lazy-loading bản địa”, tuy nhiên tôi (người dịch) thấy giữ nguyên từ gốc tiếng Anh hay hơn, hoặc nếu có dịch sẽ dùng từ “lazy-loading cấp trình duyệt” cho dễ hiểu.

Tại sao lại dùng native lazy-loading?

Theo HTTPArchive, ảnh là thành phần được yêu cầu nhiều nhất trên hầu hết website và thường chiếm nhiều băng thông hơn bất kỳ tài nguyên nào. Ở phân vị 90(*), các website gửi 4,7 MB ảnh trên máy bàn và di động.

(*): phân vị thứ 90 (90th percentile), theo cách hiểu thông thường là những trang web có dung lượng ảnh lớn hơn 90% các website khác, nói cách khác top 10% các website có nhiều ảnh nhất chứa ít nhất 4,7 MB ảnh.

Nhúng iframe cũng sử dụng rất nhiều dữ liệu và có thể ảnh hưởng tiêu cực đến hiệu suất của trang (page performance). Nếu chúng ta chỉ tải các ảnh, iframe không quan trọng (non-critical), nằm trong màn hình thứ hai trở đi (below-the-fold) khi người dùng cần xem chúng thì sẽ giúp cải thiện thời gian tải trang (page load times), tối thiểu hóa băng thông (bandwidth), và giảm sử dụng bộ nhớ.

Hiện tại có hai cách để trì hoãn tải ảnh và iframe không thuộc màn hình đầu tiên (off-screen):

• Sử dụng Intersection Observer API
• Sử dụng scroll, resize, hoặc orientationchange even hanler (trình xử lý sự kiện)

Cả hai tùy chọn này có thể cho phép lập trình viên bao gồm hàm lazy-loading vào website, và nhiều lập trình viên xây dựng thư viện của bên thứ ba để đưa ra các abstraction thậm chí còn dễ sử dụng hơn. Nhưng với lazy-loading được hỗ trợ trực tiếp bởi trình duyệt, bạn không cần đến các thư viện bên ngoài (external library) nữa. Native lazy loading cũng đảm bảo việc trì hoãn tải ảnh và iframes vẫn hoạt động bình thường ngay cả khi JavaScript bị vô hiệu hóa trên trình duyệt của người dùng (còn gọi là máy khách/client).

P/S: Rất hiếm khi trình duyệt bị vô hiệu hóa JavaScript, vì các website hiện đại, nhiều chức năng thì JavaScript là một thành phần cốt lõi, nhưng nếu nó bị vô hiệu hóa, mà trang của bạn không triển khai dự phòng bằng thẻ <noscript> thì lazy load sẽ bị gặp lỗi không hiển thị ảnh. Bạn có thể thử vô hiệu hóa JS trên Chrome bằng cách vào copy đường dẫn sau vào thanh địa chỉ:

chrome://settings/content/javascript

Rồi nhấn button vô hiệu hóa.

Thuộc tính loading

Ở thời điểm hiện tại, Chrome đã hỗ trợ tải ảnh ở các cấp độ ưu tiên khác nhau phụ thuộc vào vị trí của nó tương quan với viewport (khung nhìn) của thiết bị. Ảnh ở bên dưới viewport được tải với mức ưu tiên thấp hơn (lower priority), nhưng chúng sẽ vẫn được tìm nạp (fetched) để tải về nhanh nhất có thể (as soon as possible).

Trong Chrome 76, bạn có thể sử dụng thuộc tính loading để trì hoãn tải hoàn toàn các ảnh và iframes không thuộc màn hình đầu tiên (những khu vực mà phải cuộn chuột mới tiếp cận được), mã trông giống như thế này:

<img src="image.png" loading="lazy" alt="…" width="200" height="200">
<iframe src="https://example.com" loading="lazy"></iframe>

Dưới đây là các giá trị hỗ trợ cho thuộc tính loading:

• auto (tự động): Hành vi lazy-loading mặc định của trình duyệt, nó có cùng kết quả như khi bạn không bao gồm thuộc tính này trong thẻ.
• lazy (lười): Trì hoãn tải tài nguyên cho đến khi nó đạt đến khoảng cách định trước từ viewport (khoảng cách này cụ thể như thế nào bạn sẽ được biết cụ thể ở phần sau).
• eager (hăng hái): Tải tài nguyên ngay lập tức, không quan trọng là nó nằm ở vị trí nào trên trang (nói cách khác, ảnh có thể nằm rất sâu bên dưới viewport nhưng nó sẽ được tải ngay như là nó nằm ở trên cùng vậy).

P/S: các từ mà người dịch thêm vào là tự động, lười, hăng hái để bạn dễ nhớ và dễ hiểu hơn thôi.

Tính năng này sẽ tiếp tục được cập nhật cho đến khi nó được phát hành trong phiên bản ổn định (Chrome 76 là phiên bản đầu tiên). Nhưng bạn có thể thử nó bằng cách bật flags dưới đây trong Chrome:

• chrome://flags/#enable-lazy-image-loading
• chrome://flags/#enable-lazy-frame-loading

Ngưỡng khoảng cách tải

Tất cả các ảnh và iframe nằm trong màn hình đầu tiên (above the fold) — tức là những thứ xuất hiện ngay trong khung nhìn trình duyệt mà không cần cuộn chuột — sẽ được tải bình thường. Nhưng các ảnh và iframes nằm xa bên dưới viewport của thiết bị chỉ được tìm nạp khi người dùng cuộn chuột gần đến chúng (when user scrolls near them).

Ngưỡng khoảng cách là không cố định (not fixed) và tùy thuộc vào một số yếu tố sau:

• Kiểu tài nguyên được tìm nạp (nó là ảnh hay iframe)
• Chế độ Lite có được bật trên Chrome cho Android hay không
• Tác động của kiểu kết nối (nhanh, chậm, cáp quang, 3G, 4G, wifi, vân vân)

Bạn có thể tìm thấy các giá trị mặc định cho các kiểu kết nối khác nhau trên nguồn dữ liệu Chromium. Các con số này, và thậm chí là cách tiếp cận chỉ tìm nạp khi đạt đến khoảng cách nhất định từ viewport có thể thay đổi trong tương lai gần khi nhóm phát triển trình duyệt Chrome cải thiện heuristics (*) để xác định được khi nào nên bắt đầu tải.

(*): Kiểu quy tắc/thuật giải được phát triển dựa trên kinh nghiệm, thường là tối ưu trong phần lớn trường hợp nhưng không phải trong mọi trường hợp và có thể không phải là biện pháp tốt nhất có thể tồn tại. Ưu điểm của nó là cho chất lượng sản phẩm đủ tốt nhưng không mất nhiều thời gian phát triển.

Tôi (người dịch) sẽ cung cấp luôn thông tin về ngưỡng khoảng cách tải ở thời điểm hiện tại (cuối năm 2019):

 //
    // Lazy image loading distance-from-viewport thresholds for different effective connection types.
    //
    {
      name: "lazyImageLoadingDistanceThresholdPxUnknown",
      initial: 5000,
      type: "int",
    },
    {
      name: "lazyImageLoadingDistanceThresholdPxOffline",
      initial: 8000,
      type: "int",
    },
    {
      name: "lazyImageLoadingDistanceThresholdPxSlow2G",
      initial: 8000,
      type: "int",
    },
    {
      name: "lazyImageLoadingDistanceThresholdPx2G",
      initial: 6000,
      type: "int",
    },
    {
      name: "lazyImageLoadingDistanceThresholdPx3G",
      initial: 4000,
      type: "int",
    },
    {
      name: "lazyImageLoadingDistanceThresholdPx4G",
      initial: 3000,
      type: "int",
    },

Từ đoạn mã trên ta nhận thấy rằng trình duyệt Chrome sẽ:

• Trên mạng mà nó không nhận biết được (Unknown) nó sẽ tải ảnh khi ảnh cách viewport 5000 px
• Khi không có kết nối (Offline) nó sẽ tải khi cách viewport 8000 px
• Trên mạng 2G chậm là 8000 px
• Trên mạng 2G là 6000 px
• Trên mạng 3G là 4000 px
• Trên mạng 4G là 3000 px

Bạn có thể quan sát thấy quy luật là trên mạng càng nhanh, ngưỡng khoảng cách tải sẽ càng thấp.

Lưu ý: Trong Chrome 77, bạn có thể trải nghiệm các ngưỡng khác nhau bằng cách điều chỉnh mạng trong DevTools (công cụ cho nhà phát triển được tích hợp sẵn trong Chrome), bạn sẽ cần ghi đè ảnh hưởng của kiểu kết nối trong trình duyệt bằng cách sử dụng flag:

chrome://flags/#force-effective-connection-type

Tải hình ảnh

Để ngăn các nội dung xung quanh không reflowing(**) khi ảnh lazy-load tải, cần đảm bảo thêm thuộc tính height và width vào thành phần <img> hoặc chỉ định giá trị cụ thể, trực tiếp trong style nội tuyến (inline style):

<img src="..." loading="lazy" width="200" height="200">
<img src="..." loading="lazy" style="height:200px; width:200px;">

(**): reflowing là hiện tượng trình duyệt phải tính toán lại vị trí và bố cục của các thành phần trong tài liệu HTML, đây là hành vi sẽ khiến người dùng bị cản trở nên cần phải tránh. Bạn có thể tham khảo thêm thông tin về nó ở liên kết này.

Các ảnh sẽ vẫn được lazy-load nếu kích cỡ (dài, rộng) không được chỉ định, nhưng việc thông báo kích cỡ cho chúng sẽ giúp làm giảm khả năng trình duyệt bị reflow.

Hỗ trợ cho thuộc tính intrinsicsize vẫn đang được tiếp tục thực hiện, vì thế các ảnh sẽ vẫn được lazy-load chính xác nếu intrinsicsize được chỉ định kèm với một trong hai kích cỡ (width hoặc height).

<img src="…" alt="…" loading="lazy" intrinsicsize="250x200" width="450">
<!-- lazy-loaded -->

P/S: Bạn có thể xem ví dụ demo về cách thuộc tính loading làm việc với 100 bức ảnh sau (toàn mèo dễ thương).

Tải iframe

Thuộc tính loading ảnh hưởng đến iframe khác so với ảnh, phụ thuộc vào việc liệu iframe có ẩn hay không. (Các iframe ẩn thường được sử dụng cho mục đích phân tích hoặc giao tiếp). Chrome sử dụng các đặc điểm sau để xác định liệu một iframe có đang ẩn hay không:

• Chiều rộng và chiều cao của iframe là 4 px hoặc nhỏ hơn.
• Các thuộc tính display: none hoặc visibility: hidden đang được áp dụng.
• Iframe đang được đặt ở vị trí ngoài màn hình đầu tiên sử dụng positioning X hoặc Y có giá trị âm.

Nếu một iframe thỏa mãn bất kỳ điều kiện nào kể trên, Chrome xem nó là ẩn và không lazy-load nó trong phần lớn trường hợp. Iframe không ẩn sẽ chỉ được tải khi nó nằm trong ngưỡng khoảng cách cho phép tải (đã nói ở trên). Placeholder hiển thị cho iframes lazy-load sẽ vẫn được tìm nạp.

Các câu hỏi thường gặp (FAQ)

Hiện có bất kỳ kế hoạch nào để mở rộng tính năng này không?

Có một số kế hoạch trong việc thay đổi hành vi lazy-loading mặc định của trình duyệt để tự động tải lười bất cứ ảnh hoặc iframe nào mà phù hợp để trì hoãn nếu chế độ Lite được bật trên Chrome cho Android.

Các ảnh nền (background) viết trong CSS có tận dụng được lợi thế của thuộc tính loading không?

Không, hiện tại nó chỉ được sử dụng với các thẻ <img> mà thôi. Nói cách khác các ảnh background vẫn tải bình thường.

Thuộc tính loading hoạt động như thế nào với các ảnh nằm trong viewport nhưng không hiện ra ngay (ví dụ như nó ẩn trong các slide, mà người dùng phải click tiếp mới thấy)?

Chỉ các ảnh từ màn hình thứ hai trở đi mới được tải lười (kết hợp với việc nó thỏa mãn tiêu chí về ngưỡng khoảng cách). Tất cả các ảnh nằm trong màn hình đầu tiên, bất kể là nó không quan sát thấy ngay lúc đầu sẽ được tải như bình thường.

Chuyện gì xảy ra nếu tôi sử dụng thư viện của bên thứ ba (third-party) hoặc script để lazy-load ảnh và iframe?

Thuộc tính loading không ảnh hưởng gì đến mã lazy-load bạn đang sử dụng trên các tài nguyên, nhưng có vài điểm quan trọng sau cần để ý:

1. Nếu đoạn mã lazy-load của bạn cố gắng tải ảnh hoặc iframe sớm hơn so với Chrome tải chúng theo cách thông thường — điều đó có nghĩa là ngưỡng khoảng cách tải lớn hơn so với ngưỡng của Chrome — chúng sẽ vẫn được trì hoãn và tải dựa trên hành vi thông thường của trình duyệt (có nghĩa là trình duyệt sẽ ghi đè thiết lập của bạn).
2. Nếu đoạn mã lazy-load của bạn sử dụng ngưỡng khoảng cách tải thấp hơn so với trình duyệt, thế thì tùy chỉnh của bạn sẽ được áp dụng (chứ không phải các ngưỡng mặc định của Chrome được áp dụng, nói cách khác tùy chỉnh của bạn sẽ ghi đè thiết lập của Chrome).

Một trong các lý do quan trọng để tiếp tục sử dụng thư viện của bên thứ ba song song với loading=”lazy” đó là để hỗ trợ (polyfill) cho các trình duyệt hiện chưa có thuộc tính này.

Các trình duyệt khác có hỗ trợ native lazy-loading hay không?

Thuộc tính loading có thể được coi là một cải tiến, cho phép các trình duyệt hỗ trợ nó có thể lazy-load ảnh và iframe. Những trình duyệt chưa hỗ trợ sẽ vẫn tải theo cách cũ như hiện nay. Về mặt hỗ trợ chéo trình duyệt, loading được hỗ trợ trên Chrome 76 và bất kỳ trình duyệt nào dựa trên Chromium 76 (ví dụ như Cốc Cốc). FireFox cũng đang mở thảo luận việc tích hợp thuộc tính này vào.

Một API tương tự đã được đề xuất và sử dụng trong IE và Edge nhưng nó tập trung vào việc hạ thấp mức độ ưu tiên tải xuống của các tài nguyên thay vì trì hoãn tải chúng hoàn toàn. Nó không còn ủng hộ resource hints (gợi ý tài nguyên) nữa.

Tôi phải làm như thế nào với các trình duyệt hiện chưa hỗ trợ native lazy-loading?

Bạn có thể sử dụng thư viện của bên thứ ba hoặc các đoạn mã hỗ trợ khác để tải lười các ảnh trên website. Thuộc tính loading có thể được detect (phát hiện) nếu tính năng này được hỗ trợ trong trình duyệt nhờ đoạn mã sau:

if ('loading' in HTMLImageElement.prototype) {
  // có hỗ trợ trên trình duyệt này
} else {
  // sử dụng thư viện hoặc mã dự phòng
}

Ví dụ, lazysize là thư viện lazy-loading JavaScript phổ biến. Bạn có thể sử dụng đoạn mã dùng ở trên để phát hiện thuộc tính loading có được hỗ trợ trên trình duyệt không, nếu nó không, hãy dự phòng bằng lazysize. Điều đó được thực hiện như sau:

• Thay thế <img src> bằng <img data-src> để tránh trình duyệt (không hỗ trợ thuộc tính loading) tải ảnh ngay lập tức. Nếu thuộc tính loading được hỗ trợ, bạn chỉ việc chuyển lại data-src thành src.
• Nếu loading không được hỗ trợ, tải mã dự phòng (lazysizes). Theo tài liệu của lazysizes, bạn sử dụng class (lớp — một khái niệm trong CSS) lazyload như cách để chỉ cho lazysizes biết ảnh nào cần lazy-load.

<!-- Let's load this in-viewport image normally -->
<img src="hero.jpg" alt="…">

<!-- Let's lazy-load the rest of these images -->
<img data-src="unicorn.jpg" alt="…" loading="lazy" class="lazyload">
<img data-src="cats.jpg" alt="…" loading="lazy" class="lazyload">
<img data-src="dogs.jpg" alt="…" loading="lazy" class="lazyload">

<script>
  if ('loading' in HTMLImageElement.prototype) {
    const images = document.querySelectorAll('img[loading="lazy"]');
    images.forEach(img => {
      img.src = img.dataset.src;
    });
  } else {
    // Dynamically import the LazySizes library
    const script = document.createElement('script');
    script.src =
      'https://cdnjs.cloudflare.com/ajax/libs/lazysizes/4.1.8/lazysizes.min.js';
    document.body.appendChild(script);
  }
</script>

Dưới đây là trang demo cho kiểu tải này. Bạn hãy thử nó trên trình duyệt FireFox hoặc Safari để xem mã dự phòng hoạt động ra sao.

Lưu ý: Thư viện lazysizes cũng cung cấp plugin native loading được sử dụng để native lazy-loading khi có cơ hội nhưng vẫn có dự phỏng bằng chức năng tùy chỉnh của thư viện khi cần thiết.

Native lazy-loading ảnh hưởng như thế nào đến các quảng cáo trên trang web?

Tất cả các quảng cáo hiển thị cho người dùng dưới dạng ảnh hoặc iframe sẽ được lazy-load giống như bất kỳ ảnh hoặc iframe nào khác.

Ảnh sẽ được xử lý như thế nào khi trang web được in?

Mặc dù chức năng này không có trong Chrome 76, có một open issue để đảm bảo rằng tất cả ảnh và iframe được tải ngay lập tức nếu trang trong chế độ in ấn.

Kết luận

Triển khai lazy-loading ảnh và iframe dưới dạng native của trình duyệt có thể làm nhiệm vụ này trở nên dễ dàng hơn đáng kể cho mục tiêu cải thiện hiệu suất của trang web.

Nếu bạn để ý thấy bất kỳ hành vi bất thường nào với tính năng này trên Chrome hãy báo cho chúng tôi biết.

(Dịch từ bài viết: Native lazy-loading for the web, các tác giả: Houssein Djirdeh, Addy Osmani và Mathias Bynens, trang web: web[.]dev)

Thông tin bổ sung. Hiện tôi biết có 2 plugin cho WordPress hỗ trợ tính năng native lazy-loading là:

• Native Lazyload: do chính Google phát triển
• Flying Images: của tác giả Gijo Varghese.

The post NATIVE LAZY-LOADING LÀ GÌ, NÓ CẢI THIỆN TỐC ĐỘ WEBSITE NHƯ THẾ NÀO appeared first on Unest.

Chuyển hướng ảnh hưởng đến tốc độ trang như thế nào?

Bạn có bao giờ hỏi ai đó nơi bán bia Tiger, nhưng đến cửa hàng tạp hóa được chỉ thì nó lại đóng cửa rồi không? Và bạn sẽ phải tới mua một cửa hàng tạp hóa khác. Chuyển hướng giống như vậy đấy.

Chuyển hướng là nguyên nhân làm cho trang của bạn tải chậm hơn bởi vì nó làm phí phạm thời gian phải đến một địa chỉ nào đấy thông qua chuyển hướng từ một nơi khác.

Khi mà ngày càng có nhiều người sử dụng điện thoại di động, chuyển hướng cũng càng ngày có khả năng trở nên rắc rối hơn. Bất cứ website nào mới đây triển khai giải pháp SEO cho di động phải hết sức chú ý đến vấn đề chuyển hướng trên trang của họ. Chuyển hướng ảnh hưởng đến người dùng di động nhiều hơn vì họ sử dụng mạng di động có kết nối internet kém ổn định hơn nhiều so với người dùng máy bàn.

Có rất nhiều lý do tốt và chính đáng khi bạn muốn thực hiện chuyển hướng (chẳng hạn các link aff/tiếp thị liên kết hoặc trang của bạn đổi địa chỉ url), nhưng bạn phải ghi nhớ là chuyển hướng gây ảnh hưởng đáng kể đến hiệu năng và là nguyên nhân gây ra vấn đề tốc độ.

Bạn càng loại bỏ được nhiều chuyển hướng trên trang, bạn sẽ càng làm trang của mình tải nhanh hơn.

Tránh chuyển hướng

Nếu bạn không sử dụng bất cứ chuyển hướng nào, bạn đã giúp cho nội dung của bạn nhanh hơn đáng kể. Các chuyển hướng có khả năng trở thành vấn đề gây lãng phí thời gian lớn nhất trong mã nguồn của bạn, đặc biệt là khi bạn xem xét điều đó trên kết nối di động. Chúng ảnh hưởng đáng kể đến tốc độ trang theo cách đặc biệt tệ hại.

Chuyển hướng phía máy chủ: Nhanh, có thể lưu được trong bộ nhớ cache

Thường thì các chuyển hướng được xếp vào chuyển hướng 301 và 302, cái sử dụng HTTP để giải trình rằng một trang hoặc nguồn nào đó đã chuyển sang địa chỉ khác. Chuyển hướng 301 nghĩa là chuyển hướng dài hạn, lâu dài, còn chuyển hướng 302 nghĩa là chuyển hướng tạm thời. Cả hai đều là chuyển hướng phía máy chủ, điều này có nghĩa là máy chủ web sử dụng HTTP để chuyển hướng trình duyệt tới một địa chỉ file mới. Trình duyệt web có thể xử lý những kiểu chuyển hướng này nhanh hơn so với kiểu chuyển hướng phía máy khách và có thể lưu trong bộ nhớ cache địa chỉ chính xác của file.

Chuyển hướng phía máy khách: Chậm và không được lưu trong bộ nhớ cache

Các chuyển hướng này sử dụng thuộc tính http-equiv=”refresh” hoặc javascript nên có thể gây ra vấn đề thời gian chờ đợi dài hơn cũng như ảnh hưởng đến hiệu suất, chính vì vậy nó cần phải hạn chế sử dụng khi có thể.

Có chuyển hướng?

Bạn rất có khả năng đang có một vài chuyển hướng nào đấy. Có lẽ một trong các chuyển hướng phổ biến nhất trên web là chuyển hướng 301 để chuyển từ không-có-www sang phiên bản có-www (hoặc ngược lại). Các kiểu chuyển hướng này được khuyên dùng vì các lý do SEO trong rất nhiều năm vì thế nhiều người đã thực hiện chúng.

Lời khuyên của tôi nếu bạn đang có kiểu chuyển hướng này là bạn nên giữ nó lại để giúp Google hiểu trang web của bạn tốt hơn.

Làm thế nào để kiểm tra chuyển hướng?

Bạn có thể kiểm tra chuyển hướng trên các trang của bạn bằng cách sử dụng công cụ định vị chuyển hướng: https://varvy.com/tools/redirects/ (nó sẽ phát hiện và hiển thị các chuyển hướng 301 và 302).

Đây là thời điểm tốt để kiểm tra tất cả các trang của bạn về vấn đề chuyển hướng và xem nó ở đâu trên trang, cũng như suy nghĩ cách thay đổi chúng như thế nào, hoặc nó có đủ quan trọng để bạn chấp nhận điều đó làm chậm trang hay không.

Các khuyến nghị từ Google

Google khuyến khích việc loại bỏ các chuyển hướng khi mà nó không thực sự cần thiết. Họ khuyên bỏ chuyển hướng bằng cách…

• “Không bao giờ liên kết đến một trang mà bạn biết có chuyển hướng. Điều này hay xảy khi bạn thực hiện chuyển hướng thủ công, nhưng lại quên không thay đổi liên kết văn bản (text link) trong HTML của bạn để trỏ nó thẳng tới nguồn địa chỉ mới (thay vì phải chuyển hướng qua địa chỉ cũ).”
• “Không bao giờ yêu cầu hơn một chuyển hướng để đến bất kỳ nguồn tài nguyên nào của bạn. (chuỗi chuyển hướng, hay còn gọi là chuyển hướng nhiều lần)”

Đừng quên rằng trang web của bạn không chỉ có có mỗi HTML để tải về

Hầu như tất cả các trang web đều yêu cầu nhiều tài nguyên khác nhau để tải về. Bạn có thể cho rằng bản thân không có chuyển hướng dạng liên kết trang web nào trên HTML, nhưng còn liên kết dạng file CSS, ảnh hoặc javascript thì sao? Hãy đảm bảo rằng bạn biết rõ các tài nguyên nào của trang sẽ được gọi để tải về. Sử dụng công cụ kiểm tra tốc độ trang để làm điều đó: https://varvy.com/pagespeed/

Đảm bảo tất cả nguồn tài nguyên của bạn được gọi theo phương thức không tạo thêm chuyển hướng (Ví dụ – Nếu trang của bạn sử dụng “www” hãy đảm bảo là bạn gọi css và các file khác cũng cần sử dụng “www”).

Kiểm tra các chuyển hướng cũ

Bạn có thể muốn kiểm tra file .htaccess hoặc các file khác có nhiệm vụ cấu hình máy chủ web để xem các chuyển hướng cũ đang được thiết lập như thế nào. Những chuyển hướng này có thể được thêm vào cho một trang cụ thể hoặc một phần cụ thể trên website. Chúng có thể thực sự được thêm vào và không dễ gì để bạn biết được chúng nếu không chủ động tìm. Tôi bắt gặp nhiều trang web vẫn có các chuyển hướng về liên kết cũ thậm chí còn không tồn tại.

Loại bỏ các chuyển hướng

Có một số bước nhất định tốt nhất mà tôi tuân theo khi muốn loại trừ các chuyển hướng…

1. Tìm các chuyển hướng
2. Hiểu tại sao nó được chuyển hướng
3. Kiểm tra xem nó ảnh hưởng như thế nào / hoặc bị ảnh hưởng như thế nào bởi các chuyển hướng khác
4. Loại bỏ nếu thấy không cần thiết
5. Cập nhật nếu nó ảnh hưởng / hoặc bị ảnh hưởng bới các chuyển hướng khác
6. Nếu trang của bạn là bảo mật, xem xét sử dụng HSTS để loại bỏ chuyển hướng SSL

Làm sạch chuỗi chuyển hướng

Bạn thường cần phải để ý loại bỏ chuyển hướng trong tình huống mà bạn muốn làm sạch chuỗi chuyển hướng.

Một ví dụ trong chuyện này là khi bạn đã chuyển hướng tất cả trang của bạn từ phiên bản không-có-www sang phiên bản có-www…

Sau đấy bạn lại chuyển hướng tất cả lưu lượng của bạn sang phiên bản bảo mật https.

Trong kịch bản này bạn đã chuyển hướng người dùng từ ten-mien-cua-ban.com sang www.ten-mien-cua-ban.com rồi sau đấy lại chuyển hướng đến “https://www.ten-mien-cua-ban.com”. Điều này thường xuyên xảy ra.

Giải pháp cho vấn đề này là đảm bảo chuyển hướng cũ không chuyển hướng từ không-có-www sang có-www mà phải là chuyển từ không-có-www sang thẳng luôn https://www (hoặc các tình huống khác tùy theo yêu cầu của bạn). Mục tiêu là đảm bảo chuyển hướng của bạn đến trực tiếp nơi cần đến thay vì đi qua một trung gian nữa.

Lần cuối cùng bạn gõ “www” là khi nào (chắc hẳn là cách đây lâu lắm rồi), còn lần cuối bạn làm thế trên di động (có lẽ là chưa bao giờ luôn).

Một ví dụ khác về chuyển hướng cần phải làm sạch cũng tương tự ví dụ trên nhưng là cho một trang cụ thể. Giả dụ bạn có tất cả các chuyển hướng tôi mô tả ở trên, nhưng nhiều năm trước đây bạn thực hiện chuyển hướng 301 cho một số trang nào đấy. Vì thế mà các chuyển hướng cũ trước đây giờ lại trỏ đến một địa chỉ khác mà bản thân địa chỉ ấy cũng phải chuyển hướng, và do đó tạo thành chuỗi chuyển hướng phức tạp.

Ví dụ về chuyển hướng đúng cách

Hãy xem trang Vnexpress.net, sử dụng công cụ Varvy ở trên, bạn sẽ thấy họ chuyển hướng đúng như thế nào, tất cả chỉ là chuyển hướng một lần chứ không phải chuỗi chuyển hướng:

• Nếu khách truy cập url dạng http://www.vnexpress.net (có-www và không bảo mật), họ sẽ được chuyển thẳng đến dạng https://vnexpress.net (không-có-www và bảo mật)
• Tương tự là các trường hợp khác, người dùng chỉ cần 1 lần chuyển hướng duy nhất
• Cái cuối cùng là vào thẳng trang, không cần chuyển hướng

Ví dụ về chuyển hướng không đúng cách

(Dịch từ bài viết: Minimize redirects – Tác giả: Patrick Sexton – Website: Varvy)

The post Tối thiểu hóa chuyển hướng trong tăng tốc website appeared first on Unest.

Render nghĩa là trang web được kết xuất, hiển thị cho người dùng, vì vậy nếu điều gì đó làm chặn hiển thị (render-blocking), điều đó có nghĩa là nó làm cho trang không được hiển thị cho người dùng nhanh nhất trong khả năng.

Lưu ý nhỏ: bài viết này nói về JavaScript chặn hiển thị, không phải CSS chặn hiển thị (chúng là những cái rất khác nhau, mặc dù đều gây ra phiền toái làm trang web chậm hiển thị cho người duyệt web).

JavaScript chặn hiển thị

Google khuyến nghị loại bỏ hoặc trì hoãn JavaScript gây trở ngại cho việc tải phần nội dung của trang nằm trên màn hình đầu tiên (above the fold).

Màn hình đầu tiên có nghĩa là những gì mà người dùng thấy đầu tiên trên màn hình (chưa cần cuộn chuột, hoặc “vuốt vuốt”). Màn hình này có thể là điện thoại, iPad, máy bàn hoặc bất kỳ thiết bị nào người dùng sử dụng để xem trang web của bạn.

Thực hành này đã được sử dụng từ lâu bởi những người tìm cách tăng tốc trang web, nhưng nó vẫn còn mới mẻ với phần lớn những người quản trị, thiết kế web và có thể gây ra một chút nhầm lẫn, thậm chí có thể không biết làm thế nào.

Loại bỏ JavaScript chặn hiển thị không chỉ là có thể làm được, nó còn là yêu cầu của người dùng muốn tốc độ cao. Thậm chỉ nếu bạn chẳng quan tâm đến người dùng có kết nối internet chậm, bạn phải quan tâm đến thứ hạng của mình trên Google. Thứ hạng của bạn trên Google sẽ không ổn nếu bạn không tối ưu hóa vấn đề này. Đặc biệt nếu Google thấy trang web của bạn không tải thuận lợi trên một số thiết bị nhất định (điện thoại di động, máy tính bảng, vân vân) họ sẽ không đưa trang của bạn vào kết quả tìm kiếm, vì Google không muốn gửi người dùng đến một trang chậm chạp hoặc trang mà người dùng phải đợi rất lâu mới có được nội dung.

Làm thế nào để xác định được JavaScript chặn hiển thị

Bạn cần phải biết trang của mình đang tải cái gì. Có một số cách để làm điều này. Tôi gợi ý bạn nhìn sâu vào những gì trang đang tải bằng công cụ pagespeed: https://varvy.com/pagespeed/ để có cái nhìn tổng quan về các vấn đề của trang hoặc giao diện gặp phải. Để biết được các file cụ thể đang chặn hiển thị bạn phải sử dụng công cụ Google pagespeed insights. Công cụ này sẽ nói cho bạn biết chính xác những file nào đang chặn một trang cụ thể.

Làm thế nào để loại bỏ JavaScript chặn hiển thị

Một trong các thủ phạm phổ biến nhất về JavaScript chặn hiển thị, và cũng là một ví dụ rất tốt cho vấn đề này là jQuery – một tệp JavaScript được sử dụng bởi một tỷ lệ lớn trang web trên toàn cầu. Rất có khả năng là bạn đang sử dụng nó (nếu đúng vậy hãy tìm hiểu thêm công cụ của Varvy).

jQuery là một tệp khá nặng, trong thực tế nó có thể là file lớn nhất mà trang web của bạn cần tải để render (hiển thị) trang.

jQuery là một tệp JavaScript phổ biến, và thường được sử dụng để làm những việc rất đơn giản như là các kỹ thuật fade in (hiện ra dần dần) hoặc fade out (biến mất dần dần) cho ảnh. Thông thường không có lý do để tải jQuery trước khi bạn tải trang, nhưng phần lớn các trang web lại đang làm điều đó.

Nếu thành phần của website sử dụng jQuery nằm dưới màn hình đầu tiên thì bạn không có lý do gì để tải nó trước khi nó được dùng đến. Nếu bạn tải nó trước, bạn đang không làm theo hướng dẫn về tăng tốc trang và bạn làm cho người dùng phải chờ đợi.

Để sửa lỗi này, bạn cần phải thay đổi vị trí mà jQuery được gọi. Điều này được thực hiện trong HTML của trang web. Cách thức mà phần lớn các trang web hiện nay sử dụng là gọi jQuery ở trong phần đầu (nằm trong thẻ <head>) của tài liệu như được trình bày bên dưới:

<head>
<meta name=description content="description here."/>
<title>title here</title>
<style>
styles here
</style>
<script src="jquery.js">
</script>
</head>

Nó gọi đến jQuery (một file khá lớn) và được tải xuống bởi trình duyệt trước khi bất cứ điều gì khác được hiển thị trên trang. Đây là điều không tốt. Điều này thực sự tệ hại nếu thứ mà bạn cần đến jQuery là không cần thiết cho phần nội dung thuộc màn hình đầu tiên như trong hình trên cho thấy.

Giải pháp không hoàn chỉnh thường được sử dụng

Thường thì lệnh gọi tới jQuery sẽ được loại bỏ khỏi phần đầu của tài liệu và chuyển xuống vị trí nào đó khác ở dưới sâu hơn của trang, vì để ở phần đầu là không cần thiết. Thật không may điều đó là không đủ.

<!-- những phần không cần đến jquery (hầu hết các trang web) nằm ở đây-->
<script src="jquery.js">
</script>
<!-- những phần cần đến jQuery nằm ở đây -->

Giải pháp thực sự/tốt hơn

Để hoàn toàn loại bỏ JavaScript khỏi tuyến render, nó cần phải được trì hoãn tải cho đến khi trang tải xong. Tôi có một hướng dẫn để làm điều này sử dụng các khuyến nghị của Google để trì hoãn hoàn toàn JavaScript.

Để làm điều này tốt bạn cần phải biết trang của bạn tải cái gì và tại sao nó lại tải những thứ ấy?

Bất cứ điều gì mà trang web của bạn gọi đến đều làm người dùng của bạn tốn thời gian. Nếu bạn không biết trang của mình yêu cầu điều gì, bạn cần phải thay đổi điều này. jQuery là một ví dụ tốt bởi vì nó rất phổ biến cũng như là file có dung lượng lớn (khoảng 100KB). Một kịch bản phổ biến là một trang web nhỏ chỉ khoảng 10KB đang gọi một file lớn như jQuery (cái tốn thời gian hơn mười lần so với chính bản thân trang web) để làm một nhiệm vụ khá là đơn giản như làm chữ hiện dần lên trên trang! Khi nhìn vào, bạn có thể có ý nghĩ này “zee, nó trông thật tuyệt!”, nhưng liệu nó có đủ tuyệt để làm người dùng tốn thời gian hơn mười lần để thấy trang của bạn? Bạn có thể dễ dàng có được hiệu ứng tương tự với CSS hoặc file JavaScript nhỏ hơn nhiều.

Tôi sử dụng jQuery làm ví dụ nhưng tôi không có ý nói rằng nó tệ hại. Điều tương tự cũng có thể được nói về những đoạn mã JavaScript thậm chí còn phổ biến hơn chẳng hạn như Google Analytics, hoặc JavaScript của bên thứ ba dùng để hiển thị widget hoặc chỉ đơn giản là các nút bấm mạng xã hội như Facebook, Twitter mà mọi người rất yêu thích.

Cần phải biết trang của bạn đang sử dụng những gì, và quyết định xem nó có đáng giá đề khiến người duyệt web phải chờ đợi không

• Công cụ pagespeed là cách hay để xem trang của bạn đang sử dụng cái gì.
• Để loại trừ JavaScript chặn hiển thị bạn phải trì hoãn tải nó.

P/S: Nếu bạn dùng WordPress, các plugin như Autoptimize và Async JavaScript là các lựa chọn tốt để loại bỏ các JavaScript chặn hiển thị, bao gồm cả jQuery khi cần thiết.

(Dịch từ bài viết: Render blocking javascripts – Tác giả: Patrick Sexton – Website: Varvy)

The post Cách loại bỏ JavaScript chặn hiển thị appeared first on Unest.

Bài viết này chủ yếu là phần lý thuyết về việc loại bỏ chặn hiển thị CSS. Nó có ích nhất cho những ai làm lập trình web, viết giao diện tối ưu cho tốc độ hơn.

Nếu bạn đơn thuần đang sử dụng các CMS sẵn có như WordPress, bài viết này không cung cấp các plugin cụ thể để bạn tối ưu, nhưng nó cũng có ích để bạn hiểu cơ chế căn bản. Nếu thuộc dạng người dùng này mẹo để giảm các CSS chặn hiển thị đó là:

• Chọn theme tối ưu cho tốc độ hoặc ít nhất là chọn theme từ những nhà cung cấp uy tín
• Hạn chế sử dụng plugin và chỉ sử dụng plugin chất lượng (mã sẽ được viết tốt hơn)
• Sử dụng các công cụ tạo critical CSS và trì hoãn tải các CSS không quan trọng (hầu hết các plugin chuyên tăng tốc như WP-Rocket, Swift Performance đều tích hợp sẵn tính năng này)

OK, giờ chúng ta sẽ đi vào chủ đề chính.

CSS chặn hiển thị trang là gì?

• CSS chặn hiển thị trang (render) làm website bị chậm hiển thị.
• Mọi file CSS của bạn đều làm trang bị trì hoãn (delay) hiển thị (dù ít dù nhiều).
• File CSS của bạn càng lớn (về mặt kích cỡ), thời gian để trang hiển thị càng lâu.
• Bạn càng có nhiều file CSS (về số lượng), thời gian để hiển thị trang càng lâu.

Tại sao CSS chặn hiển thị trang lại không tốt

CSS chặn hiển thị (render blocking) làm cho trang tải chậm.

Không thành vấn đề là hiện bạn kiếm được bao nhiêu tiền từ trang web của mình, nếu tốc độ trang web nhanh hơn nó sẽ giúp bạn kiếm được nhiều hơn nữa. Ví dụ:

• Quảng cáo Adsense giúp trang kiếm được nhiều tiền hơn nếu quảng cáo được hiển thị trên trang nhanh hơn và dài hơn.
• Các trang thương mại điện tử (e-commerce) kiếm được nhiều tiền hơn bằng cách giảm tỷ lệ người mua rời bỏ giỏ hàng và cung cấp trải nghiệm người dùng tốt hơn, đồng thời giảm sự bực bội.

Làm thế nào để loại bỏ CSS chặn hiển thị?

1. Gọi đúng file CSS của bạn
2. Giảm số lượng file CSS trong đường dẫn quan trọng (critical path)
3. Nói chung cần sử dụng ít CSS về mặt tổng thể

Bài viết này sẽ thực sự đi sâu vào từng lựa chọn trên và bao gồm cả các cách thức để bạn tự làm, các mẹo hữu ích (handy tips) để hướng dẫn nhà thiết kế hoặc người quản trị web làm điều đó cho bạn, và minh họa vấn đề đủ để bạn hiểu rõ từng giải pháp.

Chúng tôi sẽ bắt đầu với phần dễ nhất trong các giải pháp…Gọi đúng file CSS là quy tắc được khuyến nghị bởi Google.

1. Làm thế nào để gọi đúng CSS

CSS có thể được gọi bằng nhiều cách thức khác nhau từ trang web của bạn, nhưng một số cách thức là hoàn toàn sai lầm trong thế giới di động hiện đại và cần tốc độ cao.

Bên dưới đề cập đến hai sai lầm trong việc gọi file CSS của bạn.

• Sử dụng @import để gọi các file css
• Nhãn css có điều kiện không chính xác

Sử dụng @import và nhãn dán css không chính xác gây ra vấn đề chặn hiển thị, và chúng có thể giải quyết được dễ dàng, hãy tìm hiểu nó kỹ hơn bên dưới.

Không sử dụng @import để gọi CSS

Vấn đề: Phương thức gọi CSS này không tốt bởi vì nó làm tăng thời gian tải CSS của bạn trước khi trang của bạn có thể hiển thị.

Giải pháp: Xác định các vị trí @import và thay thế chúng.

Phát hiện: Sử dụng công cụ trực tuyến để làm việc này, chẳng hạn như: https://varvy.com/pagespeed/. Ở cột bên trái có một (trong các) mục là “Avoid @CSS import”. Nếu bạn thấy dấu check màu xanh nghĩa là không có vấn đề gì về @import. Nếu vấn đề được tìm thấy bạn sẽ có dấu “x” màu đỏ để báo hiệu.

Chi tiết: CSS import trông giống như thế này và sẽ thường được đặt ở gần phần đầu tệp tin.

@import url("style.css")

Thay vì gọi file CSS sử dụng phương thức @import, tốt hơn là giữ các file CSS bổ sung trong một file (bạn copy và paste import CSS vào trong file CSS gốc). Nếu bạn không thể làm được điều đó vì một lý do nào đấy, bao gồm các file CSS này trong file HTML bằng cách sử dụng đoạn code sau…

<link rel="stylesheet" href="style.css">

Nhớ là thay thế “style.css” bằng tên file CSS của bạn.

Sử dụng nhãn dán CSS chính xác

Vấn đề: Khi CSS không được dán nhãn chính xác, các trình duyệt mặc định tải tất cả file CSS trước khi render (hiển thị) trang.

Giải pháp: Nhờ việc dán nhãn các file CSS chính xác, trình duyệt sẽ biết không cần phải yêu cầu tất cả các file để bắt đầu hiển thị trang.

Nhận biết: Kiểm tra nội dung HTML của bạn và xem cách CSS của bạn được dán nhãn (được mô tả rõ hơn bên dưới).

Chi tiết: Một file CSS điển hình được gọi như dưới đây:

<link href="style.css" rel="stylesheet">

Trong đoạn code bên trên nó nói rằng “đây là một liên kết” và “liên kết là cho CSS của tôi”.

Bất kỳ CSS nào được gọi theo cách thức trên sẽ luôn luôn được tải trước bởi trình duyệt để render bất cứ điều gì trên trang web của bạn.

Giờ hãy xem ví dụ về file CSS mà nó không cần tải trước khi render trang, cụ thể là file CSS dùng để hướng dẫn in ấn…

<link href="print.css" rel="stylesheet" media="print">

Đoạn code trên nói rằng “đây là một liên kết”, “liên kết trên là cho CSS của tôi” và nó cũng nói rằng “CSS được dùng chỉ cho việc in ấn thôi”.

Vì CSS được dán nhãn là media=”print”, các trình duyệt hiện đại biết rằng file CSS này không cần thiết cho việc hiển thị trang. Hệ quả là, trình duyệt sẽ đặt ưu tiên thấp hơn cho file CSS như vậy. Nó sẽ vẫn tải file CSS, nhưng CSS đó không còn là vấn đề gây ra chặn hiển thị nữa.

Hãy xem một tình huống khác, ở đây chúng ta có một file CSS được sử dụng khi chiều rộng trang được chỉ định rõ:

<link href="other.css" rel="stylesheet" media="(min-width: 40em)">

Các trình duyệt hiện đại có thể hiểu rằng file CSS này được sử dụng trong một số tình huống và không được sử dụng trong một số tình huống khác, vì thế trình duyệt có thể lựa chọn không tải CSS này để hiển thị trang nếu nó thấy không cần thiết.

2. Sử dụng ít file CSS hơn trong các đường dẫn chính

Đường dẫn hiển thị chính chỉ là cách khác để nói về “các thứ mà trình duyệt phải làm trước khi hiển thị trang web của bạn”.

Nếu bạn đã dán nhãn chính xác file CSS như chúng ta vừa thảo luận ở trên, bạn đã bắt đầu công việc loại bỏ các file CSS khỏi đường dẫn quan trọng. Tuy nhiên vẫn có rất nhiều điều chúng ta có thể làm.

Để rõ ràng hơn, chúng ta đang thảo luận về các file CSS ở dạng như “main.css” và “page.css”, vân vân. Chúng ta nhấn mạnh vào các file CSS cụ thể, hơn là các đoạn code CSS được viết bên trong những file đó.

Mỗi file vật lý mà bạn có thể loại bỏ sẽ làm trang của bạn tải nhanh hơn.

Có hai cách cơ bản để làm giảm các file css:

• Kết hợp các file CSS
• Inline (nội tuyến) CSS

Kết hợp các file CSS

Vấn đề: Mỗi file CSS trang bạn sử dụng làm tốn thêm thời giản tải trang vì nó yêu cầu thêm file để gọi.

Giải pháp: Kết hợp các file CSS thành một file (hoặc hai tùy thuộc vào độ lớn thực tế của CSS).

Chi tiết: Một trang web thường có một file CSS lớn và một vài file CSS “hỗ trợ”. Điều này xảy ra vì rất nhiều nguyên nhân, ví dụ như có thể một trang WordPress có CSS định dạng web trong một file CSS lớn, nhưng các widget và plugin bạn thêm vào có thể có các file CSS nhỏ liên kết với chúng mà được tải độc lập với CSS chính của bạn.

Điều này cũng xuất hiện trong các trang web tĩnh bởi vì nhiều người thiết kế web cho rằng sẽ tốt hơn khi chia các file CSS làm việc riêng biệt để công việc được dễ dàng hơn. Thật không may, điều này là nguyên nhân gây ra vấn đề lớn cho hiệu năng của website.

Thông tin tốt là việc có các file CSS tách biệt rất phổ biến, nên bạn có thể dễ dàng có được cải tiến về tốc độ so với đối thủ bằng cách tập trung hơn vào vấn đến này. Sự khác biệt giữa việc phải tải ít file CSS so với nhiều CSS thường có thể giúp bạn tiết kiệm được một giây thời gian tải trang.

Thậm chí điều còn quan trọng hơn cả thời gian tiết kiệm được là: trong thực tế, việc giảm sự phức tạp của CSS cho phép những cái khác tải nhanh hơn. Nếu bạn kiếm tiền từ Adsense, quảng cáo của bạn sẽ hiển thị nhanh hơn (vì chúng không còn phải cạnh tranh với các file CSS để tải). Nếu bạn muốn cho người dùng trải nghiệm tốc độ cao nhất trong các cửa hàng thương mại điện tử của mình, một lần nữa, hãy giảm số lượng các file CSS.

Nói cách khác, khi bạn nghĩ về việc làm tốc độ trang nhanh hơn, mọi sự phức tạp được loại bỏ cho phép không chỉ “x” giây bạn tiết kiệm được mà còn cho phép các thành phần khác trên trang có hiệu năng tốt hơn.

Làm thế nào để kết hợp các file CSS

Để kết hợp CSS, bạn phải copy CSS từ một file CSS và paste nó vào file khác. Một khi bạn làm điều này, bạn cần loại bỏ các lời gọi CSS trước đây (file dùng copy).

Trong hình trên chúng tôi lấy nội dung trong file “other.css” và “third.css” và đưa nó cả vào trong file “main.css”. Nhờ làm vậy, chúng tôi chuyển từ việc trang web yêu cầu ba file CSS để hiển thị thành việc trang chỉ cần gửi yêu cầu cho một file CSS để hiển thị.

P/S: Nếu bạn đang dùng WordPress, plugin Autoptimize là ứng cử viên tốt trong nhiệm vụ gộp nén CSS, nó thậm chí có thể tạo critical CSS miễn phí.

Inline các file CSS

Vấn đề: Mỗi file CSS trang web bạn sử dụng làm tốn thêm thời gian tải trang vì nó yêu cầu thêm lời gọi bổ sung file.

Giải pháp: Loại bỏ một file CSS bằng cách thay thế nó và chèn thẳng trong mã HTML.

Chi tiết: Sử dụng thẻ style trong HTML, các chỉ dẫn CSS được đưa vào bên trong file HTML thay vì sử dụng các file CSS ngoài (external CSS file)

Làm thế nào để inline CSS

Để inline CSS, bạn phải copy mã CSS từ một file CSS và paste nó chính xác vào file HTML (điều này chỉ có thể làm được với các file CSS nhỏ, nếu không file HTML của bạn sẽ trở nên quá lớn). Một khi bạn làm điều đó, bạn cần phải loại bỏ các lời gọi file CSS cũ.

Trong ảnh trên chúng tôi lấy nội dung của file “small.css” và thay thế chúng bằng cách chèn vào trong file HTML. Bằng cách làm điều này, chúng tôi chuyển việc trang web yêu cầu hai file CSS thành việc chỉ yêu cầu một file CSS để tải.

Các CSS inline được đặt trong phần đầu của tài liệu HTML sử dụng thẻ style.

<style>
.... CSS của bạn được đặt ở đây .....
</style>

P/S: Trong WordPress, các CSS dùng để inline (nội tuyến) chính là các critical CSS – các đoạn mã CSS quan trọng nhất dành cho việc hiển thị nội dung thuộc màn hình đầu tiên.

3. Sử dụng ít CSS hơn về tổng thể

“Sử dụng ít CSS” là chuyện nói dễ hơn là làm.

Có một số lý do giải thích tại sao có nhiều CSS không hữu ích yêu cầu tải trong hầu hết các website.

• Các theme WordPress có thể tùy chỉnh có hàng tá CSS bổ sung không cần thiết
• Các framework đóng vai trò nền tảng hoặc bootstrap có ích, nhưng CSS không được căn chỉnh, tối ưu cho website cuối cùng
• Nói chung, ngày xưa, số lượng CSS không phải là điều cần phải lo lắng, vì thế các nhà thiết kế làm công việc của họ trở nên dễ dàng hơn qua việc sử dụng nhiều CSS hơn cần thiết

Dù lý do khiến CSS của bạn lớn là gì đi chăng nữa thì bạn vẫn cần tìm cách làm cho nó nhỏ hơn và thông minh hơn.

Thực tế

Nếu bạn viết CSS hoặc là một trong những người tham gia vào, bạn có thể giảm thiểu thời gian bằng cách chỉ thêm CSS khi cần thiết.

Tuy nhiên nhiều khả năng là bạn đã mua một giao diện hoặc thiết kế của người khác, và trong trường hợp này chỉ có giải pháp thực tế là nói với người thiết kế đã tạo ra CSS và yêu cầu một phiên bản nhẹ nhàng hơn.

Nếu bạn xem xét một giao diện hoặc thiết kế mới, bạn có thể tiết kiệm được thời gian và tiền bạc bằng cách đặt mục tiêu tối ưu hóa phân phối CSS là một trong các yêu cầu của dự án.

Các công cụ

Varvy có tạo một công cụ để kiểm tra phân phối CSS: https://varvy.com/tools/css-delivery/ để giúp mọi người kiểm tra xem CSS của họ được sử dụng như thế nào trên trang.

Cũng có công cụ xác định tốc độ trang: https://varvy.com/pagespeed/ dùng để xác định nhiều vấn đề CSS phổ biến.

Đào sâu hơn

Nếu bạn muốn học hỏi nhiều hơn về lý do và cách thức CSS ảnh hưởng đến tốc độ tải trang bạn có thể muốn tìm hiểu Mô hình Đối tượng CSS: https://varvy.com/performance/cssom.html

(Được dịch từ bài viết: Eliminate render blocking css – Tác giả: Patrick Sexton – Website: Varvy)

The post Cách loại bỏ CSS chặn hiển thị appeared first on Unest.

• Ảnh trì hoãn (deferred image) là ảnh chỉ được tải xuống sau khi nội dung thuộc màn hình đầu tiên (initial page) tải xong.
• Các hình ảnh không nằm trong màn hình đầu tiên (below the fold) có thể được trì hoãn, điều đó cho phép nội dung website tải nhanh hơn.

Trì hoãn tải hình ảnh giúp trang tải nhanh hơn

Bài viết này sẽ hướng dẫn bạn cách đơn giản để áp dụng trì hoãn tải ảnh mà không cần đến jQuery hoặc lazy loading (tải lười biếng).

Một trong những lý do chính khiến trang web bị tải chậm là do trang có nhiều ảnh. Người dùng ở khắp nơi trên thế giới đều thấy một hiện tượng phổ biến là các ảnh được tải xuống chậm chạp từ trên xuống dưới.

Thậm chí ngay cả khi người dùng thấy các ảnh được tải chậm từ từ, thường vẫn có nhiều ảnh phía sâu bên dưới trang không cần hiển thị cho người dùng ngay lúc đó, trong khi chúng cũng vẫn đang được tải.

Tất cả những ảnh này cạnh tranh với nhau cho lượng băng thông giới hạn cũng như cạnh tranh với các nguồn tài nguyên khác chẳng hạn như CSS và JavaScript. Điều đó nghĩa là các ảnh đang cản trở việc hiển thị phần nội dung thuộc màn hình đầu tiên của trang web cho người dùng trong khả năng nhanh nhất có thể của nó.

Đây là vấn đề đã được biết đến nhiều rồi

Cách chính mà nhà phát triển và người quản trị web giải quyết vấn đề này là thông qua một phương thức gọi là lazy loading (tải lười biếng).

Các ảnh tải lười là một giải pháp trong đó khi người dùng cuộn chuột xuống bên dưới, các ảnh trong khung nhìn mới được tải, các ảnh bên dưới thì không (tải ảnh theo nhu cầu của người dùng). Có rất nhiều điều thú vị về phương thức tải lười và tôi sử dụng nó thường xuyên, nhưng nó có một số vấn đề…

• Lazy loading có thể là nguyên nhân gây ra vấn đề về hiệu suất, tốc độ.
• Lazy loading không phải là một giải pháp khả thi cho một số trang web.
• Lazy loading không phải là ý tưởng hay để giải quyết vấn đề về hiệu suất, tốc độ trên di động.

Trì hoãn tải ảnh mà không cần lazy loading hoặc jQuery

Sự thật thì lazy loading ảnh là cách thức phức tạp hơn của trì hoãn tải ảnh mà thôi.

Để quay lại vấn đề cơ bản, chúng ta sẽ thảo luận về trì hoãn tải ảnh mà không có lazy loading. Nhưng trước hết hãy xem những việc mà lazy loading thực sự làm là gì đã.

1. Quan sát (Observing) vị trí cuộn chuột
2. Giám sát (Monitoring) vị trí cuộn chuột
3. Phản ứng (Reacting) với vị trí cuộn
4. Trì hoãn (Deferring) tải ảnh

Trong bốn bước kể trên, chỉ có một cái trong số chúng là trì hoãn tải ảnh.

Chúng ta hãy thảo luận về phần trì hoãn ảnh

Khi một trang web được render (hiển thị) trên trình duyệt, trình duyệt sẽ cố gắng tải tất cả ảnh nó có thể tìm thấy trên trang. Nếu có hai ảnh trên trang, nó sẽ tải cả hai ảnh. Nếu có một trăm ảnh trên trang, nó sẽ tải cả một trăm ảnh.

Đấy là hành vi mặc định của trình duyệt. Nó phải yêu cầu và tải về tất cả các ảnh.

Cách đáng tin cậy nhất quanh vấn đề này (với tất cả các trình duyệt) là đánh lừa trình duyệt để nó nghĩ rằng những ảnh này không có ở đó.

Cách thức này được thực hiện trong lazy loading, cũng như bất cứ vị trí nào khác nhằm cung cấp một ảnh nhỏ mặc định trong mã HTML của chúng ta, và sau đó chuyển ảnh mặc định sang ảnh chúng ta thực sự muốn hiển thị thông qua JavaScript.

Điều này có nghĩa là các ảnh sẽ được đánh dấu trong mã giống như dưới đây…

<img src="anh-gia.png" data-src="anh-that.png"

Khi trang đã thực hiện tải nội dung thuộc màn hình đầu tiên rồi, trình duyệt sẽ nhận được “ảnh giả” và điều đó chỉ có trình duyệt nhận thấy mà thôi, vì thế cho dù bạn có một ảnh hay một trăm ảnh cũng chẳng thành vấn đề, bởi vì trình duyệt đã tải các ảnh giả rồi.

Sau đó thông qua JavaScript, chúng ta tráo đổi ảnh giả tương ứng bằng ảnh thật.

Khi trình duyệt thấy rằng có một ảnh mới (ảnh thật) trong HTML, nó sẽ tải ảnh đó ngay lúc ấy.

Bước tương đối đơn giản này có thể tạo ra được kết quả rất tuyệt vời. Vừa mới đây thôi, tôi đã biến một trang phải mất tám giây để tải thành chưa đến một giây chỉ nhờ phương pháp đó (chúng ta sẽ mô tả phương pháp này đầy đủ ngay bên dưới với các code mẫu để các bạn tham khảo).

Hiểu cách trang web tải xuống

Để hiểu được cách thức, thời điểm và phương thức trì hoãn được dùng, chúng ta cần phải hiểu cách tải trang diễn ra như thế nào. Đây là kiến thức quan trọng cần biết và nó chỉ khiến bạn tốn một hoặc hai phút để hiểu mà thôi.

Ảnh trên cho thấy một trang web nhỏ tải ra sao. Trang có một ảnh chính, một vài ảnh khác, một file CSS và một file JavaScript.

Trong trang khá điển hình này, mỗi nguồn tài nguyên phải cạnh tranh với nhau để được tải về.

Sự thật là chỉ một số thứ cần tải ngay xuống lúc ban đầu, đó là các phần ở bên trên đường chấm chấm (- – – – – -)

Đây là phần được gọi là “trong màn hình đầu tiên” hoặc phần nội dung đầu tiên được nhìn thấy của trang web.

Điều này nghĩa là với người dùng muốn thấy nội dung màn hình đầu tiên nhanh nhất có thể, chúng ta chỉ cần tải HTML, CSS, JavaScript và ảnh chính là đủ.

Hãy xem cách chúng ta có thể làm trang này tải nhanh hơn gấp đôi (thậm chí còn hơn) như thế nào nhé. Chúng ta cần…

• Chỉ tải ảnh chính thôi
• Trì hoãn tải các ảnh còn lại

Khi chúng ta làm điều đó, chúng ta sẽ thấy rằng trang sẽ tải nhanh hơn nhiều, người dùng sẽ thấy nội dung sớm hơn.

Giờ chúng ta đã cắt giảm từ một trang phải yêu cầu tải đến 12 tài nguyên mới được phép hiển thị xuống trang chỉ cần tải 4 tài nguyên thôi cũng đã đủ cho người dùng thấy nội dung rồi.

Tôi thích điều này.

Nó có nghĩa là quảng cáo Adsense có thể hiển thị nhanh hơn, người dùng của tôi có thể mua hàng sớm hơn, và Google đánh giá cao website của tôi.

Trung thực hơn thì bạn và tôi đều biết rằng các trang của chúng ta có hàng tá ảnh, không chỉ có vài bức như trong minh họa trên. Đừng mắc sai lầm. Phương thức này có thể làm trang của bạn tải nhanh hơn rất nhiều. Bạn càng có nhiều ảnh trên trang, bạn càng tiết kiệm được nhiều thời gian với phương thức này.

Liệu lazy loading có làm điều này cho tôi không?

Nó có chứ, nhưng có nhiều tình huống mà lazy loading không phải là biện pháp lý tưởng.

Lý do phổ biến nhất là mọi người có thể chọn không trì hoãn tải hình ảnh thông qua tải lười biếng, và đây có thể là xu hướng phổ biến mới trong việc tạo các giao diện một trang.

Giao diện một trang / One page templates

Nếu bạn có giao diện một trang (điều này có nghĩa là thanh điều hướng chính của bạn không đưa bạn tới các trang khác mà là đưa bạn đến các phần khác nhau của cùng một trang) và nếu bạn chọn tải lười biếng (lazy loading), một rắc rối không hề nhỏ sẽ nổi lên.

Khi trang bạn tải, người dùng thấy thanh điều hướng chính của bạn, và nếu họ click, họ được đưa đến phần khác của trang mà hiện không có ảnh nào được tải sẵn lúc ấy.

Chẹp, tôi chẳng thích điều này đâu.

Trong trường hợp này cho dù người dùng chỉ sử dụng điều hướng của bạn, họ vẫn bị đưa đến các vị trí mà họ phải chờ đợi để ảnh tải xong.

Đây là lúc chúng ta thực hiện việc trì hoãn tải ảnh thay vì tải lười biếng

Trong kịch bản giao diện một trang (one page template), không có lý do nào để bạn phải thiết lập tất cả mọi thứ tải lười biếng (quan sát, theo dõi và phản ứng thích hợp với vị trí cuộn chuột).

Tại sao chúng ta không trì hoãn tải ảnh và giúp ảnh được tải ngay lập tức sau khi trang tải xong.

Làm nó thế nào đây?

Để làm điều đó chúng ta cần đánh dấu ảnh của mình và thêm một đoạn JavaScript rất nhỏ và cực kỳ đơn giản. Tôi sẽ cho bạn thấy phương thức mà tôi sử dụng trong thực tế cho trang này và các trang khác. Nó sử dụng ảnh base 64, nhưng đừng để khái niệm mới này làm bạn lo lắng.

Mã HTML:

<img src="data:image/png;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs=" data-src="anh-that-cua-ban-o-day">

Và JavaScript:

<script>
function init() {
var imgDefer = document.getElementsByTagName('img');
for (var i=0; i<imgDefer.length; i++) {
if(imgDefer[i].getAttribute('data-src')) {
imgDefer[i].setAttribute('src',imgDefer[i].getAttribute('data-src'));
} } }
window.onload = init;
</script>

Sử dụng

Với hầu hết các trang bạn có thể đơn giản thêm mã này ngay trước thẻ đóng </body> trong mã HTML và thay thế “anh-that-cua-ban-o-day” bằng đường dẫn hình ảnh thực tế của bạn.

(Dịch từ bài viết: How to defer images – Tác giả: Patrick Sexton – Website: Varvy)

The post Cách trì hoãn tải ảnh giúp tăng tốc độ website appeared first on Unest.

Một số biện pháp đó bao gồm:

• Nén ảnh: gồm nén ảnh mất chất lượng và không mất chất lượng để giảm dung lượng ảnh. Có rất nhiều plugin WordPress có thể làm được công việc này
• Sử dụng định dạng ảnh mới WebP: cho ảnh có chất lượng tương đương nhưng dung lượng giảm khá tốt. Bản thân WebP cũng là một dạng ảnh nén (tuy nhiên WebP gặp một cản trở rất lớn là hiện vẫn chưa được tất cả các trình duyệt phổ biến hỗ trợ, trong khi các đoạn mã hỗ trợ dự phòng cả 2 định dạng ảnh lại là vấn đề rất kỹ thuật, gây cản trở cho người quản trị không chuyên sâu về code)
• Sử dụng CDN để giảm độ trễ của mạng internet do quãng đường truyền tải dữ liệu xa đến máy chủ gốc, nó được áp dụng cho tất cả các file tĩnh khác, chứ không riêng gì ảnh
• Lazy load: là kỹ thuật xài đến đâu tải đến đó, chỉ khi ảnh trong (hoặc ở gần) khung nhìn trình duyệt (viewport) của người dùng thì trình duyệt mới tải ảnh từ máy chủ về

Nếu bạn muốn tìm hiểu kỹ hơn về việc tối ưu hóa tốc độ tải ảnh thì đọc bài này. Còn đường dẫn tiếp theo dành cho những ai muốn tìm hiểu sâu kỹ thuật lazy load ảnh và video.

Lazy load bộc lộ nhiều ưu thế trên máy bàn

Vì máy bàn có tốc độ kết nối internet cao, ổn định, và phần cứng xử lý dữ liệu của máy bàn cũng tốt hơn nên lazy load ảnh trên máy bàn hầu như không gặp vấn đề gì, thường thì chỉ có một chút giật cục, và nó có thể được khắc phục bằng một số biện pháp can thiệp tinh tế như làm blur để ảnh hiện dần trong tầm mắt người dùng. Trang web làm điều này rất xuất sắc là medium.com, với hiệu ứng ảnh xuất hiện rất mềm mại. Một cách khác nữa là tải trước ảnh khi nó cách khung nhìn một ngưỡng nào đó, chẳng hạn 1000px hoặc 2000px, plugin giúp bạn làm điều này là Flying Images (plugin này còn cung cấp CDN miễn phí có chất lượng khá tốt, rất hợp khi triển khai trên các sản phẩm, dịch vụ cần tiết kiệm chi phí).

Lazy load không chỉ làm trang tải nhanh hơn, nó còn giúp tiết kiệm băng thông đáng kể, khi mà nó không phải mất dung lượng cho nội dung mà người dùng không xem. Vấn đề giảm dung lượng khá quan trọng khi kết hợp với CDN, vì các dịch vụ CDN phần lớn tính chi phí theo dung lượng, với kiểu tính tiền dùng đến đâu trả đến đấy.

Tại sao thiết bị di động lại là vấn đề

Ngược lại máy bàn, kết nối của thiết bị di động thường không cao bằng, không ổn định bằng, cũng như nó có phần cứng yếu hơn trong việc xử lý dữ liệu (nếu bạn để ý điểm kiểm tra tốc độ trên di động lúc nào cũng thấp hơn trên máy bàn, công cụ có lẽ bạn quen thuộc là Google PageSpeed Insights). Chính vì những điều này, lazy load ảnh trên di động có thể gây ra một số phiền toái rất khó chịu như:

• Ảnh tải về rất chậm, người dùng lướt qua phần có ảnh mà đợi một hồi lâu mới thấy ảnh tải về được
• Trong trường hợp xấu nhất, ảnh thậm chí không tải về, tạo ra một khoảng trống rất vô duyên

Vì những lý do đó, nói chung bạn không nên sử dụng lazy load trên thiết bị di động.

Một số plugin tạo cache cho WordPress có khả năng bật/tắt lazy load trên thiết bị di động, chẳng hạn như WP-Rocket.

Giải pháp thay thế

Trì hoãn tải ảnh được xem là biện pháp tốt hơn lazy load.

Trong khi lazy load kiểu truyền thống là nước đến chân mới nhảy (ảnh trong tầm nhìn thì mới tải xuống), cơ chế trì hoãn tải ảnh lại khác, nó là cơ chế làm các việc quan trọng trước, còn các việc kém quan trọng để sau (nhưng sẽ làm ngay khi việc quan trọng làm xong chứ không “lười” như kiểu lazy load truyền thống).

Trì hoãn tải ảnh trước hết tải bất cứ ảnh nào trong màn hình đầu tiên nhưng trì hoãn các ảnh từ màn hình thứ hai trở đi, cho đến khi trang tải xong mới thôi. Khi bắt gặp thẻ đóng <body> trong <html> nó mới tải các ảnh còn lại.

Trì hoãn tải ảnh sẽ làm tốc độ tải trang về mặt nhận thức cao hơn, nhưng nó thường không tiết kiệm băng thông bằng lazy load, tuy nhiên băng thông lại không phải là vấn đề lớn trong đa số website (nhất là khi họ không sử dụng CDN), do vậy tôi khuyến khích các bạn dùng trì hoãn tải ảnh thay thế lazy load.

Vấn đề kỹ thuật

Dù rằng trì hoãn tải ảnh rất dễ thực hiện, nhưng như tôi biết, hiện vẫn chưa có plugin nào hỗ trợ cho nó, trong khi các plugin dành cho lazy load ảnh thì có rất nhiều (thí dụ a3 lazy load). Giờ những người muốn trì hoãn tải ảnh vẫn phải làm việc này một cách thủ công, điều chắc chắn sẽ thành vấn đề nếu họ có số lượng bài viết lớn trên website.

Bonus: Vẫn có khả năng lazy load ảnh trên di động nếu được thực hiện khéo léo

Lazy load ảnh trên di động có nhiều rủi ro như vậy, nhưng nó vẫn có khả năng triển khai được nếu bạn thiết lập các giới hạn hợp lý:

• Chỉ lazy load ảnh trên di động nếu trang của bạn cũng tích hợp CDN có máy chủ tại vị trí truy cập của người dùng, điều này tránh rủi ro độ trễ cao. Ở Việt Nam bạn có thể tham khảo dịch vụ của CDNSun. Ngoài ra CDN còn có ưu thể bổ sung rất đáng giá là một số dịch vụ còn đính kèm theo đó nhiều tối ưu hóa khác như định dạng, kích cỡ, vân vân
• Chỉ lazy load các ảnh không quan trọng hoặc/và các ảnh ở sâu bên dưới nội dung. Các ví dụ cho các ảnh như vậy có thể là các ảnh đại diện ở mục bài liên quan, ảnh nặng nằm từ giữa bài viết đến cuối bài, các banner ảnh ở bên cột phải dùng để quảng cáo dịch vụ của bạn (trên di động, nó sẽ trôi về cuối)

Lý tưởng nhất, triển khai lazy load ảnh nên kết hợp với khả năng nhận biết được tốc độ kết nối của người dùng để đưa ra phiên bản tối ưu nhất. Nhưng vấn đề là triển khai chuyện này không dễ dàng gì. Bạn có thể tham khảo bài viết tải thích ứng (adaptive loading) để biết thêm chi tiết.

The post Không nên sử dụng Lazy load ảnh trên thiết bị di động appeared first on Unest.

1. Yêu cầu được thực hiện khi ai đó click vào một liên kết
2. Trang và các tài nguyên (file) của nó được tải về
3. Trình duyệt sử dụng các tài nguyên của trang để xây dựng trang
4. Trang sau đó được hiển thị (render) cho người dùng

Mỗi cái trong từng bước trên có nhiều thành phần và chi tiết, nhưng bốn bước đó là những yếu tố chính diễn ra để hiển thị trang web cho người dùng.

Bài viết này sẽ thảo luận từng cái trong mỗi bước trên để đưa ra được cái nhìn tổng quan về điều gì đã thực sự xảy ra khi một trang web hiển thị trên trình duyệt.

Về mặt kỹ thuật

Bốn bước liệt kê ở trên thường được đề cập về mặt kỹ thuật dưới những thuật ngữ như:

1. Yêu cầu (Request)
2. Đáp ứng (Response)
3. Xây dựng (Build)
4. Xuất trang/Hiển thị (Render)

Mỗi bước này thường được thực hiện lặp lại nhiều lần trong khi tải trang.

Yêu cầu/Request

Trước khi chúng ta đi vào việc chuyện gì xảy ra khi một trang web nhận được yêu cầu, hãy xem điều gì ngay lúc ban đầu đã tạo ra yêu cầu đến một trang.

Cách thức phổ biến nhất để một trang web nhận được yêu cầu là khi một liên kết được ai đó click (link is clicked), nhưng yêu cầu cũng xuất hiện khi một trang được làm mới lại (F5/refreshed), hoặc khi một URL được nhập vào trong trình duyệt (navigation bar is used).

Thời điểm khi một trang web được yêu cầu còn được gọi là “bắt đầu điều hướng/navigation start”.

Về cơ bản đây là thời điểm khi mà toàn bộ quá trình hiển thị trang bắt đầu.

Tài liệu

Khi một liên kết được click, một yêu cầu tài liệu được thực hiện.

Tài liệu là file trang web, cái chỉ đơn giản là file dạng text. Nó được đặt trên một máy chủ web (web hosting).

File này thường có dạng “.html”, nhưng định dạng của file thực sự không phải là vấn đề. Điều quan trọng là một file dạng text được yêu cầu bởi trình duyệt web.

File nhận được yêu cầu sử dụng hệ thống gọi là HTTP.

Ở thời điểm này chúng ta không cần phải hiểu HTTP là gì vội, chúng ta chỉ cần biết rằng một trình duyệt web đã yêu cầu một tệp (file) từ máy chủ web.

Đáp ứng/Response

Máy chủ web sau đó gửi file cho trình duyệt web.

Đáp ứng được hiểu đơn giản là trình duyệt nhận được những gì mà nó đã yêu cầu.

Nếu đây là một trang web đơn giản (chỉ có HTML) thì giai đoạn yêu cầu và đáp ứng của việc tải trang sẽ hoàn thành.

Dù vậy, hầu hết các trang web có những thành phần như là hình ảnh, CSS và JS.

Chúng được gọi là các tài nguyên (resources) và để hiển thị được trang web, trình duyệt web cũng phải nhận được các tài nguyên của trang.

Phân tích cú pháp

Vậy làm thế nào một trình duyệt web biết được rằng một trang có cần bổ sung các tài nguyên hay không?

Một khi trình duyệt nhận được tài liệu (tệp HTML), nó đọc tài liệu đó.

Khi một máy tính đọc một file đang tìm kiếm điều gì đó, điều này được gọi là  “parsing/phân tích cú pháp”

Trình duyệt web nhìn vào toàn bộ tài liệu HTML và tìm kiếm bất kỳ tài nguyên CSS, JS và hình ảnh nào được tham chiếu (referenced) trong trang.

Nếu các tài nguyên được phát hiện thấy trong HTML thì sau đó trình duyệt web sẽ yêu cầu từng tài nguyên này từ máy chủ web.

Các ảnh, CSS, và JS mà tài liệu HTML liên kết sẽ được tải xuống bởi trình duyệt.

Cách nó lựa chọn tải xuống các tài nguyên này và thứ tự tài nguyên được tải xuống hơi phức tạp một chút và sẽ được chúng tôi giải thích trong bài viết khác. Nếu bạn tò mò, hãy tham khảo bài viết về tuyến hiển thị quan trọng (critical rendering path).

Xây dựng trang/Build

Một khi trình duyệt web có được các tài nguyên cần thiết, nó có thể bắt đầu tiến hành xây dựng trang.

Cách một trình duyệt web xây dựng trang là thông qua kết hợp thông tin tìm thấy trong tài liệu (file HTML gốc) và thông tin được tìm thấy trong các tài nguyên.

Có ba bước cơ bản mà trình duyệt thực hiện để xây dựng trang.

• Xây dựng DOM
• Xây dựng CSSOM
• Xây dựng Cây Hiển Thị (Render Tree)

Xây dựng DOM

DOM là viết tắt của “Document Object Map/Bản đồ Đối tượng Tài liệu”. Nó về cơ bản là một bản đồ nơi mọi thứ được hiển thị trên trang theo dạng thức HTML. DOM đại diện cho điều HTML đang nói bằng cách ánh xạ trang theo cách quan hệ (relational manner).

Xây dựng CSSOM

CSSOM là viết tắt của cụm từ “CSS Object Map/Bản đồ Đối tượng CSS”. Nó về cơ bản là một bản đồ của các style/định dạng cụ thể nào phải được áp dụng vào các phần khác nhau của trang web theo dạng thức CSS. Bản đồ CSSOM vạch ra cách thức mọi thứ nên được hiển thị bằng cách sử dụng style.

Xây dựng cây hiển thị (render tree)

Cây hiển thị về cơ bản đưa DOM và CSSOM kết hợp lại với nhau để tạo ra bản đồ đầy đủ về cách trang sẽ thực sự được bố cục và định dạng.

Render/Hiển thị

Sau khi tất cả các bước trên được thực hiện, cuối cùng cũng đến lúc trình duyệt có thể đưa ra điều gì đó lên màn hình rồi.

Có hai điều chính xảy ra ở đây…

• Bố cục/Layout
• Định dạng hoàn chỉnh/Paint

Bố cục

Trình duyệt ở thời điểm này đã biết cái gì cần phải hiển thị (DOM) và cách thức để hiển thị nó thế nào (CSSOM) và mối quan hệ giữa hai thứ này (cây hiển thị).

Cái mà nó không biết là kích cỡ để hiển thị mọi thứ và vị trí của những thứ này sẽ kết thúc tại đâu trên màn hình.

Một ví dụ của câu chuyện này có thể là vị trí của thẻ div được gọi là “sidebar/cột” với giả định 25% chiều rộng màn hình nằm ở phía tay phải.

Hừm, 25% của cái gì đây?

Phần này được gọi là bố cục (layout), và nó là vấn đề cơ bản nơi mà trình duyệt xác định mức độ lớn của màn hình là bao nhiêu và làm thế nào điều đó ảnh hưởng đến cách hiển thị trang.

Định dạng

Giờ tất cả tính toán đã thực hiện xong, trình duyệt có thể thực sự hiển thị điều gì đó trên màn hình.

Điều này được gọi là định dạng hoàn chỉnh (paint).

Trong bước cuối cùng này trình duyệt sẽ chuyển đổi mỗi điểm nút trong cây render thành các pixel thực sự trên màn hình của người duyệt web.

Đặt mọi thứ lại với nhau

Chúng ta đã chia tách quá trình hiển thị một trang web thành bốn phần…

• Yêu cầu
• Phản hồi
• Xây dựng
• Hiển thị

Trong bài viết kế tiếp, chúng ta sẽ xem xét từng bước này chi tiết hơn.

(Dịch từ bài viết How a webpage is loaded and displayed – Tác giả: Patrick Sexton – Website: Varvy)

The post Cách trình duyệt tải trang web về và hiển thị cho người dùng appeared first on Unest.