3 thay đổi về tốc độ trang trên thiết bị di động và cách nó tác động đến tìm kiếm

GIANG

1336

24-05-2019

Theo Bizfly Cloud chia sẻ google tung ra Mobile Speed Update vào tháng 7/2018. Bản cập nhật này chính thức này thể hiện tốc độ tải trang là một tín hiệu xếp hạng cho các tìm kiếm di động.

Nó cũng đánh dấu một sự thay đổi lớn trong cách tiếp cận của Google trong việc test tốc độ website, đồng thời nhấn mạnh tầm quan trọng của trải nghiệm người dùng di động.

1. Tốc độ tải trang là một danh mục SEO khác biệt

Thay đổi lớn đầu tiên mà chúng ta nhận thấy từ đầu năm 2018 là Google hiện coi tốc độ tải trang là một danh mục riêng biệt, tách biệt với kỹ thuật SEO.

Bạn có thể dễ dàng thấy sự thay đổi này bằng cách đánh giá một trang web thông qua công cụ PageSpeed Insights.

Vài tháng trước, việc gõ URL vào PageSpeed Insights sẽ hiển thị các tiêu chí kỹ thuật rõ ràng:

- Redirects

- Nén

- Tối ưu

…

PageSpeed Insights cung cấp số liệu thống kê cơ bản và danh sách kiểm tra các tối ưu hóa được đề xuất để cải thiện điểm số của website.

Bây giờ, PageSpeed Insights hiển thị hai loại riêng biệt.

- "Optimization" là cái tên mới được áp dụng cho điểm 100 quen thuộc.

- Tuy nhiên, Speed Speed sẽ mới lạ hơn và dễ gây nhầm lẫn, đặc biệt là nếu trang web nhận được điểm "good" optimization cùng lúc với điểm số "slow" speed.

Điểm số Speed sẽ là "fast," "average," hoặc "slow."

Mặc dù các trang web có điểm tối ưu hóa thấp thường sẽ có điểm số tốc độ thấp, nhưng điều này không phải lúc nào cũng song hành.

Đây là một vấn đề lớn bởi vì, mặc dù bạn có thể dễ dàng tối ưu hóa "optimization score" bằng cách cải thiện yếu tố trong checklist và tập trung vào SEO, nhưng lại rất khó để ảnh hưởng trực tiếp đến điểm số tốc độ của bạn.

Trên thực tế, nếu trang web bị xếp loại "slow" thì có thể vì nhiều lý do nằm ngoài tầm kiểm soát của bạn.

2. Google đo tốc độ tải trang bằng dữ liệu thực địa, không phải dữ liệu phòng thí nghiệm

Nếu bạn ưu tiên sử dụng các công cụ như Pingdom hoặc WebPageTest, thì bạn có thể chưa thấy rằng PageSpeed Insights hiện đo tốc độ trang dựa trên giá trị trung bình của First Contentful Paint (FCP) và DOM Content Loaded (DCL).

Các số liệu này đo lường quãng thời gian từ khi người dùng lần đầu tiên nhìn thấy website và thời gian để HTML được tải và phân tích cú pháp.

Nói cách khác, Google hiện sử dụng Real User Measurements (RUMs) để đo tốc độ trang. Các số liệu này được lấy trực tiếp từ Chrome User Experience Report (CrUX), được tổng hợp từ hàng triệu người dùng trong thế giới thực bằng trình duyệt Chrometruy cập trang web của bạn.

Do đó, bạn có thể nhận thấy sự khác biệt giữa kết quả kiểm tra tốc độ in-house và các phép đo test tốc độ website của Google.

Ví dụ: ngay cả khi các thử nghiệm test tốc độ website của bạn đang trong khoảng có thể chấp nhận (Google khuyến nghị <200ms), thì một người dùng nào đó truy cập website bằng điện thoại Android thế hệ cũ hoặc ở một quốc gia khác có 3G rất chậm sẽ có những trải nghiệm người dùng không mượt mà.

Nếu người dùng đó trải nghiệm 400ms RTT và tốc độ truyền 400 kpbs trên website của bạn, Google rõ ràng sẽ tính toán tốc độ tải chậm hơn nhiều so với tốc độ bạn tự đo.

