Tối ưu website Cloudflare: Lighthouse 100 cho tiệm hoa

Mình đã xây website của Nhà Nhi, một tiệm hoa ở Đà Nẵng, tại hoatuoidanangnhanhi.com. Ngày 4/10/2026, trên máy tính, trang đạt 100 điểm ở cả bốn mục kinh điển của Lighthouse. Trên điện thoại cũng vậy: cả bốn mục đều 100, và mục mới Agentic Browsing đạt 3/3 ở cả hai thiết bị. Trang cũng đạt 100/100 và Level 5, “Agent-Native”, trên công cụ quét isitagentready.com. Bài này kể lại những gì đã thay đổi để đến được đó, bằng ngôn ngữ dễ hiểu, kể cả những thay đổi từng làm hỏng việc.

Thuật ngữ nào cũng có phần giải thích ngắn để bấm mở. Nếu bạn là chủ shop, hãy đọc phần kết quả và phần bài học. Nếu bạn làm web, các phần giữa có chi tiết kỹ thuật.

Kết quả trước

Mọi con số dưới đây lấy từ một báo cáo PageSpeed Insights tạo lúc 1:04 sáng (GMT+7) ngày 4/10/2026, dùng Lighthouse 13.5.0.

Lighthouse và PageSpeed Insights là gì?

Lighthouse là công cụ của Google tự động “khám sức khỏe” một trang web. Nó mở trang trong một trình duyệt được kiểm soát rồi chấm từ 0 đến 100 cho Performance (tốc độ), Accessibility (khả năng truy cập cho mọi người), Best Practices (mã sạch và an toàn) và SEO (công cụ tìm kiếm có hiểu được trang không). PageSpeed Insights là website miễn phí chạy Lighthouse giúp bạn. Số liệu đến từ bài test trong phòng thí nghiệm, không phải từ khách truy cập thật.

	Máy tính	Điện thoại
Performance	100	100
Accessibility	100	100
Best Practices	100	100
SEO	100	100
Agentic Browsing	3/3	3/3
Nội dung đầu tiên hiện ra (FCP)	0,3 giây	1,2 giây
Ảnh chính hiện ra (LCP)	0,4 giây	1,4 giây
Thời gian “bận” (TBT)	0 ms	0 ms
Trang bị “nhảy” (CLS)	0,001	0
Speed Index	0,5 giây	1,5 giây

FCP, LCP, TBT, CLS và Speed Index nghĩa là gì?

FCP (First Contentful Paint) là lúc chữ hoặc ảnh đầu tiên xuất hiện. LCP (Largest Contentful Paint) là lúc phần lớn nhất trên màn hình, thường là ảnh chính, hiện đầy đủ; dưới 2,5 giây là tốt. TBT (Total Blocking Time) đo thời gian trình duyệt quá bận để phản hồi khi bạn chạm vào màn hình trong lúc tải. CLS (Cumulative Layout Shift) đo mức trang bị “nhảy” bố cục khi đang tải, ví dụ nút bấm dịch chuyển đúng lúc bạn chạm; 0 là hoàn hảo. Speed Index cho biết phần nhìn thấy của trang được lấp đầy nhanh đến đâu.

Mở ảnh kích thước đầy đủ ↗

Kết quả trên máy tính trong báo cáo PageSpeed Insights ngày 4/10/2026. Các vòng điểm nằm phía trên, các chỉ số tốc độ nằm bên dưới.

Mở ảnh kích thước đầy đủ ↗

Kết quả trên điện thoại cũng từ báo cáo đó. Điện thoại được giả lập là Moto G Power trên mạng 4G chậm nên thời gian dài hơn máy tính.

Điểm Performance trên điện thoại có thể lệch một điểm giữa các lần chạy, vì Lighthouse giả lập một chiếc điện thoại tầm trung trên mạng chậm (xem tài liệu của Lighthouse về độ dao động điểm). Báo cáo còn hiện “No Data” ở phần dữ liệu người dùng thật, nên tất cả ở đây là dữ liệu phòng thí nghiệm.

