Computer >> Hướng Dẫn Máy Tính >  >> Kết Nối Mạng >> Internet

Google Core Web Vitals: Điều hướng nghịch lý tốc độ trang cho thành công SEO

Gần đây, tôi đọc một đống bài viết nhắc đến thay đổi cách Google dự định điều chỉnh xếp hạng trang trong Google Search từ năm sau. Hôm nay, công thức kết hợp một số yếu tố tương tác người dùng, gọi là Core Web Vitals, sắp được cộng với hiệu suất trang. Tôi nghĩ, đây là ý tưởng tồi.

Cảm giác đầu tiên của bạn sẽ là - yo, old dinosaur (khủng long già) - và của tôi cũng vậy, nên tôi quyết định thực sự kiểm tra xem có gì. Google có một số dịch vụ, như Google Search Console (Webmaster Tools mới), PageSpeed Insights, và vài cái khác, có thể giúp bạn kiểm tra hiệu suất trang web. Vậy tôi làm kiểm tra Dedoimedo, và viết bài này. Tóm lại.

Tại sao tốc độ trang vô nghĩa

Tôi đã viết về điều này nhiều năm trước, trước cả cơn sốt mobile, và lập luận vẫn đứng vững. Nhưng hơn thế nữa, tốc độ trang không phải chỉ báo trải nghiệm người dùng theo bất kỳ cách nào. Nó, tốt nhất, là chỉ báo của ngăn xếp phần mềm phục vụ trang. Nó cũng là chỉ báo của technical wealth (giàu có kỹ thuật), tôi sẽ giải thích trau chuốt.

Đầu tiên, một chút toán học đơn giản, bỏ qua Core Web Vitals. Trang với 100 dòng văn bản và 10 hình ảnh nhỏ/ngắn hơn trang với 1.000 dòng văn bản và 100 hình ảnh. Không có tham số khác, trang với nhiều dữ liệu hơn nên mất nhiều thời gian tải hơn. Điều này cho chúng ta biết gì về nội dung? Không.

Vì vậy, loại trừ mọi tham số khác, ít nội dung = tốc độ cao. Ngẫu nhiên - hoặc không - điều này phù hợp tốt với mẫu dumbification (ngu dốt hóa) của Web hiện đại, đã trở thành lực lượng thống trị khoảng 2014, đại khái cùng lúc Internet di động (smartphone tóm gọn) trở nên phổ biến.

Điều này chuyển hóa thành thời gian chú ý ngắn và tiêu dùng rẻ tiền. Viết nội dung trong càng ít ký tự càng tốt thay vì cố gắng 전달 thông điệp chính xác và hữu ích nhất có thể. Video và hình ảnh thay vì văn bản. Tất nhiên, đây chính xác những gì bạn cần để giữ đám đông low-IQ được giải trí, vì họ không thể bị phiền với chủ đề dài, phức tạp. Sau tất cả, người ngốc tốt cho kinh doanh. Họ dễ chi tiền cho thứ vớ vẩn, dễ bị ép buộc hoặc lôi kéo vào xu hướng, dễ kiểm soát. Xin chào, lợi nhuận!

Thứ hai, tải trang không cho chúng ta biết bản chất của trang. Trang bạn cần điền form hoàn toàn khác trang tóm tắt lịch sử chinh phục Norman. Với cái trước, responsiveness (phản hồi) trái ngược với tốc độ thuần túy có thể quan trọng. Với cái sau, đây là giá trị vô nghĩa. Bây giờ, đây không phải chủ đề tầm thường. Có khoa học sâu sắc, phức tạp đằng sau, và ngay cả tôi đã làm nghiên cứu nghiêm túc về chủ đề này, và trình bày công việc tại các hội nghị trong quá khứ, nhưng hãy để đó qua một bên.

Ví dụ thực tế: bất kỳ review Linux điển hình nào tôi xuất bản ở đây. Chúng khá dài, thường có khoảng 40K ký tự văn bản (khoảng 2.500-3.000 từ), và chứa khoảng 30-40 hình ảnh trên một trang. Nội dung này mất thời gian tải - không nhiều nhưng có.

