Lỗi PageSpeed Insights API 429 (Cách Đo Điểm Chuẩn Xác)

Nếu bạn gọi PageSpeed Insights API ẩn danh và nó luôn trả về lỗi 429, thì bạn không làm gì sai cả — bạn chỉ đang chạm vào một giới hạn quota chưa bao giờ được thiết kế cho cách bạn đang dùng nó. Tôi gặp đúng chuyện này khi cố xây dựng slide hữu ích nhất trong bất kỳ buổi pitch redesign nào: một con số hiệu năng trước/sau thật, có thể trích dẫn được. API ẩn danh chặn tôi hoàn toàn, còn phương án dự phòng — chạy Lighthouse cục bộ — lại cho ra những con số nhảy lung tung đến mức không tin nổi. Đây là chuyện thật sự đang xảy ra, và cách sửa cuối cùng cho ra điểm số tôi có thể đưa thẳng cho khách hàng mà không phải ngần ngại.

Vì sao PageSpeed Insights API luôn trả về lỗi 429

Bản năng đầu tiên khi bị rate-limit là nghĩ rằng đây là quota theo ngày, theo tài khoản, và bạn đã dùng hết. Không phải vậy, nếu bạn gọi API ẩn danh (không có API key, hoặc key chưa gắn billing). Quota miễn phí của PSI API là chia sẻ trên toàn cầu cho mọi caller ẩn danh, không phân bổ theo từng người dùng hay từng ngày. Bạn không cạnh tranh với lịch sử request của chính mình — bạn đang cạnh tranh với mọi script, cron job, pipeline CI trên toàn internet cùng gọi vào chung một endpoint công khai đó. Vào giờ cao điểm, pool đã cạn trước khi request đầu tiên của bạn kịp tới. Lấy một API key từ Google Cloud Console nâng trần quota lên, nhưng không giải quyết được vấn đề gốc: một response API vẫn chỉ là một khối JSON số liệu. Nó không có sức nặng hình ảnh nào trong một bộ slide pitch, và khách hàng không thể tự chạy lại trong ba mươi giây để kiểm chứng con số của bạn. Ngay cả khi API chạy được, đây vẫn là công cụ sai cho đúng việc này.

Vì sao npx lighthouse chạy cục bộ cho điểm khác nhau mỗi lần

Vậy nên tôi bỏ API, chuyển sang chạy Lighthouse cục bộ:

npx lighthouse https://example.com --view

Lần chạy đầu: Performance 66. Lần hai, cùng URL, không đổi gì cả: Performance 91. Lần ba: 98. Cùng một trang, cùng một đoạn code, ba kết quả khác nhau hoàn toàn. Đây không phải bug — đó chính là cách Lighthouse được thiết kế để hoạt động khi bạn chạy nó trên chính máy tính của mình.

Lighthouse cục bộ throttle trang web qua CPU và mạng thật của máy bạn để mô phỏng một thiết bị di động tầm trung. Nghĩa là điểm số của bạn là hàm số của bất kỳ thứ gì máy bạn đang làm tại thời điểm đó — tab Chrome khác, Slack đang index nền, một container Docker vừa khởi động, Wi-Fi giật một hai giây. Mô hình throttling áp một hệ số nhân lên phần cứng thật của bạn, nên bất kỳ nhiễu nào trên máy cũng bị khuếch đại thành một con số Performance hoàn toàn khác. Nó cũng thường bi quan hơn so với một môi trường lab sạch, vì laptop làm việc của bạn hiếm khi rảnh rỗi như bạn tưởng. Lighthouse cục bộ là công cụ chẩn đoán hợp lý để tìm ra cái gì đang chậm — nhưng là một công cụ tệ để chứng minh cho người khác rằng bạn đã làm nó nhanh hơn, vì hai lần chạy "trước" và "sau" không hề tương đồng với nhau, hay với bất cứ điều gì khác.

Cách sửa: dùng pagespeed.web.dev, không dùng API

Cách sửa thật sự không phải là viết script thông minh hơn — mà là đổi hẳn công cụ đo. pagespeed.web.dev chạy cùng engine PageSpeed Insights, nhưng thông qua hạ tầng do chính Google host, thay vì laptop của bạn hay tầng API ẩn danh bị rate-limit. Có hai điều khiến nó trở thành công cụ đúng cho một tuyên bố trước/sau:

1. Đây là con số của Google, không phải của bạn. Các gauge được render bởi server của Google, trên mạng của Google, với profile throttling của Google — khách hàng có thể chụp màn hình kiểm chứng, hoặc tự dán URL của bạn vào và ra cùng một con số. Đó là mức độ tin cậy mà một response API dạng JSON hay output terminal cục bộ không bao giờ có được.
2. Nó đủ ổn định để so sánh, miễn là bạn kiểm soát các biến số làm nó dao động. Chạy liên tiếp nhau, cùng khung giờ, cùng trạng thái trang, độ dao động nhỏ hơn hẳn so với sự hỗn loạn do throttling CPU của Lighthouse cục bộ.

