Hướng dẫn WPO tối ưu tốc độ tải trang website của bạn

WPO là gì?

Web Performance Optimization, mà chúng tôi gọi là WPO, đơn giản là việc tối ưu hóa các quy trình khác nhau ảnh hưởng đến cách một website tải.

Cách đo tốc độ tải của website?

Có rất nhiều công cụ để đo tốc độ tải. Những công cụ phổ biến nhất là:

• ›

  Google Page Speed

• ›

  Lighthouse

• ›

  GTMetrix

Trước khi bắt đầu kiểm tra, điều quan trọng là phải ghi nhớ rằng tốc độ tải khác nhau đối với mỗi người dùng. Các biến khác nhau có thể ảnh hưởng đến cách tốc độ cảm nhận đối với một người dùng ở Cuenca so với một người ở Ottawa.

Đó là lý do tại sao, thay vì làm việc về thời gian tải tính bằng giây, chúng tôi khuyên bạn tập trung vào việc tối ưu hóa:

• ›

  Trọng lượng website (MB)

• ›

  Requests

• ›

  Thời gian phản hồi máy chủ

Nếu chúng ta cải thiện 3 lĩnh vực này, tốc độ tải sẽ cải thiện bất kể người dùng ở đâu.

Chúng ta sẽ đi sâu vào từng lĩnh vực và, thông qua các công cụ khác nhau, chúng ta sẽ thấy cách làm việc với chúng để cải thiện hiệu suất của mọi URL. Tại sao tôi nói mọi URL? Bởi vì, mặc dù điều đó có vẻ hiển nhiên, tôi đã gặp nhiều trường hợp chỉ dữ liệu trang chủ được đánh giá, và tất nhiên, mỗi trang trên một site không tải các tài nguyên giống nhau.

Google Developer Tools

Trước khi bắt đầu, tôi muốn giải thích một số tùy chọn mà Google cung cấp thông qua các công cụ dành cho nhà phát triển của họ. Công cụ này là một trong những công cụ quan trọng nhất để phân tích cách một website hoạt động. Nhấp chuột phải vào trang mà trình duyệt đã mở và một bảng với các tùy chọn khác nhau sẽ xuất hiện. Chúng ta sẽ đến Inspect (Ctrl + Shift + I).

Khi công cụ đó được mở, chúng ta sẽ đến tùy chọn NETWORK mà bạn sẽ tìm thấy ở phía trên cùng. Nếu chúng ta nhấn ENTER lại trong trình duyệt, công cụ sẽ hiển thị việc tải các tài nguyên khác nhau.

Ở phía dưới của hình ảnh, chúng ta có thể thấy dữ liệu mà chúng ta quan tâm để có cái nhìn tổng quan về cách site tải.

Đào sâu hơn vào panel này từ trên cùng và xem cấu trúc cột, chúng ta có:

• ›

  Name: tên của tài nguyên.

• ›

  Status: mã phản hồi của tài nguyên (200, 301, 404...)

• ›

  Type: loại tài nguyên (script, font, png, jpg, stylesheet...)

• ›

  Initiator: tài nguyên nào kích hoạt request.

• ›

  Time: request mất bao lâu.

• ›

  Waterfall: biểu diễn đồ họa về thời gian tải của một tài nguyên.

Nếu chúng ta nhấp chuột phải ở trên cùng, chúng ta có thể thêm và xóa các cột với thông tin này.

Bật các yếu tố thông tin bổ sung như Domain, Scheme hoặc Cookies có thể giúp trong các trường hợp cụ thể để định vị các tài nguyên có thể gây ra một số vấn đề cho chúng ta, nhưng tại thời điểm này, chúng ta sẽ gắn bó với những cái đến được xác định trước.

Có một khía cạnh, mặc dù rất thú vị, tôi sẽ chỉ đề cập nhẹ để chúng ta ghi nhớ. Tốc độ kết nối, đặc biệt là trên di động, là một phần quan trọng của cách một site tải. Từ công cụ này, chúng ta có thể mô phỏng các tốc độ chậm hơn như 3G trên di động.

Làm thế nào để biết trọng lượng của một URL và làm thế nào để giảm nó?

Trọng lượng, dù tính bằng Megabyte hay Kilobyte, là một trong những lý do chính khiến một URL mất thời gian tải. Đó là lý do tại sao chúng ta bắt đầu bằng cách đi sâu vào khía cạnh này, vì nó sẽ thiết lập con đường để đạt được tối ưu hóa tốt trên site của chúng ta.