Tuy nhiên ... bài viết luôn bắt đầu bằng hai đoạn văn, có thể mất 15-20 giây để đọc, nếu không lâu hơn. Khi người dùng đọc xong, tất cả asset đã tải chục lần. Tốc độ có tác động zero đến trải nghiệm người dùng.

Nhưng ... nếu bạn nhìn trang từ góc "SEO", thì nó "quá dài" cho các chuyên gia giả. Không đi vào chi tiết hoặc trao spotlight cho phần mềm và ý tưởng tôi ghét, tôi đã thấy các công cụ "SEO" khuyên bài viết không dài hơn 500-600 từ hoặc tương tự. Riêng nó, đây là con số vô nghĩa, nhưng rồi, đây là điều xảy ra khi bạn cố gắng đặt pseudo-science (khoa học giả) quanh thứ máy móc không thực sự định lượng được.

Và đó là chất lượng (quality).

Một điều không bao giờ được nhắc trong bất kỳ thứ "SEO" nào là chất lượng. Thực tế, đây là thứ không máy móc nào bao giờ có thể kiểm tra. Chất lượng giống như niềm tin - mất thời gian tìm, xây dựng, nuôi dưỡng. Chất lượng cũng có hàm số thời gian dài - bạn không nhất quyết quyết định thứ gì là "nội dung chất lượng" chỉ bằng cách đọc một hai câu blog (tốt, bạn có thể, nếu bạn proper skilled trong domain). Thông thường, bạn cần nhiều trải nghiệm lặp lại để xác định mức độ nhất quán và độ chính xác trong vật liệu xuất bản.

Quay lại tốc độ. Hãy chơi theo. Nếu bạn muốn trang tải nhanh nhất có thể, bạn muốn nội dung ngắn nhất có thể, có nghĩa là cắt giảm chất lượng. Sau đó, bạn có thể tách nội dung thành nhiều trang, nhưng rồi bạn buộc người đọc click số hoặc mũi tên liên tục. Tôi không chắc cảm xúc chung như thế nào, nhưng tôi thấy điều này khá nhàm chán, và cố gắng tránh nó tối đa (chỉ với vài ngoại lệ nhỏ).

Thực tế, khái niệm web pages (nhiều trang phục vụ "trang" của cùng nội dung) là kết quả của cuộc đua vô nghĩa theo tốc độ, nơi tốc độ không cần thiết. Vì nếu nói về hình ảnh, gallery (thư viện ảnh) theo định nghĩa là tập hợp frame (khung) độc lập (thường độc lập). Nếu là văn bản, chúng ta nói về nội dung dài, có thể justified (có lý do), nghĩa là những người định đọc nó thực sự có kiên nhẫn cho toàn bộ từ đầu. Do đó, cân nhắc tốc độ thực sự là điều Catch-22 (vòng luẩn quẩn) ở đây.

Được, hãy chấm điểm một số trang

Nhưng như tôi nói ở đầu - chúng ta cần số thực tế. Vì vậy tôi làm một số test tốc độ cho dedoimedo.com, và cho bạn thấy kết quả. Lưu ý bạn thực sự nhận được hai bộ kết quả riêng biệt - cách trang hiển thị trên desktop, và cách hiển thị trên điện thoại (mobile). Điểm từ 0-100, và tất nhiên, càng cao càng tốt.

Google Core Web Vitals: Điều hướng nghịch lý tốc độ trang cho thành công SEO

Google Core Web Vitals: Điều hướng nghịch lý tốc độ trang cho thành công SEO

Nhìn dữ liệu, hiệu suất desktop tốt, mobile - không bằng. CHÍNH XÁC CÙNG NỘI DUNG. Sự khác biệt giữa hai khá nhỏ. Từ những gì tôi thấy, chỉ có 200 ms chênh lệch trong tham số FCP.

