Hiện trạng website Đà Nẵng 2026: 96% trượt tốc độ tải

#Tôi chọn mẫu và đo như thế nào (methodology công khai)

Tôi nghĩ phần này quan trọng hơn cả những con số phía dưới — vì một báo cáo không nói rõ cách làm thì con số nào cũng đáng ngờ.

Chọn danh sách 103 site. Tôi dùng web search với nhiều biến thể truy vấn cho từng ngành (ví dụ: "khách sạn đà nẵng" website, spa đà nẵng đặt lịch...), bổ sung từ các listing du lịch/hiệp hội ngành, rồi verify thủ công từng URL: site còn sống, đúng là doanh nghiệp tại Đà Nẵng, đúng ngành đang xét. Tiêu chí loại khỏi danh sách:

• Không có website riêng (chỉ hoạt động qua Facebook/Instagram/Shopee).
• Dùng subdomain nền tảng dùng chung (.wixsite.com, .business.site, .blogspot.com...).
• Chuỗi/tập đoàn quốc gia hoặc quốc tế (site do trụ sở chính vận hành, không phản ánh hiện trạng SME local).
• Site đã chết hoặc redirect sang domain khác ngành.
• Trùng chủ sở hữu — một doanh nghiệp có nhiều domain thì chỉ lấy một.

Quét dữ liệu. 103 site được đưa vào PageSpeed Insights API v5, chạy ở chế độ mobile, mỗi site đo một lần vào tháng 7/2026. 4 site lỗi khi quét (chặn bot, timeout, hoặc lỗi server) bị loại khỏi số liệu tổng hợp, còn lại n = 99 site dùng cho toàn bộ phân tích trong bài.

Ba điều cần hiểu đúng trước khi đọc số liệu:

1. Đây là dữ liệu lab (Lighthouse mô phỏng), đo tại một thời điểm — không phải dữ liệu hành vi người dùng thật theo thời gian (field data). Một site có thể nhanh/chậm hơn ở lần đo khác tuỳ điều kiện mạng mô phỏng.
2. Tôi dùng TBT (Total Blocking Time) làm proxy cho khả năng tương tác — đây không phải INP (Interaction to Next Paint) theo dữ liệu người dùng thật. INP cần dữ liệu CrUX thực tế, vốn không có sẵn qua PSI lab run cho các site traffic thấp.
3. Ngưỡng tôi dùng để tính "đạt/trượt" là ngưỡng chuẩn Google công bố cho Core Web Vitals: LCP ≤ 2.500ms · CLS ≤ 0,1 · TBT ≤ 200ms.

Tôi không so sánh hơn kém giữa hai site cụ thể nào trong bài — chỉ nói về phân bố và nhóm ngành. Tên/domain các site trong mẫu không xuất hiện ở đây. Cỡ mẫu từng ngành nhỏ (13–24 site), nên tỷ lệ phần trăm theo ngành nên đọc như xu hướng, không phải con số thống kê chính xác.

#Số liệu tổng: 99 website Đà Nẵng đang đứng ở đâu

Vài điểm đáng chú ý từ bảng trên:

Tốc độ tải là nút thắt lớn nhất. LCP trung vị 11,9 giây — gấp gần 5 lần ngưỡng 2,5 giây. Ở nhóm 25% chậm nhất (p75), con số này vọt lên 22,2 giây. Khi xét cả ba tiêu chí CWV cùng lúc, tỷ lệ đạt toàn phần chỉ còn 3% — cho thấy đây không phải lỗi đơn lẻ mà là nhiều vấn đề kỹ thuật cộng dồn trên cùng một site.

Ảnh chưa tối ưu là nguyên nhân chính khiến trang nặng. Trang trung vị nặng 7,07 MB, trong đó ảnh chiếm khoảng 79%. Mức phổ biến được khuyến nghị cho một trang di động tải nhanh là dưới 2 MB — phần lớn site trong mẫu vượt xa mốc này.