Quy trình thực tế cho ra một bộ trước/sau đứng vững:

1. Mở pagespeed.web.dev, dán URL của site cũ, chạy, và để nó ổn định hoàn toàn (chọn tab mobile, vì phần lớn traffic và các đánh giá Core Web Vitals đều dựa trên đó).
2. Chụp màn hình đúng phần hàng gauge — vùng nhỏ nhất chứa đủ bốn điểm số (Performance, Accessibility, Best Practices, SEO). Không chụp toàn trang kèm khung trình duyệt; chỉ gauge, gọn và rõ.
3. Lặp lại cho site mới, cùng tab thiết bị, tốt nhất trong cùng một phiên để không có gì thuộc hạ tầng của Google trôi dạt giữa hai lần chạy.
4. Đặt hai ảnh chụp cạnh nhau. Sự kết hợp đó — cùng công cụ, cùng thiết lập, cùng ngày — là thứ biến "chúng tôi đã làm nó nhanh hơn" thành một tuyên bố mà người khác thật sự có thể kiểm chứng.

Quy tắc nền tảng phía sau tất cả: đo site cũ và site mới bằng cùng một công cụ, và chọn công cụ mà người kia có thể tự chạy lại độc lập. Đừng bao giờ trộn "trước" đo bằng Lighthouse cục bộ với "sau" đo bằng PSI hosted — lúc đó bạn không còn đo redesign nữa, mà đang đo sự khác biệt giữa hai mô hình throttling, và bất kỳ người xem tinh ý nào cũng sẽ nhận ra.

Một lưu ý về thứ thật sự cải thiện

Hãy trung thực về chỗ điểm số thật sự tăng. Một site cũ được xây dựng tương đối tử tế thường đã đạt gần 100 điểm ở SEO và Best Practices — hiếm khi còn nhiều dư địa ở đó, và việc khoe một "điểm SEO" tăng ấn tượng khi nó chỉ nhích từ 92 lên 100 không phải là câu chuyện đáng kể. Những chiến thắng thật sự, đứng vững của một dự án redesign gần như luôn nằm ở Performance và Accessibility — đó là những hạng mục nơi một template cũ cồng kềnh thật sự có chỗ để tụt điểm, và nơi kỹ thuật có chủ đích thật sự tạo ra khác biệt. Hãy khung buổi pitch xoay quanh hai hạng mục mà con số thật sự có ý nghĩa.

Cách thật sự đạt điểm cao trên một site tĩnh

Để có được ảnh chụp "sau" đẹp không phải là may mắn — nó đến từ một danh sách ngắn các quyết định liên tục cải thiện Performance và Accessibility, theo thứ tự tác động gần đúng:

• Tự host font và preload chúng. Một thẻ <link> trỏ tới Google Fonts tốn thêm một lượt DNS lookup, một kết nối, một round trip trước khi file font còn chưa bắt đầu tải — và cho tới khi nó tới nơi, bạn hoặc có chữ vô hình hoặc bị layout shift khi font swap vào. Tự host file woff2 và preload chúng loại bỏ toàn bộ chuỗi đó:

  <link
    rel="preload"
    href="/fonts/inter-var.woff2"
    as="font"
    type="font/woff2"
    crossorigin
  />
  

  Đây là một trong những cách sửa đơn giản, rẻ nhất cho cả Cumulative Layout Shift lẫn Largest Contentful Paint trên một trang nhiều chữ.

• Đừng che hero bằng opacity: 0 chờ animation library trước khi paint đầu tiên. Nếu section hero render ở opacity: 0 và chờ một timeline GSAP (hay bất kỳ JS nào) fade vào, bạn vừa đẩy lùi Largest Contentful Paint của mình tới sau khi hydrate và chạy script xong — trên CPU mobile bị throttle, đó là vài giây thật sự, đo được. Hãy để hero paint ngay lập tức ở trạng thái hình ảnh cuối cùng, rồi animate các phần tử phụ xung quanh nó sau. Tôi đi sâu hơn vào đánh đổi này trong bài Core Web Vitals cho web nhiều chuyển động — chuyển động và một LCP tốt không hề mâu thuẫn, miễn là bạn sắp xếp đúng trình tự.

• Preload rõ ràng ảnh LCP. Bất kỳ ảnh hoặc phần tử nào trình duyệt xác định là ứng viên Largest Contentful Paint nên được preload, không để mặc trình tự khám phá mặc định của trình duyệt:

  <link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />
  

  Kết hợp với fetchpriority="high" trên chính thẻ <img> để trình duyệt không hạ ưu tiên nó phía sau các request khác.