Kết quả thứ hai đến từ Is Your Site Agent-Ready? (isitagentready.com), công cụ quét xem một website thân thiện với trợ lý AI đến mức nào. Nó cho trang 100/100 điểm và xếp Level 5, “Agent-Native”, với mọi nhóm có điểm đều đạt 100. Lần quét trước đó cùng đêm cho 94 vì thiếu A2A Agent Card; sau khi mình bổ sung card, lần quét lại đã đạt.

Mở ảnh kích thước đầy đủ ↗

Lần quét lại độ sẵn sàng cho agent lúc 1:18 sáng ngày 4/10/2026. Mục Commerce không có điểm vì là mục tùy chọn và công cụ không thấy dấu hiệu thương mại điện tử trên site.

Vì sao một tiệm hoa cần làm chuyện này

Phần lớn khách tìm tiệm hoa ở Đà Nẵng bằng điện thoại, thường đang vội, thường dùng mạng di động. Một trang mất bốn giây mới hiện được tấm ảnh đầu tiên sẽ mất khách vào tay kết quả tìm kiếm kế bên. Đó là mặt tốc độ.

Giờ còn có một nhóm “khách” nữa. Nhiều người hỏi trợ lý AI về “hoa tươi Đà Nẵng” và mong nhận câu trả lời ngắn có tên shop, giờ mở cửa và cách đặt hàng. Nếu trợ lý không đọc được website một cách sạch sẽ, nó sẽ trả lời bằng nguồn khác. Làm cho website dễ đọc với các trợ lý này chính là điều người ta gọi là GEO (tối ưu để các công cụ AI trích dẫn website của bạn trong câu trả lời) và AEO (tối ưu cho công cụ trả lời).

SEO, GEO và AEO là gì?

SEO (search engine optimization) là giúp Google và các công cụ tìm kiếm tìm thấy và xếp hạng trang của bạn. GEO là ý tưởng tương tự cho các công cụ AI tự viết câu trả lời từ nhiều nguồn. AEO là tối ưu cho ô trả lời nhanh hoặc câu trả lời bằng giọng nói ở đầu kết quả. Ba thứ này chồng lên nhau khá nhiều: nội dung rõ ràng, thông tin doanh nghiệp chính xác và dữ liệu có cấu trúc trung thực đều giúp cả ba.

Điểm xuất phát

Website chạy Astro kèm một ít React, đặt trên Cloudflare, có cơ sở dữ liệu cho danh mục sản phẩm và kho lưu ảnh. Trang có khoảng 222 sản phẩm, 21 danh mục và hơn 600 bài blog, tổng cộng chừng 890 địa chỉ trong sitemap.

Cloudflare, CDN và "edge" là gì?

Cloudflare là công ty đứng giữa website của bạn và khách truy cập. CDN (mạng phân phối nội dung) của họ giữ bản sao các trang ở nhiều trung tâm dữ liệu trên thế giới. “Edge” là các trung tâm dữ liệu gần người xem. Một trang lấy từ bản sao ở gần luôn nhanh hơn nhiều so với việc lần nào cũng phải gọi về máy chủ gốc.

Bức tranh ban đầu khá lẫn lộn. Hồi tháng 8, một đợt kiểm tra chín loại trang cho thấy bảy loại đã đạt 100 ở các mục không liên quan tốc độ, nhưng có vài điểm nổi cộm: trang liên hệ mất điểm vì phần câu hỏi thường gặp lồng một thẻ HTML vào thẻ khác sai cách, và một thiết lập Cloudflare cho thẻ Google chạy qua chính tên miền của shop đã tốn 313 KB trên tổng 845 KB của trang chủ.

