Tìm hiểu Độ trễ đầu vào đầu tiên (FID) là gì, nguyên nhân gây ra nó và các giải pháp khác nhau để cải thiện các chỉ số Core Web Vitals này.
Độ trễ nhập liệu đầu tiên (FID) là chỉ số trải nghiệm người dùng mà Google sử dụng như một yếu tố xếp hạng nhỏ.
Bài viết này cung cấp một cái nhìn tổng quan dễ hiểu về FID để giúp hiểu chủ đề.
Đầu vào chậm trễ hơn là cố gắng làm hài lòng Google. Các cải tiến đối với hiệu suất trang web thường dẫn đến tăng doanh số bán hàng, doanh thu quảng cáo và khách hàng tiềm năng.
Độ trễ đầu vào đầu tiên là gì?
FID là phép đo thời gian cần thiết để trình duyệt phản hồi lại tương tác đầu tiên của khách truy cập với trang web trong khi trang web đang tải. Điều này đôi khi được gọi là Độ trễ đầu vào.
Một tương tác có thể là nhấn vào một nút, một liên kết hoặc một lần nhấn phím và phản hồi sau đó. Các khu vực nhập văn bản, danh sách thả xuống và hộp kiểm là các loại điểm tương tác khác mà FID sẽ đo lường.
Thao tác cuộn hoặc thu phóng không được tính là tương tác vì không có phản hồi nào được mong đợi từ chính trang web.
Mục tiêu của FID là đo lường mức độ phản hồi của một trang web trong khi tải.
Nguyên nhân của sự chậm trễ đầu vào đầu tiên
Độ trễ đầu vào đầu tiên thường do hình ảnh và tập lệnh tải xuống không theo thứ tự.
Việc mã hóa bị rối loạn này khiến quá trình tải xuống trang web tạm dừng quá mức, sau đó bắt đầu, rồi tạm dừng. Điều này gây ra hành vi không phản hồi cho khách truy cập trang web đang cố gắng tương tác với trang web.
Nó giống như một vụ tắc đường gây ra bởi tất cả những nơi không có tín hiệu giao thông. Khắc phục nó là mang lại trật tự cho giao thông.
Google mô tả nguyên nhân của độ trễ đầu vào như sau:
“Nói chung, độ trễ đầu vào (còn gọi là độ trễ đầu vào) xảy ra do luồng chính của trình duyệt đang bận làm việc khác, vì vậy nó không thể (chưa) phản hồi với người dùng.
Một lý do phổ biến mà điều này có thể xảy ra là trình duyệt đang bận phân tích cú pháp và thực thi một tệp JavaScript lớn được tải bởi ứng dụng của bạn.
Trong khi nó đang làm điều đó, nó không thể chạy bất kỳ trình xử lý sự kiện nào vì JavaScript mà nó đang tải có thể yêu cầu nó làm điều gì đó khác. ”
Cách khắc phục độ trễ đầu vào
Vì nguyên nhân gốc rễ của Sự chậm trễ đầu vào là do quá trình tải xuống tập lệnh và hình ảnh một cách vô tổ chức, nên cách khắc phục sự cố là cân nhắc kỹ lưỡng cách các tập lệnh và hình ảnh đó được hiển thị cho trình duyệt để tải xuống.
Giải quyết vấn đề của FID thường bao gồm việc sử dụng các thuộc tính HTML để kiểm soát cách tải tập lệnh xuống, tối ưu hóa hình ảnh (HTML và hình ảnh) và cẩn thận loại bỏ các tập lệnh không cần thiết.
Mục tiêu là tối ưu hóa những gì được tải xuống để loại bỏ việc tạm dừng và bắt đầu tải xuống điển hình của các trang web không được tổ chức.
Tại sao trình duyệt trở nên không phản hồi
Trình duyệt là phần mềm hoàn thành các tác vụ để hiển thị một trang web. Các tác vụ bao gồm tải xuống mã, hình ảnh, phông chữ, thông tin kiểu và tập lệnh, sau đó chạy (thực thi) các tập lệnh và xây dựng trang web theo các hướng dẫn HTML.
Quá trình này được gọi là kết xuất. Từ kết xuất có nghĩa là “tạo ra” và đó là những gì trình duyệt thực hiện bằng cách tập hợp mã và hình ảnh để hiển thị một trang web.
Các tác vụ kết xuất riêng lẻ được gọi là luồng, viết tắt của “luồng thực thi”. Điều này có nghĩa là một chuỗi hành động riêng lẻ (trong trường hợp này là nhiều tác vụ riêng lẻ được thực hiện để hiển thị một trang web).
Trong trình duyệt, có một luồng được gọi là Chủ đề chính và nó chịu trách nhiệm tạo (hiển thị) trang web mà khách truy cập trang web nhìn thấy.
Chuỗi chính có thể được hình dung như một đường cao tốc trong đó xe ô tô là biểu tượng của hình ảnh và tập lệnh đang tải xuống và thực thi khi một người truy cập trang web.
Một số mã lớn và chậm. Điều này khiến các tác vụ khác dừng lại và chờ mã lớn và chậm ra khỏi đường cao tốc (tải xong và thực thi).
Mục đích là viết mã trang web theo cách tối ưu hóa mã nào được tải xuống đầu tiên và khi mã được thực thi, theo cách có thứ tự, để trang web tải xuống theo cách nhanh nhất có thể.
Đừng mất ngủ vì mã của bên thứ ba
Khi nói đến Core Web Vitals và đặc biệt là với Độ trễ nhập liệu đầu tiên, bạn sẽ thấy có một số đoạn mã mà bạn không thể làm được nhiều. Tuy nhiên, điều này cũng có thể xảy ra đối với các đối thủ cạnh tranh của bạn.
Ví dụ: nếu doanh nghiệp của bạn phụ thuộc vào Google AdSense (một tập lệnh chặn hiển thị lớn), thì vấn đề sẽ tương tự đối với đối thủ cạnh tranh của bạn. Các giải pháp như tải chậm bằng Google Ad Manager có thể hữu ích.
Trong một số trường hợp, chỉ cần làm tốt nhất có thể là đủ vì đối thủ cạnh tranh của bạn cũng có thể không làm tốt hơn.
Trong những trường hợp đó, tốt nhất bạn nên giành chiến thắng ở những nơi bạn có thể tìm thấy chúng. Đừng đổ mồ hôi trước những mất mát mà bạn không thể thay đổi.
Tác động của JavaScript đối với độ trễ đầu vào đầu tiên
JavaScript giống như một công cụ nhỏ tạo ra mọi thứ. Khi tên được nhập vào biểu mẫu, JavaScript có thể ở đó để đảm bảo cả họ và tên đều được nhập.
Khi một nút được nhấn, JavaScript có thể ở đó để yêu cầu trình duyệt gửi thông báo cảm ơn trong cửa sổ bật lên.
Vấn đề với JavaScript là nó không chỉ phải tải xuống mà còn phải chạy (thực thi). Vì vậy, đó là hai điều góp phần vào độ trễ đầu vào.
Nếu một tệp JavaScript lớn nằm gần đầu trang, tệp đó sẽ chặn phần còn lại của trang bên dưới nó hiển thị (trở nên hiển thị và tương tác) cho đến khi tập lệnh đó được tải xuống và thực thi xong.
Điều này được gọi là chặn trang.
Giải pháp rõ ràng là di dời các loại tập lệnh này từ đầu trang và đặt chúng ở cuối trang để chúng không ảnh hưởng đến tất cả các phần tử trang khác đang chờ hiển thị.
Nhưng đây có thể là một vấn đề nếu, ví dụ, nó được đặt ở cuối một trang web rất dài.
Điều này là do một khi trang lớn được tải và người dùng đã sẵn sàng tương tác với nó, trình duyệt sẽ vẫn báo hiệu rằng nó đang tải xuống (vì tệp JavaScript lớn đang bị trễ ở cuối). Trang có thể tải xuống nhanh hơn nhưng sau đó bị đình trệ trong khi chờ JavaScript thực thi.
Thuộc tính Trì hoãn và Không đồng bộ
Các thuộc tính Defer và Async HTML giống như các tín hiệu lưu lượng kiểm soát việc bắt đầu và dừng cách JavaScript tải xuống và thực thi.
Thuộc tính HTML là thứ biến đổi một phần tử HTML, giống như mở rộng mục đích hoặc hành vi của phần tử.
Nó giống như khi bạn học một kỹ năng; kỹ năng đó trở thành một thuộc tính của bạn là ai.
Trong trường hợp này, các thuộc tính Defer và Async yêu cầu trình duyệt không chặn phân tích cú pháp HTML trong khi tải xuống. Các thuộc tính này yêu cầu trình duyệt giữ cho chuỗi chính tiếp tục trong khi JavaScript đang tải xuống.
Thuộc tính không đồng bộ
Các tệp JavaScript có thuộc tính Async sẽ tải xuống và sau đó thực thi ngay khi nó được tải xuống. Khi nó bắt đầu thực thi là thời điểm tệp JavaScript chặn luồng chính.
Thông thường, tệp sẽ chặn luồng chính khi nó bắt đầu tải xuống. Nhưng không phải với thuộc tính async (hoặc defer).
Đây được gọi là tải xuống không đồng bộ, trong đó nó tải xuống độc lập với luồng chính và song song với nó.
Thuộc tính async hữu ích cho các tệp JavaScript của bên thứ ba như quảng cáo và chia sẻ xã hội – các tệp mà thứ tự thực thi không quan trọng.
Trì hoãn thuộc tính
Các tệp JavaScript có thuộc tính “defer” cũng sẽ tải xuống không đồng bộ.
Nhưng tệp JavaScript hoãn lại sẽ không thực thi cho đến khi toàn bộ trang được tải xuống và hiển thị. Các tập lệnh hoãn lại cũng thực thi theo thứ tự mà chúng được đặt trên một trang web.
Các tập lệnh có thuộc tính trì hoãn rất hữu ích cho các tệp JavaScript phụ thuộc vào các phần tử trang đang được tải và thời điểm thực thi thứ tự của chúng.
Nói chung, hãy sử dụng thuộc tính defer cho các tập lệnh không cần thiết cho việc hiển thị trang.
Độ trễ đầu vào là khác nhau cho tất cả người dùng
Điều quan trọng cần lưu ý là điểm của Độ trễ đầu vào đầu tiên có thể thay đổi và không nhất quán. Điểm số khác nhau giữa các khách truy cập.
Sự khác biệt về điểm số này là không thể tránh khỏi vì điểm số phụ thuộc vào các tương tác cụ thể đối với cá nhân truy cập vào một trang web.
Một số khách truy cập có thể bị phân tâm và không tương tác cho đến khi tất cả nội dung được tải và sẵn sàng tương tác.
Đây là cách Google mô tả nó:
“Không phải tất cả người dùng sẽ tương tác với trang web của bạn mỗi khi họ truy cập. Và không phải tất cả các tương tác đều liên quan đến FID… ”
Ngoài ra, lần tương tác đầu tiên của một số người dùng sẽ vào thời điểm không tốt (khi chuỗi chính bận trong một khoảng thời gian dài) và các lần tương tác đầu tiên của một số người dùng sẽ vào thời điểm thuận lợi (khi chuỗi chính hoàn toàn không hoạt động).
Điều này có nghĩa là một số người dùng sẽ không có giá trị FID, một số người dùng sẽ có giá trị FID thấp và một số người dùng có thể sẽ có giá trị FID cao ”.
Tại sao hầu hết các trang web bị lỗi FID
Thật không may, nhiều hệ thống quản lý nội dung, chủ đề và plugin không được xây dựng để tuân thủ số liệu tương đối mới này.
Đây là lý do tại sao rất nhiều nhà xuất bản mất tinh thần khi phát hiện ra rằng trang web của họ không vượt qua bài kiểm tra Độ trễ đầu vào đầu tiên.
Nhưng điều đó đang thay đổi khi cộng đồng phát triển phần mềm web đáp ứng nhu cầu về các tiêu chuẩn mã hóa khác nhau từ cộng đồng xuất bản.
Và không phải do lỗi của các nhà phát triển phần mềm tạo ra hệ thống quản lý nội dung khi sản xuất các sản phẩm không phù hợp với các chỉ số này.
Ví dụ: WordPress đã giải quyết một thiếu sót trong trình chỉnh sửa trang web Gutenberg khiến nó đạt điểm kém hơn mức có thể.
Gutenberg là một cách trực quan để xây dựng các trang web bằng cách sử dụng giao diện hoặc phép ẩn dụ của các khối. Có một khối widget, một khối biểu mẫu liên hệ và một khối chân trang, v.v.
Vì vậy, quá trình tạo một trang web trực quan hơn và được thực hiện thông qua phép ẩn dụ về các khối xây dựng, nghĩa đen là xây dựng một trang với các khối khác nhau.
Có nhiều loại khối khác nhau trông và hoạt động theo những cách khác nhau. Mỗi khối riêng lẻ có một mã kiểu tương ứng (CSS), với phần lớn mã là cụ thể và duy nhất cho khối riêng lẻ đó.
Cách tiêu chuẩn để mã hóa các kiểu này là tạo một bảng định kiểu có chứa các kiểu riêng cho mỗi khối. Làm theo cách này rất hợp lý vì bạn có một vị trí trung tâm, nơi tồn tại tất cả các mã cụ thể cho các khối.
Kết quả là trên một trang có thể bao gồm (giả sử) hai mươi khối, WordPress sẽ tải các kiểu cho các khối đó cộng với tất cả các khối khác không được sử dụng.
Trước Core Web Vitals (CWV), đó được coi là cách chuẩn để đóng gói CSS.
Kể từ khi ra đời Core Web Vitals, thực tiễn đó được coi là mã phình to.
Điều này không có nghĩa là một chút chống lại các nhà phát triển WordPress. Họ đã làm một công việc tuyệt vời.
Đây chỉ là sự phản ánh về mức độ thay đổi nhanh chóng của các tiêu chuẩn có thể gặp phải nút thắt cổ chai ở giai đoạn phát triển phần mềm trước khi được tích hợp vào hệ sinh thái mã hóa.
Chúng tôi đã trải qua điều tương tự với quá trình chuyển đổi sang thiết kế web ưu tiên thiết bị di động.
Gutenberg 10.1 Cải thiện hiệu suất
WordPress Gutenberg 10.1 đã giới thiệu một cách cải tiến để tải các kiểu bằng cách chỉ tải các kiểu cần thiết và không tải các kiểu khối sẽ không được sử dụng.
Đây là một chiến thắng lớn cho WordPress, những nhà xuất bản dựa trên WordPress và tất nhiên, những người dùng truy cập các trang web được tạo bằng WordPress.
Thời gian để khắc phục sự chậm trễ đầu vào đầu tiên là bây giờ
Trong tương lai, chúng ta có thể mong đợi rằng ngày càng nhiều nhà phát triển phần mềm chịu trách nhiệm về CMS, chủ đề và plugin sẽ chuyển sang các phương pháp mã hóa thân thiện với Độ trễ đầu vào đầu tiên.
Nhưng cho đến khi điều đó xảy ra, nhà xuất bản phải thực hiện các bước để cải thiện Độ trễ đầu vào cho lần đầu tiên. Hiểu nó là bước đầu tiên.