Hạ tầng JSON-LD đã có nhưng dùng sai loại. 59,6% site đã nhúng ít nhất một dạng dữ liệu có cấu trúc, nhưng chỉ 3% khai báo đúng LocalBusiness — loại schema giúp công cụ tìm kiếm và các trợ lý AI (Google AI Overview, ChatGPT search...) hiểu đây là một doanh nghiệp địa phương cụ thể. Nói cách khác: hạ tầng kỹ thuật phần lớn đã sẵn, chỉ chưa được dùng đúng mục đích.

Gần một nửa site mắc lỗi H1 — không có thẻ H1 nào, hoặc có nhiều hơn một H1 trên trang. Đây là lỗi nền tảng ảnh hưởng đến cách công cụ tìm kiếm xác định chủ đề chính của trang.

#Mỗi ngành trượt chuẩn theo một cách riêng

Điều rõ nhất khi tách số liệu theo ngành: không có "bệnh chung của website Đà Nẵng". Cùng trượt Core Web Vitals, nhưng mỗi ngành trượt vì một lý do khác — nên toa thuốc chép của ngành khác gần như chắc chắn sai chỗ.

Sáu phần dưới đây đi theo cùng một khung: triệu chứng (số đo được) → chẩn đoán ở mức hệ thống → hướng xử lý.

#Vì sao website khách sạn Đà Nẵng chậm và nặng nhất mẫu?

Vì gallery ảnh được đưa thẳng ảnh gốc lên web: trang khách sạn trung vị nặng 14,2 MB, riêng ảnh khoảng 8,9 MB (~63%), LCP trung vị 16,8 giây (p75: 24,2 giây). 0/16 site đạt ngưỡng LCP, 0/16 đạt cả 3 Core Web Vitals; chỉ 37,5% đạt ngưỡng TBT, điểm Performance trung vị 46/100. Điểm sáng duy nhất: 100% đã chạy HTTPS.

#Gallery ảnh gốc là lỗi quy trình, không phải lỗi người làm nội dung

Khách sạn có lý do chính đáng để cần nhiều ảnh đẹp — phòng, hồ bơi, buffet, view biển — và ảnh thường về từ photographer ở độ phân giải in ấn. Thiếu đúng một bước giữa "ảnh đẹp" và "ảnh trên web": nén và resize theo kích thước hiển thị. Hệ quả là trình duyệt tải ảnh 4000px để hiện trong khung 400px; ở nhóm 25% nặng nhất, một trang vượt 26,9 MB. Hướng xử lý: chuyển ảnh sang WebP/AVIF, resize đúng khung, lazy-load ảnh dưới màn hình đầu — làm một lần ở tầng CMS (tự nén khi upload) thay vì sửa tay từng ảnh mãi mãi. Chi tiết ở trang tối ưu ảnh chuẩn SEO.

#Mỗi giây chờ đẩy booking trực tiếp sang OTA

Phần tử LCP của website khách sạn gần như luôn là ảnh hero hoặc slider đầu trang — chính những ảnh chưa nén ở trên, cộng slider tải 5–7 ảnh cùng lúc dù khách chỉ thấy tấm đầu. Khách tra cứu trên điện thoại, nhiều khi qua 4G khi đang di chuyển; mỗi giây chờ là một cơ hội để họ quay lại tab Booking/Agoda đang mở sẵn. Website chậm không chỉ mất traffic — nó đẩy booking trực tiếp (không mất hoa hồng) sang kênh phải trả hoa hồng. Hướng xử lý: nén riêng và preload ảnh LCP, slider đầu trang về 1 ảnh tĩnh, mục tiêu thực tế trước là LCP dưới 4 giây rồi mới tối ưu tiếp về 2,5.

#Widget chồng widget và thực thể vô danh