Ngày 3/9, một đợt quét mới kiểm tra toàn bộ 891 địa chỉ trên điện thoại. Điểm trung bình là 87, và 511 trang dưới 92, mốc “xanh an toàn” mà mình dùng. Trang sản phẩm yếu nhất: 211 trên 222 trang nằm dưới mốc, với LCP trung vị 4,95 giây. Trước đó, ngày 28/8, chính trang chủ từng bị chấm 0 điểm trên cả hai thiết bị vì Lighthouse không tìm được phần tử chính để bấm giờ. Nguyên nhân nằm ở phần sau.

Cách đo

Một lần chạy may mắn chẳng chứng minh được gì, nên việc đo đạc đi trước mọi thứ.

• Mỗi ngày có một báo cáo tiếng Việt gửi tóm tắt Search Console và PageSpeed qua Telegram, và tự mở ghi chú khi có chỉ số tụt.
• Mỗi tuần quét hai lần toàn bộ địa chỉ, không chỉ trang chủ, và lưu lại lịch sử.
• Mỗi lần sửa đều có một bài test tự động nhỏ để lỗi cũ không thể quay lại mà không ai biết.

Vòng lặp đó quan trọng hơn bất kỳ mẹo nào. Nó cũng dạy một điều khó chịu: nhiều chuyện “bí ẩn” trong điểm số đến từ việc bài test chạy ở đâu, lúc nào, chứ không phải từ mã nguồn.

Lớp 1: Cloudflare

Cache không hề tồn tại

Cloudflare Pages không cache HTML do Worker trả về, kể cả khi bạn yêu cầu. Năm lần liên tiếp mở cùng một trang sản phẩm đều trả về DYNAMIC, thời gian phản hồi từ khoảng 1 đến 2,3 giây. Trong Google Search Console, 72 địa chỉ nằm ở trạng thái “Discovered, currently not indexed” hơn 30 ngày, trong đó 50 là trang sản phẩm. Mình nghi phản hồi chậm là một phần lý do, nhưng chưa đo được tác động đó, nên chỉ coi là giả thuyết.

Worker, cache HIT/MISS và TTFB là gì?

Cloudflare Worker là chương trình nhỏ chạy tại edge, có thể trả lời hoặc chỉnh sửa một yêu cầu. Cache HIT nghĩa là câu trả lời lấy từ bản đã lưu, rất nhanh. MISS nghĩa là trang phải được tạo lại, chậm hơn. TTFB (Time To First Byte) là thời gian máy chủ bắt đầu trả lời.

Cách sửa là thêm một lớp cache riêng ngay trong Worker. Lớp này chỉ lưu các trang công khai trả về thành công, bỏ qua những thứ mang tính cá nhân như tài khoản, giỏ hàng và thanh toán, và gắn header X-Edge-Cache cho biết HIT, MISS hay BYPASS để nhìn là biết chuyện gì đã xảy ra. Mọi thao tác cache đều được bọc lại, nên nếu cache lỗi thì trang vẫn được tạo bình thường thay vì cả site sập.

Một vấn đề về sau: sau khi deploy, có trang vẫn hiện bản cũ 46 phút sau đó. Mình đưa mã phiên bản build vào khóa cache, nhờ vậy mỗi bản phát hành mới tự bỏ qua các bản sao cũ mà không cần xóa cache thủ công. Cloudflare giữ cache riêng ở từng trung tâm dữ liệu, điều này cũng giải thích vì sao PageSpeed, vốn test từ một nơi còn “nguội”, hay gặp phản hồi đầu tiên 420 ms mà trình duyệt của mình không bao giờ thấy.

Ảnh theo từng trung tâm dữ liệu

Ảnh được đổi kích thước theo yêu cầu qua image transformations của Cloudflare. Lần đầu xin một kích thước mới ở một trung tâm dữ liệu sẽ chậm. Với một biến thể banner, lần đầu mất 0,755 giây ở Hong Kong và 0,394 giây ở Singapore, rồi chỉ còn 0,181 và 0,127 giây khi đã có cache. PageSpeed thường rơi đúng vào trường hợp nguội, nên mình cache ảnh đã đổi kích thước bằng Cache API của Worker và chuẩn hóa yêu cầu để ?w=800&f=webp và ?f=webp&w=800 được tính là một mục.