Dữ liệu sau đến từ công cụ được đề cập ở trên, GTMETRIX, và tương ứng với một website mà tôi sắp bắt đầu tối ưu hóa.

Chúng ta sẽ tập trung vào dữ liệu ở cột bên phải, cột đề cập đến (Page Details), cụ thể là Total Page Size.

Thoạt nhìn, trọng lượng của site này cao hơn nhiều so với mức trung bình, nhưng hãy nhớ rằng điều quan trọng không phải là tổng trọng lượng của site mà là trọng lượng đó mất bao lâu để tải, vì có một thứ gọi là Lazy Load, một tính năng trì hoãn việc tải cho đến khi người dùng cần tài nguyên. Chúng ta sẽ nói về nó sau.

Chúng ta cũng có thể tìm thông tin này trong các công cụ dành cho nhà phát triển, trong panel chúng ta đã xem ở trên, mà tôi sẽ nhắc lại với bạn lần nữa.

Nếu bạn nhìn vào phía dưới, cả 7,5 MB và 215 request đều rất gần với các con số được báo cáo bởi GTMETRIX. Quan trọng là bạn phải biết GTMETRIX lấy thông tin từ đâu trong trường hợp bạn muốn sử dụng một công cụ khác.

Bây giờ hãy xem điều gì đang nặng đến vậy và làm thế nào chúng ta có thể sửa nó.

Tùy chọn Waterfall cung cấp cái nhìn trực quan về cách các tài nguyên tải, hiển thị URL tài nguyên, status, domain và cột Size. Nếu chúng ta nhấp vào cột cuối cùng đó, nó sẽ sắp xếp trọng lượng từ lớn nhất đến nhỏ nhất và từ nhỏ nhất đến lớn nhất.

Nhìn vào trọng lượng, chúng ta có thể thấy, như xảy ra trong hầu hết các trường hợp, rằng hình ảnh là nguyên nhân lớn cho trọng lượng quá mức của URL.

Không có quy định chính thức về trọng lượng tối đa mà một hình ảnh nên có, nhưng chúng tôi khuyến nghị không quá 100 KB và, nếu bạn có tùy chọn (nếu bạn sử dụng Photoshop, bạn có), đặt hình ảnh tải dần dần dưới dạng JPG và tránh PNG bất cứ khi nào bạn không cần kênh Alpha (độ trong suốt).

Bằng cách giảm trọng lượng hình ảnh, chúng ta sẽ cải thiện đáng kể việc tải của site, và có một số công cụ bạn có thể sử dụng. Cá nhân tôi tối ưu hóa với Photoshop, nhưng có những tùy chọn online thú vị:

• ›

  https://imagecompressor.io/compress

• ›

  https://kraken.io/web-interface

Cả GTMetrix và công cụ Google đều cho phép chúng ta xem các tài nguyên theo loại, tức là chỉ hình ảnh, script, CSS...

Điều này hữu ích cho một góc nhìn rộng hơn về nơi cần làm việc. Trên URL này, hình ảnh chiếm 4 MB trong tổng số 7,2 MB, vì vậy phần lớn vấn đề trọng lượng nằm ở đó. Mặc dù vậy, có những tài nguyên khác nổi bật là rất nặng đối với loại của chúng, như một file CSS hơn 700 KB và một Script hơn 300 KB.

Tại thời điểm này, tôi muốn làm rõ rằng khi chúng ta thực hiện tối ưu hóa tốc độ tải (WPO), chúng ta phải đối mặt với một số vấn đề mặc dù có giải pháp, nhưng không nằm trong tầm kiểm soát của chúng ta để hành động.

Trong trường hợp này, chúng ta thấy một file CSS rất lớn. Nếu nhà thiết kế đã tạo một CSS hơn 700 KB, việc tối ưu hóa file cụ thể đó sẽ khó khăn.

Chúng ta có thể làm gì để giảm trọng lượng của các file này?

Minify (CSS, JS và HTML)

Minification là một quy trình tìm cách giảm trọng lượng file bằng cách loại bỏ dữ liệu không cần thiết như comment, khoảng trắng, code lặp lại và code không sử dụng. Có nhiều công cụ để thực hiện quy trình này, ngoại trừ phần code không sử dụng, vốn khó tối ưu hóa hơn và sẽ yêu cầu đi vào file theo cách thủ công (điều mà tôi không khuyến nghị).

Công cụ để minify file

• ›

  HTML Minifier http://kangax.github.io/html-minifier/

• ›

  CSS Nano https://cssnano.co/

