Trong thế kỷ 21 với sự bùng nổ của internet và thương mại điện tử, việc sở hữu một website là một phần quan trọng của chiến lược kiếm tiền online. Tuy nhiên, một trang web tốt không chỉ đòi hỏi nội dung hấp dẫn mà còn yêu cầu tối ưu hóa tốc độ. Tốc độ trang web không chỉ ảnh hưởng đến trải nghiệm người dùng mà còn đóng vai trò quan trọng trong việc thu hút và giữ chân khách hàng.
Trong bài viết này, chúng ta sẽ khám phá cách tối ưu tốc độ căn bản cho trang web của bạn, giúp bạn tạo ra một trải nghiệm người dùng xuất sắc và nâng cao khả năng kiếm tiền online.
Hãy cùng chúng tôi đi vào chi tiết để biết cách biến trang web của bạn thành một công cụ mạnh mẽ trong việc kiếm tiền trực tuyến.
Ở phần này, chúng ta sẽ tìm hiểu rõ hơn về Google Pagespeed
Cách tối ưu hóa trang web dựa theo gợi ý của Google Pagespeed Insights
Trong danh sách các công cụ kiểm tra tốc độ trang web, tôi thực sự không ưa thích Google Pagespeed Insights (GPI) – một công cụ kiểm tra tốc độ trang web phổ biến nhất. Tôi đặt nó ở đầu danh sách vì nó thường là công cụ mà những người mới chưa rành về web thường tham khảo. Họ nghĩ rằng công cụ này quan trọng nhất vì nó được tạo ra bởi Google, một tên tuổi đứng đầu trong lĩnh vực tìm kiếm trên internet.
Nhưng thực tế là, có rất ít sự tương quan giữa việc đạt điểm cao trên công cụ này và việc xếp hạng cao trên Google. Không tin tôi? Hãy tự thử nghiệm… hãy tìm kiếm Google với một từ khóa bất kỳ và sau đó chạy kiểm tra Google Pagespeed Insights cho 10 kết quả hàng đầu.
Để tôi nói rõ hơn: TÔI KHÔNG BAO GIỜ sử dụng GPI! Nó không cung cấp cho tôi bất kỳ chi tiết hữu ích nào hoặc đề xuất cần xem xét. Và thậm chí cả thông tin mà nó cung cấp cũng hoàn toàn không hữu ích hoặc hoàn toàn sai lệch.
Bạn có thể thấy rằng GPI thậm chí còn không cho phép bạn chọn vị trí máy chủ để kiểm tra, điều này có nghĩa là nó thậm chí còn không đo thời gian một cách cụ thể. Nó chỉ đoán mò về cách trang web của bạn tải và mất bao lâu. Hãy để tôi nói thêm một lần nữa… GPI hoàn toàn vô ích, hoặc ở mức tốt nhất là rối rắm và đánh lừa ở mức tồi nhất. Đừng quan tâm đến nó!!!
First Contentful Paint
Nó không chính xác! Hãy bỏ qua và sử dụng thử nghiệm mắt của bạn.
Lý thuyết: First Contentful Paint xuất hiện sau khoảng 500ms là tốt, sau khoảng 1 giây là tạm ổn, và lâu hơn thì cần được tối ưu hóa.
Vấn đề với GPI là nó thường nói quá về thời gian FCP của bạn, ví dụ, nó nói thời gian là 5 giây, trong khi thực tế nó chỉ mất 1 đến 2 giây khi bạn duyệt web.
Một số khác như…
Chỉ số tốc độ (Speed Index), Thời gian đáp ứng tương tác (Time to Interactive), Paint có nghĩa đầu tiên (First Meaningful Paint), CPU Idle đầu tiên (First CPU Idle), Độ trễ đầu vào tiềm năng tối đa (Max Potential First Input Delay):
Hãy bỏ qua hết mọi thứ này. Chúng thường nói quá về thời gian thực sự của bạn.
Điều chỉnh kích thước hình ảnh một cách đúng cách
Một số gợi ý ở đây là hợp lý và bạn cần tối ưu hóa hình ảnh thông qua việc điều chỉnh kích thước hoặc nén một cách tốt hơn.
Nhưng một số hình ảnh có thể được giữ lại với chất lượng cao hơn (để đảm bảo rõ nét hơn), hoặc kích thước lớn hơn (để tương thích với màn hình Retina).
Và một số hình ảnh thậm chí không cần tối ưu hóa nhiều. Liệu họ có thực sự cần phải lo lắng về việc tối ưu hóa 3KB trên một hình ảnh 1MB không? Nói thẳng, không cần!
Trì hoãn tải hình ảnh ngoài màn hình (Defer Offscreen Images)
KHÔNG! Và tôi ghét công cụ quá mực có ý kiến về điều này. Như tôi đã đề cập trước đó, TÔI GHÉT TẢI TRANG MÀN HÌNH LƯỚI. Hãy đọc hướng dẫn của tôi trước khi tranh cãi với tôi.
Tôi không đề xuất tải trang màn hình lưới cho nhiều trang web. Tại sao? Vì điều này ảnh hưởng đến trải nghiệm người dùng, làm trễ việc tải nội dung chỉ để đạt được “tốc độnhanh hơn”. Và tôi sẽ mãi mãi ghét những công cụ luôn nói với tôi rằng hãy tải trang màn hình lưới.
Phục vụ hình ảnh dưới dạng định dạng mới thế hệ tiếp theo (Serve Images in Next-Gen Formats)
Có thể là một điểm hợp lý để cải thiện việc nén hình ảnh. Nhưng có thể bỏ qua nếu bạn biết tại sao bạn đang sử dụng định dạng hình ảnh cụ thể.
Tôi cũng ghét việc họ đang cố gắng thúc đẩy định dạng WebP một cách quá nhanh, mà thực sự chưa được sử dụng rộng rãi trên tất cả thiết bị, trình duyệt và phần mềm hình ảnh.
Nếu bạn vẫn còn đang sài iphone 6s thì chắc chắn nó không hiển thị tốt đâu!
Eliminate Render-Blocking Resources
Tôi đánh giá cao việc công cụ này cố gắng chỉ ra những mục Render-Blocking, nhưng bạn có hiểu tại sao một số tài nguyên NÊN Render-Blocking không? Đó là để bạn không gặp vấn đề về FOUT/FOUC, nghĩa là nội dung tải trước khi tải CSS stylesheet và khiến mọi thứ trông xấu xí trước khi CSS tải, sau đó trang web phải Render lại. Một số CSS thực sự NÊN Render-Blocking.
JS Render-Blocking cũng tồn tại với một lý do. Một số JS hoàn toàn cần thiết để vẽ phần trực quan của trang web của bạn và nếu không tải JS đó trước, nội dung sẽ hiển thị một cách không mong muốn. Tôi nói đúng hơn… hãy tưởng tượng bạn đang mang một ly rượu đến cho bạn bè bằng cách mang rượu trước (trong tay) và sau đó là cốc. Bạn hiểu rồi, cốc hoàn toàn cần thiết để kiểm soát cách nội dung được truyền tải. Chúng ta không thể để nội dung tràn ra ngẫu nhiên mà không có hiệu ứng vẽ dự kiến.
Mã hóa hình ảnh một cách hiệu quả (Efficiently Encode Images)
Nhiều đề xuất liên quan đến hình ảnh… phiền phức! Đừng lo lắng về điều này nếu hình ảnh của bạn đã được kích thước và nén một cách đúng cách!
Loại bỏ CSS không sử dụng (Remove Unused CSS)
HAHAHAHA! Xin lỗi, mọi người. Điều này không thể thực hiện được đối với hầu hết các bạn. Điều này là do bạn sử dụng nhiều plugin có các kiểu CSS trùng lặp. Có thể là theme của bạn đã thiết kế nút một cách cụ thể, sau đó bạn đã thêm một plugin mua sắm làm nút có kiểu khác, và sau đó thêm một plugin CSS tùy chỉnh với kiểu riêng, ghi đè lên hai kiểu trước đó. Trong trường hợp này, kiểu nút từ theme và plugin mua sắm có thể được xem là “CSS không sử dụng”.
Có chỉ có 2 cách để loại bỏ CSS không sử dụng. Cách dễ dàng hơn cho hầu hết mọi người là loại bỏ CSS không cần thiết từ theme/plugin. Cách tốt nhất (nhưng phức tạp) là tùy chỉnh mã hóa trang web của bạn để chỉ còn mã cần thiết và không có phần không cần thiết. Đó là lý do tại sao tôi thích việc mã hóa tất cả mọi thứ. Trang web của chúng tôi luôn gọn gàng và nhẹ nhàng mà không có thứ không cần thiết.
Giảm thời gian phản hồi máy chủ (TTFB)
Nhìn chung, mọi thứ xung quanh 200ms (0,2 giây) là tốt. Tôi đã thấy GPI phàn nàn về TTFB 0,15 giây trước đó, tôi chỉ bỏ qua nó vì nó quá không chính xác.
Đảm bảo văn bản vẫn hiển thị trong quá trình tải webfont (Ensure Text Remains Visible During Webfont Load)
Không, đó là ý tưởng ngu ngốc. Đó là cách sự cố FOUT xảy ra. Và văn bản của bạn trông xấu xí trong một khoảnh khắc trước khi phông chữ tải lên và sau đó trang web nhanh chóng vẽ lại và gây ra trải nghiệm người dùng khó chịu. KHÔNG, KHÔNG, KHÔNG!
Tránh tải trọng lượng mạng khổng lồ (Avoid Enormous Network Payloads)
Có vẻ như một cảnh báo hợp lệ đề xuất trang web của bạn nên nhẹ nhàng hơn. Tôi đồng tình một phần với đề xuất của GPI ở đây, nhưng tổng thể thì đừng nghiêm túc đối với họ.
Kích thước trang của bạn thực sự không quan trọng. Tôi đã thấy một số trang web có dữ liệu 8MB tải nhanh hơn so với các trang web khác chỉ có 1MB dữ liệu. Vì vậy, mặc dù đúng, tôi đồng tình rằng các trang web luôn nên nhẹ nhàng, tôi không đồng ý rằng kích thước tổng cộng tương quan tốt với thời gian tải. Tại sao? Bởi vì nó liên quan đến thời gian xử lý và trọng lượng vẽ.
Mã lệnh mất thời gian hơn để xử lý và vẽ so với tài sản tĩnh đơn giản. Vì lý do này, một trang web 2MB (với 500KB html, 500KB CSS, 500KB JS và 500KB hình ảnh) sẽ tải nhanh hơn so với một trang web 5MB (chỉ có 100KB html, 100KB CSS, 100KB JS và 4,7MB hình ảnh). Nhưng GPI có tính đến điều này không? Tất nhiên không. Nó chỉ đưa ra cảnh báo tự động khi trang web của bạn vượt qua một kích thước trang nhất định.
Bạn nên cố gắng tải chỉ những mục bạn thực sự cần, nhưng tổng thể, bạn thậm chí không cần lo lắng về điều này nếu trang web của bạn tải nhanh đủ!
Giảm thiểu công việc trên luồng chính (Minimize Main-Thread Work)
Có vẻ như những thước đo hữu ích về thời gian render JS. Tất cả những điều này trong lý thuyết đều quan trọng và bạn nên cố gắng tải ít JS càng tốt. Chỉ có hai cách để làm điều này… hoặc loại bỏ một số plugin nặng hoặc chọn plugin với mã nguồn nhẹ hơn, hoặc viết mã JS của bạn tốt hơn (thường không phải là vấn đề cho những người phát triển chuyên nghiệp).
Nhược điểm của GPI ở đây là nó thường nói quá về thời gian thực hiện theo ý của tôi và cũng không chỉ dẫn người mới làm thế nào để giải quyết vấn đề.
Phục vụ tài nguyên tĩnh với chính sách bộ nhớ đệm hiệu quả (Serve Static Assets with an Efficient Cache Policy)
Một lời khuyên trang web tĩnh (mà thay đổi ít) nên được lưu trữ trong thời gian dài. TUY NHIÊN, không phải tất cả tài nguyên tĩnh nên được lưu trữ. Một số liên quan đến thiết kế và chức năng của trang web của bạn và không nên được lưu trữ để người dùng của bạn có thể thấy phiên bản mới nhất của trang web khi bạn thực hiện thay đổi!
Ngoài ra, một số tài nguyên tĩnh đang tải từ máy chủ của bên thứ ba (như Google Analytics hoặc kịch bản API hoặc webfonts) và vì họ không tải từ trang web của bạn, bạn không kiểm soát cách họ được tải! Bạn có thực sự nghĩ rằng các dịch vụ bên thứ ba sẽ không lưu trữ các tài nguyên này và giảm tải máy chủ của họ nếu họ không có lý do để để chúng không lưu trữ???
Giảm thời gian thực hiện JS (Reduce JavaScript Execution Time)
Một công cụ kiểm tra JS hữu ích để cho bạn biết mỗi JS mất bao lâu để tải. Vấn đề ở đây là nó nói quá về thời gian thực hiện theo ý của tôi và cũng không hướng dẫn người mới làm thế nào để giải quyết vấn đề. Nếu bạn không tự code các JS này, thì bạn chỉ có một lựa chọn để tối ưu hóa nó: loại bỏ chúng. Vâng, điều này có thể đồng nghĩa với việc bạn mất chức năng nào đó. Nếu bạn vẫn muốn có chức năng đó, bạn có thể tải một theme/plugin khác được viết mã hiệu quả hơn hoặc tự tạo mã cho chức năng đó.
Tránh kích thước DOM quá lớn (Avoid Excessive DOM Size)
Thước đo hợp lệ ở đây. Bạn có thể giảm số lượng phần trên trang hoặc sử dụng theme/plugin được viết mã mảnh hơn hoặc viết lại trang để giảm trọng lượng DOM.
Giảm độ sâu của yêu cầu chính (Minimize Critical Requests Depth)
Điều này đơn giản là theme/plugin của bạn quá nặng. Bạn có quá nhiều thứ đang tải và quá nhiều thứ đang tải thêm thứ khác. Hãy chọn theme/plugin nhẹ hơn và/hoặc tự tạo mã cho một số thứ. Hoặc chỉ cần loại bỏ các yếu tố trực quan không cần thiết và chức năng không cần thiết.
Giữ số lượng yêu cầu thấp và kích thước truyền tải nhỏ
Thực sự, điều này không quan trọng miễn là bạn đã làm trang web của bạn nhẹ nhàng nhất có thể. Thật sự không quan trọng nếu bạn có 100-200 yêu cầu và một số kích thước tệp lớn. Quan trọng là trang web của bạn tải nhanh. Và nếu trang web của bạn không tải nhanh, bạn có thể xem danh sách này để xem loại tài nguyên nào bạn đang tải.