• Sửa thứ tự heading. Đây là điểm Accessibility thuần túy và không tốn gì cả: một <h1> mỗi trang, không nhảy cấp (một <h2> không bao giờ nên nhảy thẳng xuống <h4>), và heading được dùng cho cấu trúc tài liệu thật sự chứ không chọn vì cỡ chữ. Audit accessibility của Lighthouse kiểm tra trực tiếp điều này, và đây là một sửa lỗi năm phút trên hầu hết template.

Không cái nào trong số này đòi hỏi migrate framework hay dựng lại từ đầu — chúng là khoảng cách giữa một trang trông nhanh trong ảnh chụp và một trang thật sự đạt được điểm số đó.

PSI API vs Lighthouse cục bộ vs giao diện pagespeed.web.dev

	PSI API (ẩn danh)	npx lighthouse cục bộ	Giao diện pagespeed.web.dev
Quota	Chia sẻ toàn cầu, thường xuyên 429	Không có (chạy trên máy bạn)	Gần như không giới hạn khi dùng thủ công
Độ ổn định giữa các lần chạy	N/A (không nhận được response)	Kém — dao động 20-30+ điểm trên cùng một trang	Tốt — đủ ổn định để so sánh
Đo cái gì	Dữ liệu lab của Google, nếu nó phản hồi	CPU/mạng laptop của bạn, bị throttle	Môi trường lab hosted của Google
Mức độ đáng tin với khách hàng	Thấp — một khối JSON thô	Thấp — một con số terminal không ai khác tái tạo được	Cao — khách hàng có thể tự chạy lại
Dùng tốt nhất cho	Ngân sách hiệu năng tự động trong CI (với API key thật)	Chẩn đoán cục bộ xem cái gì đang chậm	Bằng chứng trước/sau cho pitch hoặc báo cáo

Mang cái này vào buổi pitch redesign của bạn

Toàn bộ mục đích của việc này là một slide đứng vững trước sự soi xét: hai ảnh chụp gauge, cùng công cụ, cùng ngày, một cái mờ và một cái sáng xanh. Đó là một lập luận mạnh hơn bất kỳ đoạn văn nào tuyên bố "đã tối ưu hiệu năng". Nếu bạn đang cân nhắc xem redesign có đáng đầu tư hay không ngay từ đầu, tôi đã viết riêng về bài toán kinh doanh trong bài cái giá thật của một website chậm — còn nếu bạn muốn có người thực hiện toàn bộ quy trình đo lường và sửa lỗi này giúp bạn, đó chính xác là công việc trên trang dịch vụ.

FAQ

Làm sao để lấy điểm Lighthouse trước/sau chính xác?

Chạy phiên bản cũ và mới của site qua cùng một công cụ, trong cùng một phiên, rồi so sánh trực tiếp output của các gauge thay vì so sánh những con số rời rạc. pagespeed.web.dev là lựa chọn thực tế nhất vì nó đủ ổn định để so sánh và người bạn trình bày có thể tự kiểm chứng — hãy chụp toàn bộ hàng gauge cho cả hai.

Vì sao điểm Lighthouse của tôi khác nhau mỗi lần chạy?

Lighthouse cục bộ throttle CPU và mạng của bạn để mô phỏng một thiết bị di động, dùng phần cứng thật của máy bạn làm baseline. Các tiến trình nền, hiện tượng CPU throttle vì nhiệt, và độ trễ mạng đều làm baseline đó dịch chuyển, nên cùng một trang có thể chênh 20-30 điểm giữa các lần chạy. Đây là công cụ chẩn đoán, không phải công cụ benchmark.

Lighthouse cục bộ vs PageSpeed Insights — nên tin cái nào?

Dùng Lighthouse cục bộ (npx lighthouse --view) để chẩn đoán cái gì đang chậm trong quá trình phát triển — nó nhanh và tiện cho việc lặp lại. Dùng giao diện pagespeed.web.dev hosted khi bạn cần một con số để trình bày cho người khác, vì nó ổn định và tái tạo được ở phía họ.

Làm sao để thật sự chứng minh một cải thiện hiệu năng website cho khách hàng?

Cùng công cụ, cùng thiết lập, site cũ và site mới đo liên tiếp nhau, trình bày dưới dạng cặp ảnh chụp gauge thay vì một con số phần trăm tự tuyên bố. Khách hàng nên có thể dán URL của bạn vào cùng công cụ đó và nhận được đúng kết quả bạn đã cho họ xem.

pagespeed.web.dev vs npx lighthouse — khác nhau thật sự ở đâu?

Cả hai đều chạy engine Lighthouse bên dưới, nhưng pagespeed.web.dev thực thi nó trên hạ tầng hosted của Google với môi trường nhất quán, còn npx lighthouse thực thi cục bộ, bị throttle qua CPU và điều kiện mạng biến động của chính máy bạn. Với bất kỳ điều gì bạn cần trình bày hay bảo vệ trước người khác, hãy dùng bản hosted.