• ›

  Uglify http://lisperator.net/uglifyjs/

May mắn thay, chúng ta đang nói về WordPress, và như tất cả chúng ta đều biết, trong WordPress, rất hiếm khi không tìm thấy plugin xử lý hoạt động này.

Cá nhân tôi thích sử dụng một plugin hoàn toàn miễn phí, Autoptimize, và một plugin trả phí, WP Rocket.

Trong bài viết này, tôi không muốn giải thích cách các plugin này hoạt động nhiều như cách thực hiện các tác vụ tối ưu hóa. Bởi vì nếu chúng ta sử dụng các plugin khác, chúng cũng có những tùy chọn này, và điều tốt nhất là hiểu những gì chúng ta đang làm.

Minify với WP Rocket

Phần này không phức tạp. Chúng ta chỉ cần đến tab tối ưu hóa file và chọn ô minify HTML. Trong WP Rocket, tùy chọn này được lặp lại bên dưới cho các file CSS và JS. Tuy nhiên, tôi khuyên bạn nên bật ô này và kiểm tra. Lặp lại tùy chọn này từng cái một, vì nếu có gì đó thất bại, sẽ dễ dàng hơn để xác định vấn đề.

Trước khi kiểm tra hiệu ứng của minification, chúng ta phải xóa cache, nếu không, chúng ta sẽ không thấy kết quả của HTML đã cập nhật.

Cách xóa cache trình duyệt?

Các loại plugin này đi kèm với các tùy chọn để xóa cache, mà chúng ta có thể thấy ở phía trên cùng.

Một cách khác là thông qua trình duyệt, khi Google Developer Tools được bật (Ctrl + Shift + I).

Nhấp chuột phải vào mũi tên "reload page" và chọn "empty cache and hard reload."

Minify với Autoptimize

Với Autoptimize, hành động optimize là cái thực hiện minification, với đặc thù là cung cấp tùy chọn để giữ comment HTML. Những comment này thường được các nhà phát triển thêm vào để giữ thông tin có thể hữu ích trong tương lai.

Để kiểm tra rằng tối ưu hóa này đã có hiệu lực, chúng ta sẽ đến mã nguồn của URL và sẽ thấy một cái gì đó như sau:

Code trở nên không thể đọc được nhưng chức năng của nó vẫn giống nhau.

Các tùy chọn này lặp lại theo cùng một cách trong WP Rocket và Autoptimize cho các file CSS và JS. Như tôi đã đề cập trước đó, tôi không khuyên bạn nên tối ưu hóa mọi thứ cùng một lúc, mà 1 cái 1 lần. Các plugin này giữ các bản sao của các file đã được minify, vì vậy việc khôi phục về bản gốc là khả thi bằng cách bỏ chọn ô tương ứng.

Để tiếp tục giảm trọng lượng trang, chúng ta có thêm 2 tùy chọn:

• ›

  Loại bỏ hoặc giảm các plugin thêm CSS hoặc JS vào việc tải.

• ›

  Loại bỏ hoặc cắt giảm code không sử dụng từ file CSS.

2 tùy chọn này phức tạp hơn và yêu cầu nhiều kiến thức hơn, vì bạn phải cẩn thận và đảm bảo rằng không có các lệnh gọi từ các trang khác đến phần bạn đang loại bỏ.

Trong khi việc loại bỏ plugin không phải lúc nào cũng có thể vì tài nguyên mà chúng cung cấp, có những plugin được tối ưu hóa tốt hơn các plugin khác, có nghĩa là ít request hơn và JS nhẹ hơn. Vì vậy, trong hệ sinh thái WordPress tuyệt vời, hầu như luôn có một sự thay thế.

Thời gian tải so với thời gian phản hồi

Bây giờ là lúc nói về request, thời gian phản hồi và thời gian tải. Tại thời điểm này, chúng ta phải đề cập đến một phần cơ bản của quy trình: máy chủ. Tối ưu hóa máy chủ thường nằm ngoài tầm kiểm soát của chúng ta, vì vậy điều quan trọng là phải chọn một giải pháp hiệu quả.

Nhưng hãy đi từng bước.

Request là gì?

Một request, hay HTTP Request, là một lệnh gọi được thực hiện từ client đến máy chủ để yêu cầu một tài nguyên nhất định. Request có thể đến các máy chủ khác nhau.

Request có thể là HTTP hoặc HTTPS. Nếu chúng ta nhìn vào cấu trúc của một request, chúng ta có thể phân tích nơi sự chậm trễ về thời gian xảy ra.