TBT chỉ đạt 37,5% vì script bên thứ ba tích tụ theo năm tháng: booking engine, live chat, popup, pixel, bản đồ — từng quyết định đúng, tổng thể sai. Cùng lúc, 0/16 site khai báo Hotel/LocalBusiness (chỉ 37,5% có JSON-LD bất kỳ): ngành phụ thuộc "được tìm thấy" nhiều nhất lại khai báo thực thể kém nhất, nên khi khách hỏi AI "khách sạn gần biển Mỹ Khê có hồ bơi", câu trả lời dẫn nguồn OTA. Hướng xử lý: kiểm kê và defer script không cần chạy ngay (giữ booking engine nhưng tải sau khi trang tương tác được); thêm JSON-LD Hotel với tên, địa chỉ, toạ độ, hạng sao, tiện ích. 43,8% site còn lỗi H1, 25% thiếu meta description — một buổi rà soát là đủ.

Tự kiểm riêng cho khách sạn: View Source (Ctrl+U), tìm <script src= và đếm số domain bên thứ ba — cái nào 6 tháng qua không dùng?

#Vì sao website spa & clinic nhẹ mà vẫn chậm?

Vì thủ phạm là JavaScript chứ không phải ảnh: trang spa trung vị chỉ 6 MB — nhẹ hơn mặt bằng chung — nhưng LCP trung vị 13,7 giây (p75: 27,4 giây, tệ thứ nhì mẫu), 0/14 đạt cả 3 Core Web Vitals, và tỷ lệ đạt TBT thấp nhất 6 ngành: 35,7%.

#Công cụ chuyển đổi chất đống đến mức giết chính chuyển đổi

Spa sống bằng chuyển đổi tức thời — xem bảng giá xong là muốn đặt lịch. Vì thế site spa tích nhiều công cụ tương tác: widget đặt lịch nhúng, chat Zalo + Messenger (thường cả hai), popup khuyến mãi, pixel quảng cáo. Mỗi thứ là một script chạy ngay khi tải trang, và tất cả tranh main thread với chính cái nút "Đặt lịch" chúng được sinh ra để phục vụ. Hướng xử lý: giữ một kênh chat chính thay vì hai-ba, defer chat/pixel/popup tới sau tương tác đầu tiên, và để nút đặt lịch là HTML thuần trỏ tới form/số điện thoại — không phụ thuộc widget nặng mới bấm được.

#Trang nhẹ mà chậm: sắp lại thứ tự tải, không cần nén lại kho ảnh

Khi trang nặng mà chậm (như khách sạn), nén ảnh là xong việc lớn. Khi trang nhẹ mà vẫn chậm, thủ phạm là chuỗi tải bị chặn: CSS/JS render-blocking xếp trước nội dung, slider khởi tạo bằng JavaScript nên ảnh hero phải đợi script, font tải chậm giữ trắng chữ. Với người dùng, 13 giây màn hình trắng trên trang 6 MB và trên trang 14 MB tệ như nhau; với người sửa, đây là tin tốt. Hướng xử lý: preload phần tử LCP (thường là ảnh banner dịch vụ), slider đầu trang về 1 ảnh tĩnh, defer CSS/JS không critical — trang 6 MB hoàn toàn có thể xuống dưới 4 giây chỉ bằng sắp xếp lại.

#Nền móng lỏng ở ngành cần niềm tin nhất

57,1% site spa lỗi H1 (cao thứ hai mẫu); 71,4% có JSON-LD nhưng chỉ 7,1% (1/14) khai báo LocalBusiness — như in danh thiếp mà quên ghi địa chỉ, ở đúng ngành hưởng lợi từ tìm kiếm "spa gần đây" nhiều nhất. Và 1/14 site chưa HTTPS, trong khi form đặt lịch spa/clinic nhận tên, số điện thoại, đôi khi cả tình trạng da hay nhu cầu điều trị. Hướng xử lý: mỗi trang đúng 1 H1 nêu dịch vụ + địa phương; schema BeautySalon/DaySpa cho spa, MedicalClinic cho clinic; bật SSL và redirect toàn bộ HTTP → HTTPS — việc của một buổi chiều.