Điều này dẫn đến một số câu hỏi hóc búa thú vị.

Ví dụ: các số liệu kiểm tra trong phòng thí nghiệm có thể báo cáo một trang web tương đối nhanh, trong khi Google sẽ coi đó là chậm.

Điều này có thể vẫn còn là một bí ẩn cho đến khi chúng ta đào sâu vào cơ sở dữ liệu CrUX và phát hiện ra rằng hầu hết các khách truy cập trang web có thể được đặt ở bất cứ đâu trên thế giới và họ thường sử dụng các kết nối chậm hơn.

Thông tin như thế này dẫn đến một vấn đề nan giải: làm thế nào để chúng ta tối ưu hóa tốc độ trang web khi mọi thứ đều dựa trên RUM?

Rõ ràng, bạn không thể đi khắp nơi để đảm bảo rằng tất cả khách truy cập đang sử dụng mạng LTE và điện thoại thông minh mới nhất.

Những gì bạn có thể làm là sử dụng CrUX để hiểu khách truy cập của bạn đến từ đâu trên thế giới và trải nghiệm người dùng trung bình trên trang web của mình.

Nếu bạn nhận thấy xu hướng (ví dụ: hầu hết khách truy cập của bạn đến từ Kentucky hoặc hầu hết khách truy cập của bạn sử dụng iPhone 5) thì bạn có thể cố gắng tối ưu hóa cụ thể cho đối tượng đó.

Để truy cập CrUX:

- Đăng nhập vào Google Cloud.

- Tạo một dự án CrUX mới.

- Chuyển BigQuery console và click 'Compose Query'.

- Chạy các truy vấn để giải quyết các thách thức cụ thể.

Ví dụ: nếu bạn muốn đánh giá RUM tốc độ trang web từ tháng 8 năm 2018, bạn sẽ thực hiện truy vấn sau:

SELECT

form_factor.name AS device,

fcp.start,

ROUND(SUM(fcp.density), 4) AS density

FROM

`chrome-ux-report.all.201808`,

UNNEST(first_contentful_paint.histogram.bin) AS fcp

WHERE

origin = 'http://example.com'

GROUP BY

device,

start

ORDER BY

device,

start

Sau đó, bạn có thể cắm dữ liệu kết quả vào các chương trình trực quan hóa như Tableau, Google Data Studio và Excel để tạo các biểu đồ trực quan về hiệu suất của trang web.

Bạn nên thêm CrUX vào kho SEO của mình và sử dụng nó để khám phá các số liệu chính của người dùng thực, như: Thiết bị và loại kết nối mà người dùng sử dụng, hiệu suất của trang web của bạn so với đối thủ cạnh tranh.

3. Điểm tối ưu hóa thậm chí còn quan trọng hơn

Trước khi Page Speed Update được triển khai, chúng tôi đã tò mò muốn xem hiệu ứng (nếu có) mà bản cập nhật tác động tới page ranking. Để kiểm tra điều này, chúng tôi đã phân tích 1 triệu URL mà chúng tôi đã nhận được trong 30 vị trí hàng đầu cho 33.500 truy vấn.

Kết quả là có rất ít mối tương quan giữa vị trí xếp hạng và số liệu FCP/DCL.

Tuy nhiên, có một mối tương quan mạnh mẽ (0,97) giữa các trang có Optimization Score trung bình và các vị trí của chúng trong SERPs.

Điểm tối ưu hóa trung bình của các vị trí 1 đến 30 trong tìm kiếm di động tăng 0,83 điểm, điều này cho thấy tối ưu hóa kỹ thuật là quan trọng hơn bao giờ hết.

Kết luận

Nếu bạn biết website có vấn đề với cả Speed Score và Optimization Score, thì bạn nên tập trung vào việc test tốc độ website và sau đó tối ưu tốc độ trang web xuống dưới 200ms và khắc phục các sự cố kỹ thuật trước tiên.

Theo Bizfly Cloud chia sẻ

>> Có thể bạn quan tâm: 10 cách cải thiện hiệu suất website tập trung vào front-end performance (P1)