Các công tắc trong bảng điều khiển

Một số tác động lớn nhất đến từ các thiết lập nằm ngoài mã nguồn:

• Rocket Loader, công tắc của Cloudflare trì hoãn script, viết lại thẻ script theo cách làm hỏng việc chuyển trang của Astro. Trang tài khoản treo ở dòng “đang kiểm tra đăng nhập” cho đến khi tải lại. Mình đã tắt nó.
• Early Hints cho phép trình duyệt bắt đầu tải ảnh và CSS trong lúc máy chủ còn đang chuẩn bị trang. Đang bật.
• Smart Tiered Cache cho các trung tâm dữ liệu dùng chung bản sao, nên ít khách phải chạm tới máy chủ gốc chậm. Đang bật.
• Cổng thẻ Google (tag gateway), thiết lập đứng sau con số 313 KB, đã biến mất khỏi trang chủ.

Thiết lập trong bảng điều khiển rất dễ bị quên. Giờ mình giữ chúng trong một script chạy lại an toàn nhiều lần, và ghi chú lý do cho từng thiết lập.

Lớp 2: giao diện

Ảnh đúng cỡ

Trong bài test của Lighthouse, điện thoại được coi là rộng 412 pixel với màn hình sắc nét, và trình duyệt cứ chọn ảnh rộng khoảng 1.200 pixel. Mình tạo cho mỗi ảnh một dải kích thước hợp lý, để điện thoại nhận file nhỏ. Một banner trang chủ giảm từ 47,4 KB xuống 21,7 KB, và khoảng 44 thẻ sản phẩm vốn tải 88 đến 133 KB cho khung chỉ rộng 206 pixel giờ tải bản nhỏ hơn nhiều. Tác động: điện thoại tải ít byte hơn hẳn trước khi ảnh chính hiện ra.

srcset, sizes, WebP và AVIF là gì?

srcset và sizes là các thuộc tính HTML giúp trình duyệt chọn file ảnh nhỏ nhất mà vẫn sắc nét trong khung của nó. WebP và AVIF là định dạng ảnh hiện đại, nhìn giống JPEG hay PNG nhưng nhẹ hơn nhiều. AVIF còn nhẹ hơn nữa, nhưng tạo ra chậm hơn.

Sau đó, những tấm ảnh sản phẩm khổ dọc cho thấy điều quyết định dung lượng là số điểm ảnh chứ không phải độ “phức tạp”: một tấm ảnh dọc có số điểm ảnh gấp năm lần banner ngang, trong khi khung chỉ hiển thị một phần. Cắt ảnh ngay tại CDN theo đúng khung hiển thị và dùng AVIF đã giảm một ảnh sản phẩm từ 267.742 byte xuống 87.578.

Điểm số bằng không

Có thời gian trang chủ bị chấm 0 trên điện thoại, bốn lần liên tiếp. Bản ghi vết cho thấy không có phần tử chính nào được ghi nhận. Thủ phạm là một dòng CSS ở dải đánh giá khách hàng: scroll-snap kết hợp cuộn mượt khiến trình duyệt tự “bắt” lại vị trí dải đó mỗi khi font và ảnh tải xong, mà trình duyệt thì ngừng ghi nhận LCP sau bất kỳ lần cuộn nào, kể cả lần không ai nhìn thấy. Với mắt người, mọi thứ vẫn bình thường. Mình chỉ gắn các hành vi đó bằng JavaScript sau khi trang tải xong. Trên trang test, điểm hôm đó đi từ 0 lên 83, và các bước sau đưa nó cao hơn nữa. Tác động: trang chủ lại có điểm thật thay vì 0.