Tự kiểm riêng cho spa: reload trang trên điện thoại rồi bấm ngay nút đặt lịch — có phản hồi tức thì không? Có bao nhiêu bong bóng chat/popup hiện lên trong 5 giây đầu?

#Vì sao website tour du lịch có nội dung tốt mà vẫn trượt Core Web Vitals?

Vì phần "nội dung máy đọc được" làm tốt nhưng phần thân cõng nội dung đó quá tải: lỗi H1 chỉ 31,3% (thấp nhất mẫu), 87,5% có meta description — nhưng 0/16 đạt cả 3 Core Web Vitals, ảnh chiếm ~80% dung lượng trang (tỷ trọng cao nhất mẫu, 9,0 MB/11,3 MB), tỷ lệ đạt CLS thấp nhất mẫu (56,3%), LCP trung vị 11,1 giây.

#Ảnh rải khắp trang — trang danh sách tour cần xử lý trước

Khác khách sạn, ảnh tour không dồn vào một gallery mà rải khắp nơi: trang danh sách hàng chục card mỗi card một ảnh, trang chi tiết là album lịch trình từng ngày, ảnh món ăn, ảnh review. Ảnh đi thẳng từ điện thoại hướng dẫn viên/marketing lên CMS, không có bước nén ở giữa. Hướng xử lý: ưu tiên trang danh sách tour (nhiều ảnh nhất, là cửa vào chính) — thumbnail card chỉ cần vài chục KB, lazy-load từ card thứ 4–5; sau đó mới đến album trang chi tiết.

#Layout giật nhất mẫu — chỉ số duy nhất tour đứng cuối cả 6 ngành

Hai đặc thù cộng hưởng: rất nhiều ảnh mà markup không khai báo kích thước (ảnh tải tới đâu đẩy chữ xuống tới đó), cộng banner khuyến mãi/hotline và slider chèn muộn bằng JavaScript. Người mua tour mở nhiều tab so giá, đọc kỹ lịch trình — mỗi cú giật là một lần mất dòng đang đọc. Hướng xử lý: khai báo width/height (hoặc aspect-ratio) cho toàn bộ ảnh, dựng sẵn khung giữ chỗ cho banner — nhóm sửa rẻ nhất trong các bệnh Core Web Vitals.

#Cạnh tranh với sàn tour bằng một thực thể vô danh — và cái bẫy "đã làm SEO rồi"

62,5% site tour có JSON-LD nhưng 0% khai báo TravelAgency/LocalBusiness, không site nào dùng TouristTrip — trong khi các sàn (Klook, Traveloka, GetYourGuide...) khai báo dữ liệu tour rất kỹ và được trích khi khách hỏi "tour Bà Nà 1 ngày giá bao nhiêu". Cái bẫy của ngành: vì on-page đã tốt nhất nhì mẫu, nhiều chủ site tưởng mọi thứ đã ổn, trong khi phần đang chảy máu là kỹ thuật. Hướng xử lý: giữ nguyên chất lượng nội dung, dồn ngân sách theo thứ tự ảnh → CLS → LCP → schema.

Tự kiểm riêng cho tour: mở một trang tour, Ctrl+U tìm <img — các thẻ ảnh có width/height không? Thiếu là nguồn CLS.

#Vì sao website dịch vụ chuyên nghiệp SEO tốt nhất mà vẫn 0% đạt Core Web Vitals?

Vì cả ngành trượt gần như ở đúng một chỉ số: LCP, chỉ 4,2% đạt ngưỡng. Ngành này (kế toán, luật, IT, agency, tư vấn) đứng nhất mẫu ở 5 chỉ số — meta description 95,8%, JSON-LD 79,2%, LocalBusiness 8,3%, CLS 87,5%, trang nhẹ nhất (4,6 MB) — vậy mà 0/24 đạt cả 3 Core Web Vitals: 23/24 site trượt ngưỡng LCP, site duy nhất đạt LCP lại trượt CLS. LCP trung vị 9,4 giây.

