Trong phần 1 của loạt bài viết về “Hướng dẫn tối ưu tốc độ căn bản cho website kiếm tiền online,” chúng ta đã tìm hiểu về công cụ Google PageSpeed. Ngay bây giờ, chúng ta sẽ tiến xa hơn và bắt đầu khám phá một công cụ mạnh mẽ giúp bạn đo lường và cải thiện hiệu suất trang web của mình – đó là GTmetrix.
GTmetrix là một trong những công cụ phân tích tốc độ trang web hàng đầu trên internet, cho phép bạn kiểm tra và đánh giá hiệu suất của trang web của bạn theo nhiều yếu tố quan trọng.
Trong phần này, chúng ta sẽ tìm hiểu cụ thể về GTmetrix, cách sử dụng nó để đo lường tốc độ trang web hiện tại của bạn và làm thế nào để tối ưu hóa trang web của bạn dựa trên các thông số và đánh giá mà công cụ này cung cấp. Hãy cùng nhau bắt đầu hành trình tối ưu hóa trang web để tạo ra một trải nghiệm tốt hơn cho người dùng và tăng cơ hội kiếm tiền trực tuyến của bạn.
Cùng tìm hiểu về GTmetrix nhé!
Khuyến nghị phổ biến từ GTmetrix (và cách đọc chúng)
GTmetrix là công cụ kiểm tra hiệu suất mà tôi xem xét rất cao. Nó đo lường một loạt những điều nhỏ bé, cung cấp số liệu cụ thể và biểu đồ hình ảnh rõ ràng, cũng như nhiều tab và sub-tab chứa thông tin hữu ích cho các nhà phát triển để tối ưu hóa trang web của họ.
Đăng ký tài khoản miễn phí cho phép bạn lựa chọn từ nhiều vị trí kiểm tra và lưu trữ 30 ngày kết quả kiểm tra trước đó để so sánh dễ dàng theo thời gian. Nếu bạn chỉ có thời gian cho một công cụ tốc độ, hãy sử dụng công cụ NÀY!
Dịch vụ ảnh đã được thu nhỏ (Serve scaled images)
Khuyến nghị hợp lệ. Hãy đảm bảo hình ảnh của bạn được cắt và kích thước một cách chính xác theo kích thước hiển thị của chúng. Tuy nhiên, có một số trường hợp nơi bạn muốn có hình ảnh lớn hơn một chút so với không gian được cấp.
Tuy nhiên, có một số trường hợp nơi bạn muốn có hình ảnh lớn hơn một chút so với không gian được cấp cho mục đích tương thích với retina. Bạn có thể sửa chữa điều này bằng cách điều chỉnh kích thước hình ảnh một cách tốt hơn hoặc sử dụng một chủ đề/plugin có thể điều chỉnh kích thước hình ảnh hiển thị một cách đúng đắn.
Vấn đề của tôi với chỉ số này là nó thường thường hiển thị một “F” đáng lo ngại khi thực tế nó không quan trọng đến vậy. Trong nhiều trường hợp, nó không ảnh hưởng đến thời gian tải trang của bạn một cách đáng kể.
Cung cấp tài nguyên từ một URL thống nhất (Serve resources from a consistent URL)
Khuyến nghị hợp lệ. Trang web của bạn nên hiển thị tất cả các tài nguyên từ cùng một tên miền và trong ngữ cảnh của HTTP hoặc HTTPS, có-WWW hoặc không có-WWW. Tuy nhiên, khuyến nghị này không áp dụng khi bạn đang sử dụng CDN. Rõ ràng, vì CDN cần tải từ URL riêng của nó.
Tận dụng việc lưu trữ của trình duyệt (Leverage browser caching)
Một khuyến nghị mà tôi thật sự không thích. Đúng, các tài nguyên tĩnh (không thay đổi thường xuyên) thường nên được lưu trữ trong thời gian dài. Tuy nhiên, không phải tất cả các tài nguyên tĩnh nên được lưu trữ. Một số tài nguyên 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ó thể thấy phiên bản mới nhất của trang web khi bạn thay đổi!!!
Hơn nữa, 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 các tập lệnh API, hoặc webfont) và do họ không tải từ trang web của bạn, bạn không kiểm soát được cách chúng được tải! Bạn có thực sự nghĩ rằng các dịch vụ của bên thứ ba không lưu trữ các tài nguyên này và giảm thiểu tải máy chủ của họ nếu họ không có lý do để để chúng không được lưu trữ???
Hoãn việc phân tích Javascript (Defer parsing of Javascript)
JS làm chặn render tồn tại với một lý do. Một số JS hoàn toàn cần thiết để render các phần trực quan của trang web của bạn và nếu không tải JS đó trước (còn gọi là “JS quan trọng”), nội dung sẽ tràn ra một cách không mong muốn.
Bạn có thể và nên tối ưu hóa nó, nhưng bạn phải biết đâu là JS cần được hoãn lại và đâu là JS không nên. Bạn cũng nên cẩn thận để biết cách hoãn lại nó để không ảnh hưởng đến thiết kế hoặc chức năng của trang web của bạn. Có thể, việc tối ưu hóa dễ nhất đối với hầu hết mọi người là tránh càng nhiều hiệu ứng thiết kế, tính năng và plugin không cần thiết càng tốt.
Kết hợp hình ảnh bằng cách sử dụng CSS sprites (Combine images using CSS sprites)
Đây là một chiến thuật ngớ ngẩn và g cumbersome từng phổ biến vào thời kỳ cách đây khoảng 10-20 năm. Mặc dù hiện tại nó có thể đôi khi hữu ích, nhưng nó không có nhiều tác động trong thời kỳ hiện tại của giao thức HTTP/2. Nó cũng rất phiền phức để xây dựng các CSS sprite.
Thu nhỏ số lượng chuyển hướng (Minimize redirects)
Chỉ số này đôi khi hợp lệ nhưng đôi khi chỉ trỏ đến các vấn đề mà bạn không kiểm soát. Mọi chuỗi chuyển hướng do trang web của bạn tạo ra nên được sửa chữa một cách tất yếu. Ví dụ: tất cả URL trên trang web của bạn nên sử dụng cùng một tên miền (HTTP hoặc HTTPS, có-WWW hoặc không có-WWW).
Đôi khi, vấn đề đơn giản là do bạn nhập phiên bản HTTP của tên miền của bạn vào bài kiểm tra thay vì HTTPS. Tuy nhiên, bất kỳ chuỗi chuyển hướng nào do tài nguyên của bên thứ ba tạo ra (được tải từ máy chủ của bên thứ ba) không thể được sửa chữa hoặc kiểm soát bởi bạn. Bạn phải bỏ qua chúng hoặc ngừng sử dụng plugin/dịch vụ nào đó đang tạo ra các yêu cầu được chuyển hướng đó.
Chỉ định một bộ kiểm tra bộ nhớ cache (Specify a cache validator)
Chỉ số kỹ thuật không dành cho người không phải là nhà phát triển. Hầu hết thời gian, nó tham chiếu đến các tài nguyên của bên thứ ba mà bạn không kiểm soát. Đơn giản là bỏ qua nó!
Tránh CSS @import (Avoid CSS @import)
Chỉ số hợp lệ chỉ ra điều gì đó ảnh hưởng đến thời gian tải trang của bạn. Thật không may, CSS @import thường được sử dụng bởi một số chủ đề và plugin vì nhiều lý do khác nhau. Tôi muốn nói rằng điều này thường là do sự lười biếng. Tại thời điểm này, tôi khuyên bạn nên tránh sử dụng các chủ đề/plugin đó hoặc tìm cách khác để bao gồm các tệp CSS đó.
Muốn tối ưu hóa và bao gồm tệp CSS một cách thủ công? Hãy thử hướng dẫn này (Gift of Speed) hoặc hướng dẫn này (Varvy).
Tối ưu hóa hình ảnh (Optimize Images)
Chỉ số hữu ích để cho bạn biết hình ảnh nào có thể được tối ưu hóa thêm. Ðây là quan điểm của tôi. Hãy tối ưu hóa hình ảnh nhỏ hoặc không quan trọng càng nhiều càng tốt. Nhưng đối với các hình ảnh quan trọng cần chất lượng tốt (sản phẩm, nhiếp ảnh, vv), bạn có thể muốn sử dụng chất lượng cao hơn so với những gì kiểm tra này đề xuất. Đây là lý do tại sao quan trọng phải biết điều gì phù hợp nhất cho trang web của bạn thay vì lắng nghe một công cụ tự động.
Chỉ định kích thước hình ảnh (Specify Image Dimensions)
Tôi không nghĩ điều này thực sự cần thiết và tôi lười để giải thích tại sao. Được rồi, tôi sẽ thử một phiên bản ngắn gọn. Cơ bản, có thể hiệu quả về việc sử dụng lại một số hình ảnh trong các vị trí khác nhau của trang web của bạn ngay cả khi chúng không phù hợp với kích thước hoàn hảo. Tôi cũng nghĩ rằng việc không thiết lập kích thước chỉ ảnh hưởng đến quá trình hiển thị ban đầu một cách không đáng kể nhưng không ảnh hưởng đến kết quả cuối cùng.
Thu nhỏ Javascript (Minify Javascript)
Tôi ghét việc kiểm tra tính điểm lớn của việc này. Rất nhiều lần, việc tiết kiệm 50% của một số tệp JS chỉ tiết kiệm được 1KB. Hầu hết thời gian, việc thu nhỏ Javascript thậm chí không tạo ra sự khác biệt lớn… và nếu có, thì vấn đề của bạn là bạn có quá nhiều JS từ đầu! Btw, nếu bạn thực sự muốn thu nhỏ Javascript của mình, bạn có thể làm điều đó từ Cloudflare tại mức độ DNS thay vì lãng phí sức mạnh xử lý cho một số plugin PHP.
Nhúng Javascript nhỏ (Inline Small Javascript)
Đúng, điều này là đúng. Nhúng một số JS ngoại vi nhỏ hơn có thể hiệu quả hơn là tạo một yêu cầu HTTP riêng biệt cho nó.
Tuy nhiên, điều này thường được gọi là yêu cầu bên ngoài vì có lý do! Và nếu bạn không phải là một lập trình viên, bạn sẽ không biết liệu nó có nên được nhúng hay không. Tại sao phải mất công cho một lợi ích nhỏ nhặt như vậy?
Tối ưu hóa thứ tự các kiểu dáng và tệp script:
Chỉ số có vẻ không cần thiết. Điều quan trọng không phải là thứ tự nạp tệp script không quan trọng, mà là cách chúng được nạp theo cách không tối ưu do việc sử dụng các chủ đề và plugin nặng nề. Vì vậy, lại một lần nữa… hãy loại bỏ một số tính năng và chức năng hoặc tạo mã thủ công.
Thu nhỏ HTML (Minify HTML)
Không quá quan trọng theo ý kiến của tôi. Chắc chắn, nó làm cho trang web của bạn nhẹ hơn một chút nhưng với cái giá là gì? Thu nhỏ trang web của bạn miễn phí tại mức độ DNS với Cloudflare là lựa chọn yêu thích của tôi.
Thực hiện nó tại mức độ máy chủ trên mỗi yêu cầu nạp trang ban đầu?… Tôi nghĩ rằng điều này thật ngớ ngẩn. Đây là một trong những khuyến nghị ảnh hưởng nhiều khi trang web của bạn quá phình to, và NẾU trang web của bạn quá phình to, thì chúng ta biết bạn nên tập trung vào việc giảm phình to và không lãng phí thêm sự xử lý máy chủ để thu nhỏ nội dung!
Thu nhỏ CSS (Minify CSS)
Giải thích tương tự như trên.
Chỉ định bộ ký tự sớm (Specify a character set early)
Không quá quan trọng và không ảnh hưởng nhiều. Tôi sẽ nói rằng nếu bạn thấy chỉ số này, chủ đề của bạn có lẽ đã bỏ lỡ điều đó! Bạn có thể chỉ định bộ ký tự một cách thủ công theo hướng dẫn này.
Kích hoạt nén gzip (Enable gzip compression)
Chỉ số hoàn toàn hợp lệ nhưng hơi phiền phức vì nó không giải thích các tình huống thay thế. Đầu tiên: bạn hoàn toàn nên sử dụng nén GZIP vì nó giúp giảm kích thước của tài nguyên trang web của bạn, làm cho việc truyền và tải nhanh hơn. TUY NHIÊN, bạn hoàn toàn có thể bỏ qua GZIP và khuyến nghị này nếu bạn đã sử dụng nén BROTLI trên máy chủ của bạn, điều này còn tốt hơn GZIP! THỨ HAI: bạn cũng nên bỏ qua khuyến nghị này nếu nó tham chiếu đến các tài nguyên được tải từ máy chủ của bên thứ ba (vì bạn không kiểm soát chúng!).
Chỉ định tiêu đề Vary: Accept-Encoding (Specify a Vary: Accept-Encoding header)
Không quá quan trọng theo ý kiến của tôi. Nhưng một lần nữa, nó thường tham chiếu đến các tài nguyên của bên thứ ba mà bạn không kiểm soát.
Tránh các yêu cầu không tốt (Avoid bad requests)
Chỉ số hoàn toàn hợp lệ. Bạn không nên thực hiện bất kỳ cuộc gọi nào đối với tài nguyên không tồn tại. Có thể bạn đang tham chiếu đến những thứ không tồn tại hoặc bạn có thể viết sai một số liên kết và tên hình ảnh. Hãy sửa chúng!
Tránh chuyển hướng trang đích (Avoid landing page redirects)
Khuyến nghị hợp lệ! Nhưng cũng có thể là bạn đã nhập phiên bản sai của tên miền của bạn? Hoặc có thể bạn đang có ý định một cuộc chuyển hướng?
Kích hoạt Keep-Alive (Enable Keep-Alive)
Khuyến nghị này nói chung là một điều tốt trong thế giới hiệu suất tải trang. Tuy nhiên, trong thế giới máy chủ, có nhiều ý kiến khác nhau. Một số người nói rằng bạn nên bật nó, nhưng đặt một giới hạn thời gian cụ thể. Người khác nói rằng bạn có thể tắt nó để có hiệu suất tốt hơn. Bạn có thể quyết định cái nào là tốt nhất bằng cách xem xét trang web, lưu lượng và khả năng máy chủ của bạn. Điều này là một trong những điều mà bạn cần phải là một chuyên gia máy chủ để biết liệu bạn nên bật hoặc tắt nó hoặc thậm chí tự mình kích hoạt nó.
Nhúng CSS nhỏ (Inline small CSS)
Tất nhiên, bạn có thể làm điều này nếu bạn biết cách và nếu bạn biết liệu cách này có hiệu quả hơn cách khác. Nhỏ là như thế nào?
Và liệu nó có cần phải được nhúng nếu các tài nguyên tĩnh đó đã được lưu trữ? Liệu cần phải nhúng nếu nó không được sử dụng cho việc hiển thị quan trọng? Ehhh, có lẽ cần phải có nhiều kỹ thuật mã hóa thủ công và nhiều tinh túy nhỏ để xem xét cho một cái gì đó có thể sẽ không ảnh hưởng nhiều đến bạn!
Thu nhỏ kích thước yêu cầu (Minimize request size)
Lý tưởng! Hãy cố gắng giữ nó nhỏ để trang web của bạn tải nhanh hơn!
Đặt CSS trong phần head của tài liệu (Put CSS in the document head)
Vâng, đó là khuyến nghị tổng quan hợp lệ. Nhưng không nhất thiết phải tuân theo nghiêm ngặt nếu bạn biết bạn đang làm gì.
Ưu tiên các tài nguyên bất đồng bộ (Prefer asynchronous resources)
Vâng, điều này thường được khuyến nghị.
Tránh ký tự set trong thẻ meta (Avoid a character set in the meta-tag)
Không quá quan trọng theo cách này hoặc cách khác. Đây là cách để làm điều đó.
Tránh src hoặc href trống (Avoid empty src or href)
Tôi nghĩ rằng những vấn đề này tương đối không đáng kể nhưng có thể ảnh hưởng đến máy chủ của bạn nếu bạn có rất nhiều và/hoặc lưu lượng lớn. Tôi ghét điều này là công cụ không cho bạn biết nơi src hoặc href trống.
Đặt Javascript ở cuối trang (Put JavaScript at bottom)
Logic thông thường đằng sau khuyến nghị này hoàn toàn có lý. HTML là nội dung, CSS là kiểu dáng trực quan và JS thường liên quan đến chức năng. Vì vậy, thông thường chúng ta nghĩ rằng HTML và CSS nên tải trước và JS nên tải sau cùng.
Vấn đề duy nhất với logic này là hiện nay, JS thường được sử dụng cho mục đích thiết kế. Thường xuyên được sử dụng để tải thanh trượt, hoặc các phần tử chủ đề, hoặc nhiều phần tử trực quan khác. Trì hoãn JS đó và bạn sẽ trì hoãn tải trang của mình. Vì vậy, điểm của tôi là… khuyến nghị này không luôn luôn liên quan và chắc chắn không áp dụng cho mọi JS.
Vì vậy, tùy vào bạn để biết xem JS nào có thể trì hoãn một cách an toàn và JS nào nên tải càng nhanh càng tốt. Và khi bạn biết điều đó, bạn có thể hoàn toàn bỏ qua khuyến nghị này.