Phân tích thời gian của một HTTP request

Hãy phân tích những gì chúng ta thấy trong biểu đồ thời gian này.

• ›

  Request được khởi động nhưng bị block hoặc xếp hàng: Nếu block kéo dài lâu, có thể do nhiều lý do: các request có ưu tiên cao hơn hoặc nhiều request đến nguồn này.

• ›

  DNS Lookup: trình duyệt đang phân giải địa chỉ IP của request.

• ›

  Connecting: thời gian cần để kết nối với máy chủ để giải quyết request. Nếu thời gian này cao, nó có thể chỉ ra các vấn đề mạng, lỗi kết nối hoặc một máy chủ quá tải.

• ›

  Sending: yêu cầu tài nguyên được gửi.

• ›

  Waiting: đây là thời gian máy chủ mất để giải quyết một request và gửi phản hồi; nếu nó dài, có vấn đề trên máy chủ.

• ›

  Receiving: nhận tài nguyên.

Một HTTPS request thêm một bước nữa, được hiển thị ở đây.

Hai screenshot này thuộc về hai site khác nhau, một chưa được tối ưu hóa (HTTP Request) và một được tối ưu hóa (HTTPS Request).

Nếu bạn nhìn kỹ và so sánh, sự khác biệt lớn nhất là ở thời gian chờ. Trong những trường hợp này, bạn cần phân tích máy chủ chi tiết hơn.

Server request: làm thế nào chúng ta có thể giảm chúng?

Như chúng ta đã thấy, số lượng request liên quan chặt chẽ đến thời gian tải, vì vậy việc giảm số lượng request sẽ cải thiện thời gian tải của một URL. Common sense đóng một vai trò trong quy trình tối ưu hóa và biết liệu một tài nguyên có thực sự hữu ích cho người dùng hoặc doanh nghiệp của chúng ta hay không. Đây là khoảnh khắc để tạm biệt một số tài nguyên không thêm gì cả, nhưng tôi không phải là người quyết định điều đó.

Tuy nhiên, chúng ta có các tùy chọn để cải thiện request, mặc dù những hành động này không mang lại sự thay đổi lớn cho việc tải của site. Tôi sẽ lặp lại bản thân: điều tốt nhất là loại bỏ các tài nguyên không thêm gì.

Kết hợp CSS và JS

Một hành động phổ biến khác khi tối ưu hóa một trang web là kết hợp các tài nguyên CSS và JS, nhưng điều đó có nghĩa là gì?

Mục tiêu của việc kết hợp là giảm request với chi phí tăng trọng lượng file. Kết hợp có nghĩa là hợp nhất các tài nguyên CSS hoặc JS khác nhau thành một tài nguyên duy nhất.

Nếu thời gian phản hồi dài, việc kết hợp có thể có lợi. Nếu thời gian gửi rất chậm, có lẽ kỹ thuật khác sẽ tốt hơn.

Lý tưởng là kết hợp trong khi có một máy chủ tốt, để chúng ta thắng ở cả hai mặt.

Kết hợp tài nguyên với WP Rocket và Autoptimize

Hoạt động kết hợp với các plugin này đơn giản như trước. Chúng ta chỉ cần chọn ô tương ứng.

Trong WP Rocket, các tùy chọn để kết hợp CSS và JS là giống nhau; các panel gần như giống hệt nhau. Như chúng ta thấy trong hình, có một ô để thêm đường dẫn của các file mà chúng ta không muốn kết hợp.

Bên dưới checkbox, chúng ta cũng thấy một ghi chú về việc không sử dụng tùy chọn kết hợp nếu chúng ta đang sử dụng HTTP/2. Bài viết này giải thích thêm về HTTP/2.

Autoptimize cung cấp nhiều tùy chọn hơn để làm việc với CSS và giảm request. Trong tùy chọn tôi đánh dấu, nó kết hợp và đưa ra cảnh báo về tác động mà nó có thể có, nhưng cuối cùng điều này luôn tương đối.

Trong phần đầu tiên của bài viết, tôi muốn giải thích một số hành động cơ bản nhất định bao gồm những gì, những hành động chúng ta thường thấy trong hầu như tất cả các plugin tối ưu hóa WPO, nhưng vẫn còn nhiều điều chúng ta có thể làm để cải thiện cả request và thời gian tải.

Cấu hình cache