Trang bị “nhảy”

Hiện tượng nhảy bố cục đến từ ba nơi. Một thanh công cụ co lại khi cuộn, một form đăng nhập bị ẩn cho đến khi máy chủ trả lời, và ở danh sách sản phẩm, thanh bên nằm trước trong HTML rồi bị CSS đẩy xuống khi nội dung đến. Cách sửa trong cả ba trường hợp là dựng sẵn bố cục cuối cùng ngay trên máy chủ và giữ thứ tự HTML giống thứ tự người dùng nhìn thấy. Giờ có một bài test cấm mẹo đổi thứ tự bằng CSS ở khu cửa hàng. Tác động: trang không còn dịch chuyển dưới ngón tay, và CLS trên điện thoại là 0 trong báo cáo cuối.

Bớt JavaScript, HTML gọn hơn

Ba ví dụ. Mỗi lần tải trang từng bắn khoảng ba lượt xem Google Analytics trên hai ID, kéo theo 461 KB script Google và 155 yêu cầu thừa trên một trang sản phẩm, chiếm 53% số byte. Mình chuyển sang một công cụ chạy ở edge là Zaraz, gửi dữ liệu phân tích từ máy chủ Cloudflare thay vì từ điện thoại của khách, và bỏ phần còn lại. 76 KB mã giỏ hàng nằm trong mọi trang được tách thành khoảng 6 KB cộng một phần tải khi cần. Và khung Google Maps trở thành một ô giữ chỗ, bấm mới tải.

Còn một quy tắc ngón tay cái mà mình đã đo. Một kết nối bắt đầu bằng việc gửi khoảng 14,6 KB, rồi nhân đôi dần. Trang HTML nén dưới khoảng 43,8 KB đến nơi trong hai lượt đi-về (một lượt đi-về là một thông điệp gửi tới máy chủ và phản hồi quay lại); lớn hơn thì cần ba lượt, thêm khoảng 150 ms cho lần hiện nội dung đầu. Vì vậy mình rút gọn mọi script inline lúc build và đặt ngân sách 8 KB script inline nén xuất hiện ở mọi trang; hiện là 7,4 KB. Tác động: ít phải tải hơn, điện thoại ít phải xử lý hơn, và TBT là 0 ms trong báo cáo cuối.

Lớp 3: phía máy chủ

Danh mục sản phẩm được phục vụ từ cơ sở dữ liệu qua Cloudflare. Thay đổi ở đây khá nhỏ. Dữ liệu chiến dịch dùng thời gian cache ngắn dần khi thay đổi tiếp theo đến gần. Danh sách sản phẩm được phân trang ngay trên máy chủ, giảm HTML từ 60 xuống 27 KB sau khi nén. Đơn hàng được bảo vệ chống gửi trùng, và giới hạn số yêu cầu lặp lại sẽ chặn khi có lỗi thay vì mở toang. Những việc này không hiện thành điểm số nào, nhưng giữ cho các đường nhanh luôn đáng tin. Tác động: trang vẫn nhanh và đơn hàng vẫn an toàn khi shop lớn dần.

Lớp 4: sẵn sàng cho AI agent

AI agent là chương trình duyệt web, đọc và hành động thay con người. Nó không đoán được website cất thông tin ở đâu, nên một site chuẩn bị tốt sẽ công bố các tệp và phản hồi nhỏ, theo chuẩn chung, chỉ rõ mọi thứ nằm ở đâu. Mục Agentic Browsing của Lighthouse và công cụ isitagentready.com đều kiểm tra những thứ này.

robots.txt, Content Signals, MCP, WebMCP và API catalog nghĩa là gì?