#Cùng chậm nhưng hai thủ phạm — phải phân loại trước khi sửa

Soi dữ liệu thô, ngành tách làm hai nhóm rõ rệt. Khoảng chục site chậm theo kiểu quen thuộc: ảnh chiếm 80–95% trang, có site trên 20 MB — toa nén ảnh như khách sạn. Một nhóm tương đương chậm theo kiểu khó hiểu hơn: trang dưới 3,5 MB, ảnh có khi chỉ 5–20%, TBT thấp, mà LCP vẫn 5–20 giây. Thủ phạm nhóm này nằm ở chuỗi tải và hạ tầng: CSS/JS chặn hiển thị, font tải chậm, và — điểm ít ai kiểm tra — hosting phản hồi chậm ngay từ byte đầu tiên. Nhiều công ty đặt website ở gói hosting rẻ nhất từ ngày thành lập và không ai xem lại; trang 3 MB trên server phản hồi 3–4 giây thì tối ưu ảnh đến mấy cũng vô ích. Khác spa ở chỗ nhóm này gần như không có widget — trang "sạch" mà vẫn chậm, nên phải nghi từ tầng móng. Hướng xử lý: DevTools → Network → reload; nặng ảnh → nén ảnh; nhẹ mà chậm → nhìn dòng document đầu tiên, TTFB trên 1 giây là chuyện hosting/cache, cần bật cache/CDN hoặc đổi gói trước khi đụng giao diện.

#Schema nhiều nhất mẫu nhưng do plugin tự sinh

79,2% có JSON-LD, nhưng phần lớn là bộ Organization + WebSite + WebPage + ImageObject — dấu vân tay của plugin SEO; chỉ 6/24 site khai báo subtype đúng ngành (LegalService, AccountingService, AdvertisingAgency...). Bộ schema plugin nói với Google và AI rằng "đây là một website" — điều chúng đã biết; thứ chưa được nói là công ty làm gì, phục vụ khu vực nào, chuyên gia đứng tên là ai. Hướng xử lý: nâng schema lên subtype đúng ngành kèm khu vực phục vụ, thêm Person cho chuyên gia đứng tên với chức danh và chứng chỉ.

#Cái bẫy: báo cáo SEO toàn tick xanh

Đây là ngành hiểu SEO nhất mẫu — nhiều site chính là agency, công ty IT — nên mọi thứ plugin hay checklist làm được đều đã làm. Nhưng ranh giới của công cụ cũng là ranh giới của báo cáo: tốc độ hiển thị không nằm trong danh sách tick. Chủ site mở báo cáo thấy toàn màu xanh, trong khi khách đợi 9 giây mới thấy trang. Ở vai Delivery Manager, tôi gọi đây là lỗi chọn thước đo: đo thứ dễ đo thay vì thứ khách cảm nhận. Hướng xử lý: thêm đúng một chỉ số vào thói quen — LCP mobile từ PageSpeed Insights, đo mỗi tháng một lần.

Tự kiểm riêng cho dịch vụ chuyên nghiệp: trong tab Network, click dòng document đầu tiên — TTFB/Waiting trên 1 giây nghĩa là hosting/cache đang là điểm nghẽn.

#Vì sao website bất động sản có trung vị nhanh nhất mà vẫn nhiều site rất chậm?

Vì ngành này phân hoá mạnh nhất mẫu: LCP trung vị 7,2 giây — nhanh nhất 6 ngành — nhưng p75 là 24,3 giây, khoảng cách hơn 3 lần (khách sạn chậm đều, trung vị và p75 cách nhau chưa tới 1,5 lần). Đạt cả 3 Core Web Vitals 7,7% — tốt thứ nhì mẫu — nhưng ngành này cũng giữ kỷ lục website nặng nhất toàn khảo sát, và tỷ lệ lỗi H1 cao nhất: 69,2%.

#Ngành "hai tốc độ" — đừng benchmark với trung bình ngành