Không nghi ngờ gì, tối ưu hóa cache là một trong những hành động mà chúng ta sẽ nhận thấy những cải thiện lớn nhất trong cách một site tải. Trong bài viết về SEO cho WordPress này, tôi đã giải thích cách cache hoạt động. Tôi khuyến khích bạn xem để hiểu cách nó hoạt động.

Autoptimize và WP Rocket thực hiện các hành động caching, nhưng WP Rocket cung cấp cho bạn vài tùy chọn nữa. Đáng chú ý là các plugin đã biến tối ưu hóa này thành một thứ đơn giản hơn: bạn hầu như không có một vài tùy chọn và quy trình nhanh chóng và không đau đớn.

Như bạn thấy, WP Rocket cho phép bạn làm việc trên 4 thứ:

• ›

  Bật caching cho các thiết bị di động.

• ›

  Lưu các file riêng cho thiết bị di động.

• ›

  Bật caching cho người dùng đã đăng nhập.

• ›

  Chỉ định thời gian để xóa cache.

Phụ thuộc vào mỗi dự án để chọn tùy chọn nào, nhưng với tất cả những điều này, lời khuyên của tôi là:

• ›

  Cache di động luôn luôn, vì mặc dù hầu hết các site đều responsive, có nội dung bạn có thể có trên di động nhưng không có trên desktop.

• ›

  File riêng biệt.

• ›

  Không có cache cho người dùng đã đăng nhập, trên hết là vì nếu tôi đang chỉnh sửa, tôi không muốn caching.

• ›

  Thời gian cache, phụ thuộc vào việc bạn thực hiện bao nhiêu thay đổi đối với site của mình. Nếu đó là một site tin tức hàng ngày, ngắn; nếu đó là nội dung không cập nhật thường xuyên, dài hơn.

Lazyload

Tính năng lazyload giúp hiển thị tài nguyên (Hình ảnh và Iframe) khi người dùng cần chúng; tức là, trình duyệt không tải các tài nguyên này cho đến khi người dùng cuộn đến chúng. Tính năng này được triển khai trong nhiều plugin và thậm chí được cấu hình sẵn trong một số theme WordPress. Từ phiên bản Chrome 76 trở đi, nó thậm chí còn đi kèm nguyên bản trong trình duyệt.

Điều này có nghĩa là bằng cách thêm thuộc tính loading="lazy", trình duyệt đã diễn giải lazy loading của hình ảnh, nhưng tất nhiên không phải mọi trình duyệt đều sẽ diễn giải điều này, vì vậy tôi khuyên bạn nên tiếp tục sử dụng plugin. Đây là một video được rút ra từ web.dev cho thấy một ví dụ về lazy loading hình ảnh là gì.

Tối ưu hóa Iframe

Nếu chúng ta sử dụng iframe để nhúng nội dung từ các site khác, chúng ta có hai hành động chúng ta có thể sử dụng để cải thiện việc tải của mình.

• ›

  Lazy loading thông qua chức năng lazyload

• ›

  Hoặc thay thế iframe bằng một hình ảnh cho đến khi người dùng nhấp vào nó.

Cả tùy chọn đầu tiên và thứ hai đều có thể được bật thông qua, một lần nữa, plugin yêu thích của chúng ta WP Rocket.

Autoptimize không có phần này nhưng cung cấp việc cài đặt một plugin bổ sung để thực hiện điều đó https://wordpress.org/plugins/wp-youtube-lyte/

Tải hoãn các file JS với Defer hoặc Async

File JS là một trong những thủ phạm của những gì các kiểm tra tốc độ gọi là render blocking của một trang. Điều này xảy ra khi, trong quá trình rendering, trình duyệt dừng lại để tải xuống một file JS và thực thi nó. Mục tiêu của tối ưu hóa WPO là cung cấp thông tin cho người dùng càng sớm càng tốt, đó là lý do tại sao điều này được coi là blocking, vì không có gì được render cho đến khi JS đã tải xuống thực thi.

Đó là lý do tại sao loại hành động này có xu hướng được gắn cờ trong kiểm tra. Khi sử dụng các plugin của bên thứ ba hoặc theme không được tối ưu hóa tốt, chúng ta có thể có JS chặn rendering vì nó, ví dụ, ở header.

Trong những trường hợp này, chúng ta nên sử dụng hai thuộc tính được thêm vào trong code lệnh gọi JS, Defer và Async. Để các thuộc tính này hoạt động, các script phải là bên ngoài.

Tại SEO Alive, chúng tôi sử dụng plugin Pre Party Resource Hints, cho phép bạn chọn file nào và phương pháp tải nào bạn muốn áp dụng. Một điều kỳ diệu!