robots.txt là tệp văn bản cho bot biết phần nào của site được phép ghé. Content Signals là các dòng bổ sung trong đó, cho biết nội dung được dùng cho tìm kiếm, trả lời AI hay huấn luyện AI. MCP (Model Context Protocol) là chuẩn để trợ lý AI gọi các công cụ của website, còn server card là “danh thiếp” của nó. WebMCP cho trình duyệt AI dùng các công cụ do trang đăng ký, ví dụ tìm kiếm, thay vì đoán nút bấm. API catalog (RFC 9727) là danh mục máy đọc được về dữ liệu công khai của site.

OAuth, OpenAPI và header Link là gì?

OAuth là cách chuẩn để một chương trình chứng minh danh tính và xin quyền hành động thay cho ai đó; “OAuth discovery” là trang công khai giải thích cách làm việc này. OpenAPI là bản mô tả máy đọc được về dữ liệu công khai của website và các yêu cầu nó chấp nhận. Header Link là thông tin ẩn gửi kèm trang, chỉ tới các tài nguyên hữu ích như bản mô tả đó.

Đây là những gì site đang công bố, và cái nào cũng có thứ thật đứng sau:

• Tệp robots.txt có Content Signal cho phép tìm kiếm, trả lời AI và huấn luyện AI, kèm sitemap.
• Header Link ở trang chủ trỏ tới mô tả API và danh mục API.
• Một API catalog công khai, bản mô tả OpenAPI cho API công khai chỉ đọc, và một tệp liệt kê tài nguyên cho agent.
• Các tài liệu khám phá đăng nhập theo chuẩn và tệp auth.md mô tả cách một agent đăng nhập.
• Một endpoint MCP thật với bốn công cụ chỉ đọc, kèm server card.
• Ba tệp Agent Skills (đặt hoa, theo dõi đơn, xác thực).
• Một A2A Agent Card, hồ sơ giúp một AI agent tìm và trò chuyện với agent khác. Công cụ quét đọc đây là card hợp lệ, phiên bản 1.0.0, có 4 skill và 2 interface.
• Sáu công cụ WebMCP ngay trong trang: tìm sản phẩm, xem một sản phẩm, liệt kê danh mục, thêm vào giỏ, xem giỏ và theo dõi đơn. Thêm vào giỏ không tạo đơn hàng.
• Các bản ghi DNS cho agent biết các điểm kết nối nằm ở đâu.
• Markdown cho agent: khi một bot xin text/markdown, trang chủ trả về bản văn bản gọn. Việc này đến từ một thiết lập cấp zone của Cloudflare là Markdown for Agents, không phải từ mã của mình.

Mở ảnh kích thước đầy đủ ↗

Mục Agentic Browsing của báo cáo bản điện thoại. Ba kiểm tra đạt, bốn kiểm tra không áp dụng, trong đó có WebMCP và llms.txt. Lighthouse ghi chú mục này còn đang phát triển và có thể thay đổi.

Có một chi tiết nên biết: Lighthouse đánh dấu các kiểm tra WebMCP là “không áp dụng” trong lần chạy này, trong khi công cụ quét độ sẵn sàng cho agent phát hiện 6 công cụ WebMCP. Hai công cụ kiểm tra những thứ khác nhau.

Nguyên tắc mình theo: chỉ công bố những gì site thật sự có. Ngày 28/8, lần làm đầu tiên cố tình bỏ qua các tệp đăng nhập, MCP và WebMCP vì các tính năng đó chưa tồn tại. Chỉ vài giờ sau, một công cụ quét làm lộ khoảng trống, và từng mảnh còn thiếu được xây thành một tính năng nhỏ có thật, kèm bài test sẽ báo lỗi nếu có tài liệu trỏ vào hư không. Đến tháng 10, bài kiểm tra mới của Lighthouse cho 2/3 vì tệp ai-catalog.json dùng những trường mà schema không cho phép. Mình sửa tệp, thêm bài test dùng chính schema của Lighthouse, và mục này lên 3/3.

Những gì mình không làm, do cố ý hoặc do lựa chọn:

• Không có tệp llms.txt. Địa chỉ đó hiện trả về 404 và mình không tuyên bố là có. Lighthouse cũng ghi kiểm tra llms.txt là không áp dụng.
• Không có giao thức thanh toán cho agent. Đây là tiệm hoa không nhận thanh toán thẻ qua agent, nên công cụ đánh dấu các mục này là tùy chọn và không tính điểm.
• Không ký yêu cầu bằng Web Bot Auth; công cụ đánh dấu mục này là không áp dụng và không tính điểm.

Mở ảnh kích thước đầy đủ ↗

Các kiểm tra khám phá API, Auth, MCP và Skill trong lần quét lại. Cả chín kiểm tra đều đạt, kể cả A2A Agent Card từng không đạt ở lần quét trước.

SEO, GEO và AEO

Dữ liệu có cấu trúc, sitemap, chuyển hướng và DNS là gì?

Dữ liệu có cấu trúc (JSON-LD theo chuẩn schema.org) là các nhãn ẩn trong trang, báo cho Google biết “đây là sản phẩm, giá thế này, shop mở cửa từ 07:00 đến 20:00”. Nhờ đó trang có thể hiện kết quả nổi bật như sao đánh giá, giá hoặc câu hỏi thường gặp ngay trong kết quả tìm kiếm. Sitemap là danh sách toàn bộ trang cho Google, kèm ngày chỉnh sửa gần nhất. Chuyển hướng đưa khách từ địa chỉ cũ sang địa chỉ mới: 301 là đã chuyển vĩnh viễn, 410 là đã xóa hẳn, 404 là không tìm thấy. DNS là danh bạ của internet, đổi một tên như hoatuoidanangnhanhi.com thành địa chỉ máy chủ.

Phần lớn công việc ở đây là dọn dẹp ít hào nhoáng nhưng có lợi cho người dùng, Google và công cụ AI cùng lúc:

• Dữ liệu có cấu trúc nói rõ trang là gì: doanh nghiệp hoa, sản phẩm kèm thông tin giao hàng và đổi trả, bộ sưu tập, bài blog và khối câu hỏi thường gặp. Xem hướng dẫn dữ liệu có cấu trúc của Google.
• Ngày “chỉnh sửa lần cuối” thật trong sitemap, lấy từ lịch sử của từng trang thay vì ghi “hôm nay”.
• Tồn đọng 551 địa chỉ mà Search Console báo không tìm thấy đã được xử lý bằng chuyển hướng cho trang đã dời và phản hồi “đã xóa hẳn” cho trang cố ý gỡ bỏ.
• Bài viết trùng lặp hoặc theo khuôn mẫu được gộp lại. Đánh giá sao do mình tự dựng đã bị gỡ, và đánh giá thật được đưa lại khi có sự đồng ý của chủ shop.
• Mỗi trang một địa chỉ chính, và thông tin shop thống nhất ở mọi nơi: địa chỉ, số điện thoại và giờ mở cửa khớp với Google Business Profile.

Mình không tuyên bố lượng truy cập đã nhiều hơn. Mình không có số liệu tìm kiếm trước và sau nào dám đứng ra bảo đảm, và lúc đó Search Console cho thấy lượt nhấp 7 ngày ngày 2/9 thấp hơn 43%. Nhanh và dễ đọc là nền móng, không phải lời hứa về thứ hạng.

Những chỗ đã đi sai