Một nửa là các sàn/môi giới làm web gần đây: landing dự án gọn, ít trang, tải nhanh — kéo trung vị xuống đẹp. Nửa kia là site lâu năm tích tụ: hàng trăm tin đăng, mỗi tin một album, theme cũ chồng plugin — tạo cái đuôi 24 giây. Trong một ngành phân hoá thế này, trung bình không đại diện cho ai cả; site của bạn hoặc thuộc nhóm 7 giây, hoặc nhóm 24 giây, và hai nhóm cần hai lộ trình khác nhau. Nhóm nhanh: 7,2 giây vẫn gấp gần 3 lần chuẩn, tối ưu tiếp ảnh hero và preload là trong tầm tay. Nhóm chậm: đừng vá lẻ — dọn kho ảnh, bỏ plugin thừa, cân nhắc dựng lại template trang dự án.

#Trang dự án đổ nguyên album gốc — ~230 MB cho một lần tải

Website nặng nhất trong 99 site là một site bất động sản: ~230 MB cho một lần tải trang, 99% là ảnh — gấp hơn 3 lần site nặng thứ nhì (một khách sạn, ~70 MB). Chủ đầu tư gửi bộ media dự án — phối cảnh 4K, mặt bằng từng tầng, thư viện tiện ích — và toàn bộ lên trang nguyên gốc. Ảnh rải theo chiều dọc trang dự án rất dài, nên trang "có vẻ" xem được ngay phần đầu, trong khi điện thoại vẫn âm thầm tải hàng chục MB phía dưới. Hướng xử lý: nén + resize tự động mọi ảnh upload; lazy-load toàn bộ ảnh dưới màn hình đầu (thay đổi ăn tiền nhất với trang dự án dài); album đầy đủ chuyển thành lightbox/tab tải theo nhu cầu.

#Lỗi H1 bị nhân bản và chân dung số thiếu tin cậy

9/13 site lỗi H1, và cơ chế nhân bản làm ngành này nặng hơn ngành khác: mỗi dự án là một trang copy từ cùng một khuôn — khuôn sai một chỗ thì vài chục trang dự án sai đúng chỗ đó. Sửa ở template, mọi trang nhân bản sau tự đúng. Cùng lúc, 53,8% có JSON-LD nhưng 0% khai báo LocalBusiness, chỉ 1/13 dùng đúng RealEstateAgent; 1/13 site vẫn chạy HTTP — ở ngành mà khách để lại số điện thoại cho giao dịch lớn nhất đời họ, cạnh tranh trực diện với các sàn lớn trên cả kết quả tìm kiếm lẫn câu trả lời AI. Hướng xử lý: RealEstateAgent với tên, địa chỉ, khu vực hoạt động; trang dự án cân nhắc Residence/ApartmentComplex; bật SSL.

Tự kiểm riêng cho bất động sản: đo PageSpeed Insights cả trang chủ lẫn một trang dự án nhiều ảnh — nhiều site trang chủ nhanh nhưng trang dự án, nơi khách thật sự quyết định, chậm gấp ba.

#Vì sao website F&B khoẻ nhất về kỹ thuật mà vẫn vô hình với máy tìm kiếm?

Vì phần "được máy đọc" mỏng nhất mẫu: F&B dẫn đầu về kỹ thuật — đạt cả 3 Core Web Vitals 12,5%, TBT đạt 87,5%, điểm Performance trung vị 64/100, đều cao nhất mẫu — nhưng 50% site không có meta description (thấp nhất mẫu), chỉ 43,8% có JSON-LD, 0% khai báo LocalBusiness và chỉ 1/16 dùng Restaurant. Cơ thể khoẻ, hồ sơ trắng — ảnh ngược của dịch vụ chuyên nghiệp.

#Hồ sơ trắng ở đúng ngành sống bằng tìm kiếm địa phương