Sự khác biệt giữa Defer và Async là gì?

Mặc dù cả hai thuộc tính đều có mục tiêu tương tự, ngăn chặn việc diễn giải DOM HTML bị JS dừng lại, có một sự khác biệt đáng chú ý giữa hai cái.

Với thuộc tính Async, tài nguyên được tải xuống mà không dừng việc tải HTML, nhưng khi đã tải xuống, việc tải HTML bị tạm dừng để thực thi JS; với thuộc tính defer, tài nguyên cũng được tải xuống song song với việc tải HTML, nhưng nó chạy khi việc tải kết thúc, vì vậy không có blocking bởi script.

Về vấn đề này, có sự khác biệt giữa WP Rocket và Autoptimize. WP Rocket làm cho các quyết định dễ dàng hơn nhiều cho bạn và hành động theo cách bán tự động để giữ JS không chặn rendering; trong Autoptimize, mặt khác, bạn chỉ có thể chuyển đổi tùy chọn Async.

Trong Autoptimize, dưới tab extra, chúng ta có tùy chọn này để thêm các file JS chúng ta muốn tải bằng Async, nhưng để có sự linh hoạt hơn, họ khuyến nghị một plugin bổ sung khác, "Async Javascript".

Với plugin này, chúng ta có thể làm việc với cả Defer và Async, và thậm chí cung cấp các tùy chọn một-nhấp-chuột để làm cho mọi thứ dễ dàng hơn. Điều tốt về plugin này là chúng ta có thể làm việc với các script và loại trừ những script chúng ta cho là cần thiết. Trong WP Rocket, mặt khác, chúng ta phải tin tưởng những gì plugin làm, mặc dù nó làm tốt.

Tùy chọn này nằm trong cùng một tab tối ưu hóa file.

CDN là gì và nó có thể giúp chúng ta như thế nào?

Một CDN là cái được gọi là content delivery network. CDN chịu trách nhiệm lưu một phần thông tin và các tài nguyên để giảm tải máy chủ cho các tài nguyên đó và phản hồi tốt hơn việc tải. CDN cũng có chức năng sao chép địa lý, để giữ tài nguyên có sẵn ở các điểm khác nhau và phục vụ nó cho người dùng bất kể họ kết nối từ đâu. Thông thường loại dịch vụ này được sử dụng cho các file nặng như Hình ảnh và Video.

Đăng ký dịch vụ này là quan trọng khi chúng ta có các site có nhiều lưu lượng truy cập, mặc dù không nên loại trừ đối với các site có ít lưu lượng truy cập.

Các hành động khác sẽ giúp chúng ta cải thiện một chút nữa

Để kết thúc bài viết, chúng ta có 3 cải tiến nữa, mặc dù chúng sẽ không tạo ra những thay đổi lớn trong thời gian tải, sẽ giúp chúng ta giảm request, và cuối cùng đó là điều chúng ta muốn.

Tối ưu hóa font

Tối ưu hóa font có thể được thực hiện thông qua các plugin hoặc thủ công bằng cách chỉnh sửa và tối ưu hóa CSS. Lý tưởng sẽ là chỉ gọi font bạn sẽ sử dụng và không, như xảy ra trong nhiều trường hợp, tải xuống một file với tất cả các Google Fonts.

Autoptimize có một tùy chọn để làm việc trên fonts.

Khó nói tùy chọn nào để chọn mà không thấy dự án, vì tôi không biết template của bạn sử dụng font nào và khi nào nó tải, vì vậy điều tốt nhất là kiểm tra và xem kết quả.

Như bạn thấy, ngay sau các tùy chọn Google Fonts chúng ta có "Remove Emoji", sẽ tiết kiệm cho chúng ta một request đến máy chủ. Chức năng của nó đơn giản là chuyển đổi các ký hiệu đại diện cho emoji thành biểu tượng.

WP Rocket cũng cho phép chúng ta vô hiệu hóa các emoji này và cũng cung cấp tùy chọn để ngăn nội dung được nhúng trên các site bên thứ ba.

Cuối cùng có nhiều hành động để cải thiện tốc độ tải của một site. Không phải lúc nào cũng có thể làm việc sâu để tối ưu hóa mọi tài nguyên, vì nó phụ thuộc vào loại hình kinh doanh và những gì nó cần.

Tôi hy vọng hướng dẫn tối ưu hóa WPO này hữu ích và bạn có thể áp dụng nó cho các dự án của mình hoặc cho khách hàng của mình.