• 100 trên điện thoại không ổn định. Trước vòng sửa cuối cùng, cùng một mã nguồn nhưng trang chủ đạt 97, 98 rồi 90 trong các lần chạy liên tiếp.
• Một thiết lập miễn phí làm mất 16 điểm SEO. Hồi tháng 5, Cloudflare tự thêm dòng Content-Signal vào robots.txt, và trình kiểm tra của Lighthouse coi đó là quy tắc không xác định, kéo SEO từ 100 xuống 84. Ba tháng sau các công cụ đã hiểu dòng này, và giờ mình công bố dòng của riêng mình. Chuẩn thay đổi ngay dưới chân bạn.
• Tối ưu quá tay làm ảnh bị mờ. Sau khi nén mạnh, ảnh bài viết nhìn mềm và nhoè, còn một số ảnh sản phẩm mất một phần chiều rộng vì giá trị sizes sai. Ngày 2/10 mình đo lại và chọn ảnh sắc nét hơn thay vì file nhỏ nhất.
• CSS quan trọng làm chữ đổi sang màu tối. CSS inline có ưu tiên cao hơn quy tắc của framework và biến chữ trắng thành chữ tối ở menu và chân trang.
• Một bản ghi DNS sai làm hỏng www. Địa chỉ www trả lỗi ở mọi đường dẫn cho đến khi bản ghi được sửa đúng.
• Sự cố thanh toán khiến deploy ngừng khoảng ba tuần, từ 11 đến 30/9. Việc chuyển sang một đường deploy thứ hai đang được thực hiện.

Bài học

1. Đo từ chỗ người đo đang đứng. PageSpeed chạm vào một trung tâm dữ liệu còn nguội, nên điểm có thể lên xuống mà mã không đổi gì.
2. Một dòng CSS có thể làm điểm về 0. Hãy test trang thật, đừng chỉ tin vào cái mình thấy ổn.
3. Hãy thử bác bỏ giả thuyết mình ưa thích trước. Sáu lần chạy cho thấy ảnh hero không phải vấn đề; HTML kết thúc muộn mới là vấn đề.
4. Công tắc trong bảng điều khiển là một phần của hệ thống. Hãy ghi lại và làm cho chúng chạy lại được.
5. Sửa nguyên nhân chung trước khi sửa từng trang. Một chất lượng ảnh mặc định bị thiếu và một logo ẩn bị đặt ưu tiên sai có giá trị hơn mọi chỉnh sửa lẻ.
6. Đếm điểm ảnh, đừng đếm ý định. Hãy cắt ảnh theo đúng khung nó lấp đầy.
7. Sửa tận nguồn nội dung, không chỉ máy chủ. Các bài viết dùng ảnh Markdown thuần thì chậm; quy trình giờ đã xử lý chúng.
8. Tối ưu quá tay sẽ nhìn thấy được. Hãy để con người cân đối giữa dung lượng và độ sắc nét.
9. Metadata trung thực hơn một dấu tích xanh. Chỉ công bố thứ đang có, và test để chắc chắn là có.
10. Mỗi lần sửa nên có một bài test bảo vệ, vì lỗi nào cũng từng xảy ra một lần.
11. 100 là mục tiêu có nhiễu. Hãy nhắm tới biên an toàn và nói rõ điều đó.

Tiếp theo

Việc còn lại: thu thập dữ liệu người dùng thật, vì hiện PageSpeed hiện “No Data”, giữ điểm số ổn định khi shop và các chuẩn thay đổi, cân nhắc xem tệp llms.txt có đáng công bố không, và chuyển deploy sang đường dự phòng bền hơn. Mục tiêu khó hơn là giữ 100 ổn định ở mọi lần chạy trên điện thoại, không chỉ lần trong báo cáo này.

Nếu bạn muốn một danh sách ngắn để sao chép: đo mọi trang theo lịch, kiểm tra xem HTML của bạn có thật sự được cache không, đặt kích thước ảnh theo đúng khung, tìm những script không cần thiết, cho mỗi trang một địa chỉ rõ ràng, và chỉ công bố tệp cho agent khi tính năng đó có thật.

Nguồn dùng trong bài

Báo cáo PageSpeed Insights và lần quét Is Your Site Agent-Ready? ở trên là số liệu chính thức cho điểm cuối cùng. Các con số trong lịch sử dự án lấy từ ghi chép issue và thay đổi của chính shop, vốn ở chế độ riêng tư.