Bây giờ, Lab Data cho thêm - và ở đây chúng ta có thêm thông tin. Nhưng lại, không lấy bối cảnh BẢN CHẤT của trang, con số không có ý nghĩa nhiều. Ví dụ, Time to Interactive, không có tương tác thực sự trên trang tôi - văn bản và hình ảnh. Đọc, nhìn. Một phần của thời gian này - nhanh bao nhiêu nội dung trang hiển thị nhìn thấy được, được chỉ ra bởi Speed Index. Điều này quay lại lập luận của tôi về việc tốc độ vô nghĩa. Trang index trên Dedoimedo, ví dụ, hiển thị tiêu đề tin tức cho nội dung xuất bản vài tháng qua. Rõ ràng, nếu ít hơn, nó sẽ tải nhanh hơn. Nhưng đó không phải là điểm.

Google Core Web Vitals: Điều hướng nghịch lý tốc độ trang cho thành công SEO

Con số có thể trông báo động, nhưng tin tôi đi, Dedoimedo đạt điểm cao hơn hầu hết trang web khác. Thử, gõ một số xuất bản công nghệ phổ biến, và xem yourself.

Để hiểu thêm, tôi quyết định mở rộng kết quả, và nhìn các opportunities (cơ hội) và diagnostics (chẩn đoán) khác nhau trong báo cáo - về cơ bản là khuyến nghị mà thuật toán đằng sau báo cáo đề xuất. Lưu ý rằng những thứ này không ảnh hưởng điểm - nhưng tự nói lên sự thật.

Diagnostics wise - dường như một số third-party code chặn tải main thread (của cái gì) khoảng 1 giây. Phân tích cho thấy thủ phạm chính thực sự là code Google Ads tôi dùng trên các trang. Tương tự, document.write() được gắn cờ là vấn đề khác cho kết nối chậm, và lại, điều này thuộc code third-party.

Google Core Web Vitals: Điều hướng nghịch lý tốc độ trang cho thành công SEO

Google Core Web Vitals: Điều hướng nghịch lý tốc độ trang cho thành công SEO

Opportunities - một số thứ thú vị. Hình ảnh. Đề xuất dùng định dạng "next-gen" thay vì JPG và PNG cũ. Giả định sẽ tiết kiệm khoảng 2.7 giây tải, nhưng 2.7 giây ít hơn thời gian đọc một dòng văn bản trên bất kỳ trang nào trang web tôi. Thực tế, nó không tạo khác biệt. Nhưng điều này quay lại việc tôi dùng tập hợp hình ảnh lớn trong bài viết. Đó chính là thứ giúp người dùng có giá trị tốt nhất từ hướng dẫn và tutorial của tôi. Hình ảnh bản thân có thể vô dụng.

Google Core Web Vitals: Điều hướng nghịch lý tốc độ trang cho thành công SEO

Điều tôi thấy tò mò lại - unused JavaScript - tất cả đều nội dung third-party liên quan đến Google stuff tôi dùng trên Dedoimedo. Bây giờ, tôi tự hào về sự chính xác và meticulous (tỉ mỉ). Tôi luôn cố gắng implement giải pháp tốt nhất để người dùng - người đọc, những người quan trọng - có trải nghiệm tốt nhất.

Đây là một trong những lý do Dedoimedo có ZERO JavaScript organic - và lý do nó nên nhanh. Không cookie, không comment, không gì. Chỉ third-party code là một số analytics cơ bản, search, một vài quảng cáo để kiếm vài bạc, và cookie overlay applet, bắt buộc bởi GDPR và CCPA. Nhưng nhìn kết quả trên, điều tốt nhất tôi có thể làm là bỏ hẳn script third-party.

Bây giờ, tôi không phát minh code cho bất kỳ cái nào trên. Tôi dùng code quảng cáo đúng như Google quy định. Tôi dùng code cookie applet đúng như Civic quy định. Nếu có cơ hội cải thiện tải, như async function v.v., thì tôi vô lực implement. Tôi không có kiểm soát over cách công ty third-party tạo code. Kiểm soát duy nhất của tôi là chọn dùng chúng - và có lẽ lựa chọn đó cũng cần xem lại.

