Hành trình optimize Google Page Speed 100/100 và thất bại trong gang tất.

Mình viết bài này giới thiệu các bạn hành trình mình optimize cái site bé nhỏ của mình để được 100 điểm Google Page Speed. Mình thấy cách làm khá đơn giản, bạn không cần phải là một siêu nhân, hoặc một lão làng với kinh nghiệm tối ưu hóa ghê gớm để có thể làm được như vậy. Nào ta bắt đầu.

Tại sao phải optimize website để được 100 Google Page Speed?

Trước tiên mình giới thiệu là trước khi mình viết bài này thì mình cũng chưa có kinh nghiệm gì nhiều về việc tối ưu hóa một cái website thật sự là phải làm nó cụ thể như thế nào. Trước giờ mình toàn làm phát triển tính năng mà thôi, website load 2s hoặc 4s mà nói với mình không khác nhau mấy :).  Và tới giờ cũng vậy bạn ạ,  với mình hay công ty bé bé mình đang đi làm thì cái quan trọng vẫn là mình tập trung resource giải quyết vấn đề quan trọng trước của khách hàng của mình, giải quyết việc quan trọng trước.

Tuy nhiên đời người chỉ sống có một lần, có một số việc mình nên làm ít nhất một lần trong đời, một số việc chúng ta nên một lần trải nghiệm khi thời gian và đời còn cho phép ha. Optimize cái website để nó được 100/100 điểm Google Page Speed là việc mình chưa từng làm, mà dự án công ty thì không có khả năng để làm trong thời gian cho phép nên chỉ có cái site kikiguru.com của mình là có thể mang ra làm thuốc thử nghiệm mà thôi.

Đại ý mình muốn nói là việc optimize cho cái app, cái site của chúng ta là cần thiết tuy nhiên không nhất thiết là phải là 100/100 Google Page Speed, theo mình thì bạn đạt được chừng 70/100 cho các dự án thường thường là ổn lắm rồi. Ý kiến chủ quan của mình là vậy.

Nếu đạt được 100/100 Google Page Speed thì bạn được gì?

Dù là theo mình biết thì Page Speed có ảnh hưởng tới thứ hạng SEO của cái site của bạn, site nào nhanh thì Google ưu tiên hơn tuy nhiên với 100/100 thì với mình chắc chủ yếu là để khoe với mấy bạn là chính, rồi để có thêm kiến thức để tư vấn cho khách hàng, chém gió với anh em. Hoặc lấy nó làm bằng chứng cho năng lực của bạn khi Bid dự án là chính. Còn trải nghiệm của người dùng cuối theo cái cảm nhận của mình thì thấy 100/100 với 80/100 nó chả không khác nhau mấy. Giống như việc cái màn hình 24-inch 4k  với 24-inch FHD+ chả khác nhau mấy về chất lượng hình ảnh đầu ra, kiểu kiểu vậy!

Và đương nhiên quan trọng nhất chính là trải nghiệm, kinh nghiệm, kiến thức quý báu mà mình có được. Cái này sẽ giúp mình đưa ra giải pháp tốt hơn cho các dự án sắp tới.

Sơ sơ về cái site KiKi guru.

Site này mình sử dụng CMS là Ghost, một NodeJS CMS khá mạnh phục vụ cho việc viết bài là chính. Mình có một con server AWS LightSail bé bé với 1Core, 1GB RAM. Mình cài Ghost bằng docker trên đó, database thì MariaDB cài trực tiếp vô luôn, không thông qua docker. Mình cũng có Nginx để serve static content từ Ghost cũng như là reverse proxy.  Mình có vẽ một cái mình tổng quan về cái cách mình triển khai bên dưới nà.

Mình cũng không khá giả gì, nhưng cũng cố gắng dành chút tiền duy trì một cái server Lightsail bé bé đó với kinh phí 5$ 1 tháng. Mình cũng host vài cái linh tinh khác như VPN hay mấy cái tool em yêu khoa học trên dó để tối ưu hóa tài nguyên các kiểu.

Do cũng thuộc tầng lớp vô sản nên anh em thương dùm không nên phá nhé, không thì mình không còn gì để viết bài cho anh em đâu.

Những vấn đề mình đã gặp phải khi thực hiện tối ưu theo Google Page Speed.

0.  First content paint, Largest content paint

1. Server infrastructure
2. Giải quyết bài toán “Initial Server response time slow” với cloudflare
3. Lazy Load image + Image resize + external resources + Processive JPeg, explicit image width + height + lazy load inside editor.
4. Các vấn để trên mobile (link quá nhỏ để nhấn), màu bị high contrast 1.6 và desktop.
5. Web font và System font.
6. Facebook Comment load.
7. Nginx + http2 preload.
8. Thư viện cũ, không biết phải làm sao.
9. Chuyện Gzip vs Broti, Http1, Http2, Http3
10. Có cần 100/100 không, những câu chuyện thành công (tiki.vn, tgdd.com)

Tại thời điểm này có thể thấy mình đang bị vấn đề lớn nhất là Largest Content Paint (LCP). Hiện tại mình đang tốn gần 4s để render.

Mình không cần nhất thiết phải optimize nó tới mức dưới 1s mà đâu đó khoản 2s là mình đã đạt được 99% điểm cho cái LCP rồi. Vậy target của mình là sẽ có gắn giảm từ 4.1s xuống còn 2s cho cái LCP.

Cách giải quyết thế nào? Trước tiên mình cần tìm hiểu LCP là gì?

Largest contentful paint (LCP) là thời gian mà cái phần tử có diện tích lớn nhất xuất hiện trên màn hình của user.

Theo Google thì LCP tốt nhất là nên dưới 2.5s. Vậy mình đặt mục tiêu làm nó dưới 2s thì có vẻ ổn..tới lúc này mình vẫn chưa biết làm sao cả?

Trong cái blog của mình nó chính là cái hình tựa của bài viết á.

Load CSS kiểu Async

Bình thường thì khi gặp file css thì browser sẽ dừng lại ở đó, cho tới khi nó load được file đó về, parse, rồi load lên browser. Có một vài cái css mình thấy không cần thiết lắm như mình có sử dụng google fonts. Nên mình sẽ load google fonts bằng async luôn và sẽ giảm được khoản 500ms thời gian FCP.

<link media="print" onload="this.media='all'" href="https://fonts.googleapis.com/css2" rel="stylesheet">

Image nên có height hoặc width

Mình nghĩ để làm một việc là để tất cả mấy cái image có chiều cao cố định thì khá khó và cũng lười. Tuy nhiên có một cái chỗ mà nó xài rất nhiều trong mấy cái blog đó chính là hình logo và tác giả, vì nó hiện rất nhiều chỗ.

Cuối cùng là nếu bạn nào làm được 100/100 điển trên google chrome lighthouse sẽ có pháo bông bắn té le nha.

Bài này có tham khảo thông tin từ các nguồn:

1. Web.dev  https://web.dev/optimize-lcp