"Quán hải sản gần đây", "bún chả cá Đà Nẵng ngon" — và ngày càng nhiều câu hỏi đi thẳng vào AI. Nhưng mọi thông tin máy cần (bán món gì, ở đâu, giờ nào, tầm giá) đều không được khai báo ở dạng đọc được. Theo tôi quan sát, chủ quán dồn công sức số vào Google Maps, Facebook và app giao đồ ăn — nơi thấy khách ngay — còn website làm một lần cho "có mặt tiền" rồi để đó. Khi AI trả lời "quán ngon Đà Nẵng", nguồn được trích là nền tảng review chứ không phải tiếng nói chính chủ của quán. Hướng xử lý: meta description cho các trang chính (tên quán + món chủ lực + khu vực), mỗi trang đúng 1 H1 (lỗi H1 hiện 56,3%), schema Restaurant với tên, địa chỉ, giờ mở cửa, khoảng giá.

#Cái đuôi chậm nhất mẫu và menu dạng ảnh

p75 LCP 27,7 giây — tệ nhất khảo sát; trong dữ liệu thô có một site F&B đo được LCP hơn 100 giây trên trang ~40 MB với 96% là ảnh. Ảnh món chụp điện thoại lên nguyên gốc, mỗi món 3–5 MB; vấn đề chưa bao giờ là số ảnh mà là cỡ ảnh — tấm ảnh món nén đúng còn 100–200 KB trông không khác trên màn hình điện thoại. Ở nhiều site, chính tờ menu cũng là ảnh: nặng cho khách (phải zoom từng góc), mù với Google (không đọc được món và giá), và vô hình với AI khi khách hỏi "quán nào có bún chả cá dưới 50 nghìn". Hướng xử lý: nén ảnh món, trang chủ chỉ giữ vài ảnh đại diện; chuyển menu thành HTML thật (tên món + giá + mô tả), kèm schema Menu/MenuItem nếu làm được.

#Điểm sáng 5 ngành kia nên học: trang ít JavaScript

87,5% site F&B đạt ngưỡng TBT, nhiều site gần bằng 0 — không phải vì ngành này giỏi kỹ thuật hơn mà vì ít tham vọng tính năng: không widget đặt lịch, không popup chồng popup, chỉ HTML, ảnh và một nút gọi điện/chỉ đường. Đó chính là công thức spa (TBT đạt 35,7%) và khách sạn (37,5%) đang phải quay về: mỗi script bên thứ ba phải tự chứng minh giá trị, mặc định là không có mặt. Khi thêm bất kỳ công cụ mới nào — chat, popup, đặt bàn — đo TBT trước và sau; lợi thế này mất rất nhanh và giành lại rất chậm.

Tự kiểm riêng cho F&B: bôi đen thử tên món trên trang menu — bôi đen được là HTML thật; không bôi đen được là ảnh, và máy cũng "đọc" y như vậy.

#Nhóm dẫn đầu có gì khác

Tôi không nêu tên site cụ thể trong bài này (lý do: một site được khen hôm nay có thể xuống cấp sau này, và tôi không muốn bài viết vô tình trở thành công cụ PR cho ai). Nhưng nhìn vào đặc điểm chung của nhóm điểm Performance cao nhất trong mẫu, có vài pattern rõ:

• Nhóm này tập trung chủ yếu ở hai ngành dịch vụ chuyên nghiệp (kế toán, IT, agency) và F&B. Đáng chú ý là hai ngành này đứng ở hai đầu về khai báo dữ liệu có cấu trúc — JSON-LD 79,2% so với 43,8% — tức tốc độ và việc khai báo cho máy là hai việc tách biệt, làm tốt việc này không kéo theo việc kia.
• LCP của nhóm này rất thấp — nhiều site dưới 3 giây, có site dưới 1 giây — trái ngược với trung vị toàn mẫu gần 12 giây.
• Chỉ có 1 site khách sạn và 1 site spa lọt vào nhóm 15 điểm cao nhất toàn mẫu — khớp với phần phân tích theo ngành ở trên: các ngành thiên về hình ảnh (khách sạn, tour, spa) có tỷ lệ đạt CWV thấp nhất.