Sau đó, kết quả cũng dường như khác khá nhiều từ test này sang test khác. Đây là kết quả mobile từ chỉ vài ngày sau cái đầu tiên được thu thập - tôi không phiền, nhưng rồi, làm sao tôi lấy kết quả này vào tài khoản, nếu chúng thay đổi nhiều như vậy mà không có input từ phía tôi?

Google Core Web Vitals: Điều hướng nghịch lý tốc độ trang cho thành công SEO

Con số dường như trái ngược với báo cáo Google Search Console - tất cả trang báo cáo Good page performance - nhưng Field Data text report dường như đồng ý. Note bên lề, trong tất cả trang indexed, chỉ hai có mobile usability issues, và cả hai dường như false positives (dương tính giả), vì live test báo all green (cả hai thực sự render đúng trên điện thoại). Ví dụ, một trong hai trang bị gắn cờ, hướng dẫn exploit Windows 10:

Google Core Web Vitals: Điều hướng nghịch lý tốc độ trang cho thành công SEO

Google Core Web Vitals: Điều hướng nghịch lý tốc độ trang cho thành công SEO

Google Core Web Vitals: Điều hướng nghịch lý tốc độ trang cho thành công SEO

Nói về friendly, font xám nhạt trên nền xám không thực sự friendly. Xa từ đó.

Kết luận

Và bạn có nó, phát hiện của tôi. Con số không nói lên nhiều riêng lẻ - không có context (bối cảnh), bạn không thực sự biết gì. Con số khác đáng kể giữa desktop và mobile, và con số khác nhau từ sample này sang sample khác. Con số không đồng ý với bộ công cụ khác cung cấp chức năng tương tự. Con số dường như bị ảnh hưởng chủ yếu bởi script third-party, hầu hết do Google tạo. Một số dữ liệu cũng bao gồm false positives.

Đây là test ngắn, đơn giản - và nó cho thấy nhiều variation (biến động) và ambiguity (mơ hồ) về cách performance/speed được hiểu. Lại một lần, chúng ta không biết gì về nội dung đằng sau con số, không biết gì về chất lượng thực tế. Một trang có thể có điểm hoàn hảo, nhưng rồi hầu hết Internet hiện đại là cái hố nhục. Đó là thứ cần giải quyết trước. Nhưng hey, tôi chỉ là một đầu bếp thấp hèn.

Tôi không chắc ai quan tâm đến những gì tôi viết ở đây - 'tis one man's opinion (chỉ ý kiến một người). Nhưng tôi tin rằng thêm tốc độ vào công thức chỉ làm mọi thứ tệ hơn. Điều đã tệ với người đuổi theo "SEO" unicorn (kỳ lân) huyền thoại. Tốc độ chỉ dẫn đến nội dung "nhanh" càng pha loãng hơn, càng nhiều fluff (rác) không substance (chất lượng) được thiết kế để làm hài lòng máy móc. Gợi ý: Tôi chưa BAO GIỜ thử bất kỳ khuyến nghị "SEO" nào, và độ phổ biến trang web tôi đã tăng, giảm, tăng lại (với zero intervention từ tôi), giảm và tăng theo nhịp các cân nhắc tài chính hoàn toàn ngoài tầm kiểm soát của tôi. Thay vào đó, tôi tập trung vào chất lượng và vui vẻ. Nhưng tôi cũng biết tôi là giống techies old school đang chết dần, và tương lai thuộc về những idiot touch-happy (vui vẻ chạm màn hình). Điều đó ổn, vì đó là tương lai của họ. Tôi sẽ chào họ từ một kỳ nghỉ 퇴廢 (hoang phí) trên hòn đảo nắng đẹp đâu đó, tận hưởng cổ tức từ công ty kiếm lợi nhuận khổng lồ từ đám đông low-IQ.

Chúc vui.