Ba bài học xuyên suốt cả 6 ngành, nếu chỉ được nhớ ba điều:

1. Ảnh là thủ phạm số một của tốc độ — ảnh chiếm khoảng 79% dung lượng trang trung vị toàn mẫu, và quá nửa ở 4/6 ngành (khách sạn, tour, bất động sản, F&B); nén và lazy-load ảnh là khoản đầu tư lãi nhất với website SME.
2. Trang nhẹ chưa chắc nhanh — spa và một nửa ngành dịch vụ chuyên nghiệp chứng minh điều đó; thứ tự tải và hạ tầng quan trọng không kém số MB.
3. Có mặt trên web chưa phải là được máy nhìn thấy — chỉ 3% toàn mẫu khai báo LocalBusiness; khi khách hỏi AI trước khi hỏi bạn bè, hồ sơ máy đọc được là mặt tiền thứ hai.

#Tự khám website của bạn trong 5 phút

Không cần đợi ai audit, bạn có thể tự kiểm tra nhanh:

1. Đo LCP thật — vào PageSpeed Insights (công cụ chính chủ của Google, miễn phí), nhập URL, chọn tab Mobile. Nếu LCP > 2,5 giây, trang đang trượt ngưỡng chuẩn. Nhìn thêm TBT (> 200ms là trang "đơ") và CLS (> 0,1 là layout giật).
2. Phân loại thủ phạm — mở tab Network trong DevTools (F12), reload trang. Tổng dung lượng lớn và toàn ảnh → nén ảnh. Trang nhẹ mà vẫn chậm → nhìn dòng document đầu tiên: TTFB trên 1 giây là chuyện hosting/cache.
3. Đếm thẻ H1 — View Source (Ctrl+U), Ctrl+F tìm <h1. Trang chuẩn nên có đúng 1 thẻ H1 chứa chủ đề chính.
4. Kiểm tra schema đúng ngành — dán URL vào Rich Results Test của Google, xem có LocalBusiness hoặc subtype đúng ngành (Hotel, Restaurant, RealEstateAgent...) không — khác với chỉ có JSON-LD chung chung.
5. Test trên điện thoại thật — không chỉ xem trên máy tính. Phần lớn khách hàng SME của bạn đang xem qua di động.

Nếu muốn một bản tóm tắt tự động thay vì làm tay từng bước, tôi có công cụ audit website miễn phí chấm nhanh các điểm này. Với nhóm câu hỏi liên quan đến AI Search (site có được ChatGPT/AI Overview trích dẫn hay không), có thể xem thêm công cụ kiểm tra độ sẵn sàng AI.

#Phần lớn lỗi sửa được mà không cần làm lại website

Số liệu ở trên không nhắm vào một doanh nghiệp hay một agency cụ thể nào — đây là bức tranh phân bố của cả một thị trường tại một thời điểm. Phần lớn vấn đề (ảnh nặng, script thừa, thiếu schema đúng loại, lỗi H1) đều là những thứ có thể khắc phục được bằng kỹ thuật trên site hiện tại, không đòi hỏi làm lại toàn bộ website.

Với những trường hợp nền tảng đã cũ hoặc không còn kiểm soát được cấu trúc để tối ưu tiếp, việc thiết kế lại website Đà Nẵng theo hướng đúng ngay từ kiến trúc sẽ hiệu quả hơn vá lẻ từng phần. Nếu muốn đào sâu thêm về cấu trúc kỹ thuật, xem bài tái cấu trúc website ngành F&B, bất động sản theo hướng technical SEO. Đợt đo tiếp theo — nếu có — sẽ là chuyện của 2027, khi đủ thời gian để xem bức tranh này có nhúc nhích.

Nguyễn Phúc Nguyên Châu Delivery Manager 14 năm kinh nghiệm Delivery (Website, Hệ thống, AI Automation) cho thị trường Việt - Nhật