9 cách tăng tốc website bất động sản và cải thiện Core Web Vitals

Một website bất động sản có thể tải rất nhanh ở trang chủ nhưng lại trở nên nặng nề khi khách mở trang dự án: ảnh hero dung lượng lớn, hàng chục ảnh gallery, mặt bằng, video, Google Maps, Zalo, chatbot, popup, analytics và nhiều script quảng cáo cùng hoạt động.

Đó là lý do tối ưu tốc độ web BĐS không nên chỉ là cài một plugin cache rồi chạy PageSpeed Insights. Bạn cần xác định tài nguyên nào đang làm chậm nội dung chính, thao tác nào bị JavaScript chặn và phần nào thực sự cần tải ngay.

Trong bài này, Bdsweb hướng dẫn 9 cách tăng tốc theo hướng thực dụng: đo đúng → tối ưu nội dung màn hình đầu → giảm dữ liệu tải xuống → giảm xử lý phía trình duyệt → tối ưu máy chủ → theo dõi bằng dữ liệu thực tế. Nếu đang xây dựng website bất động sản chú trọng SEO và tạo lead, hiệu năng nên được thiết kế từ đầu thay vì chỉ xử lý sau khi website đã trở nên quá nặng.

Tóm tắt nhanh: nên tăng tốc web BĐS theo thứ tự nào?

Ưu tiên	Việc cần làm	Vấn đề chính giải quyết
1	Đo đúng bằng dữ liệu thực tế	Không tối ưu mù
2	Tối ưu ảnh và LCP	Màn hình đầu tải chậm
3	Lazy-load phần ngoài màn hình	Tải quá nhiều tài nguyên ban đầu
4	Giảm JavaScript và third-party	INP kém, thao tác lag
5	Cache và CDN	Server/file tĩnh phản hồi chậm
6	Tối ưu CSS, font và tài nguyên render	Render đầu trang bị chặn
7	Tối ưu hosting/backend/database	TTFB cao
8	Tối ưu module đặc thù BĐS	Map, gallery, filter, video quá nặng
9	Thiết lập performance budget và monitoring	Website chậm trở lại sau vài tháng

Website bất động sản thường chậm ở đâu?

Trước khi sửa, nên hiểu rằng một trang chậm có thể do ba lớp khác nhau.

Lớp 1: Network – tải quá nhiều dữ liệu

Ví dụ:

• Ảnh 3000–5000px;
• Video tự động tải;
• Font quá nhiều weight;
• JavaScript lớn;
• Gallery tải toàn bộ ảnh ngay từ đầu.

Lớp 2: Backend – server phản hồi chậm

Ví dụ:

• Hosting yếu;
• Database query chậm;
• Không có cache;
• API bên ngoài làm request kéo dài;
• Trang danh sách query quá nhiều bản ghi.

Lớp 3: Browser – tải xong nhưng vẫn lag

Ví dụ:

• JavaScript xử lý lâu;
• Slider nặng;
• Filter render lại DOM lớn;
• Chat/heatmap/pixel cạnh tranh main thread;
• Layout liên tục thay đổi sau khi tải.

Muốn tăng tốc hiệu quả, cần xác định trang đang chậm ở lớp nào thay vì áp dụng toàn bộ kỹ thuật cùng lúc.

Core Web Vitals hiện gồm những chỉ số nào?

Core Web Vitals hiện tập trung vào ba khía cạnh: tải nội dung, khả năng phản hồi và độ ổn định bố cục.

Chỉ số	Đo gì?	Mức “Good”
LCP	Thời gian hiển thị nội dung lớn chính	≤ 2,5 giây
INP	Khả năng phản hồi sau tương tác	≤ 200 ms
CLS	Mức dịch chuyển bố cục	≤ 0,1

Google/web.dev khuyến nghị đánh giá các ngưỡng này ở phân vị 75 của lượt truy cập, tách mobile và desktop.

Điều đó có nghĩa một lần test Lighthouse đạt điểm cao trên máy của developer chưa chứng minh rằng phần lớn khách truy cập thật đang có trải nghiệm tốt.

1. Đo đúng trước khi tối ưu: đừng chỉ nhìn một con số PageSpeed

Nếu phải chọn một việc làm đầu tiên, Bdsweb sẽ không chọn nén ảnh hay cài cache. Hãy xác định trang nào chậm, chỉ số nào kém và nguyên nhân nằm ở đâu.

Dữ liệu thực tế – Field Data

Ưu tiên xem:

• Chrome UX Report nếu URL/origin có đủ dữ liệu;
• Core Web Vitals trong Search Console;
• Real User Monitoring nếu website tự triển khai.

Field data cho biết trải nghiệm của người dùng thật với mạng, thiết bị và hành vi thật.

Dữ liệu phòng lab – Lab Data

Sử dụng:

• PageSpeed Insights;
• Lighthouse;
• Chrome DevTools Performance;
• Network waterfall.

Lab data phù hợp để tìm nguyên nhân và kiểm thử thay đổi.

Đừng test duy nhất trang chủ

Website BĐS nên chọn đại diện theo template:

• Trang chủ;
• Trang danh sách;
• Trang dự án;
• Trang tin đăng;
• Landing page;
• Bài blog.

Một trang chủ nhanh không có nhiều ý nghĩa nếu trang dự án – nơi tạo lead – lại tải rất chậm.

Google cũng nhấn mạnh rằng Core Web Vitals là một phần của page experience, nhưng việc đạt điểm tốt không bảo đảm xếp hạng cao và không nên chạy theo điểm hoàn hảo chỉ vì SEO.

2. Tối ưu ảnh và tài nguyên LCP trước tiên

Với rất nhiều website BĐS, LCP thường là:

• Ảnh Hero;
• Ảnh đại diện dự án;
• Banner lớn;
• Khối text Hero;
• Đôi khi là ảnh slider đầu tiên.

Việc đầu tiên là xác định chính xác LCP element bằng DevTools hoặc PageSpeed Insights.

Resize theo kích thước thực tế

Nếu ảnh hiển thị tối đa 1200px, không nên bắt điện thoại tải file gốc 5000px chỉ để CSS thu nhỏ.

Dùng responsive images

Ví dụ:

Trình duyệt có thể chọn file phù hợp hơn với kích thước màn hình.

Chọn định dạng ảnh phù hợp

WebP hoặc AVIF có thể giúp giảm dung lượng trong nhiều trường hợp, nhưng không nên chuyển định dạng rồi coi như công việc đã hoàn tất. Vẫn cần kiểm tra:

• Kích thước pixel;
• Quality;
• Chất lượng visual;
• Browser support của hệ thống khách hàng;
• Cách CMS tạo thumbnail.

Không đặt một giới hạn KB cứng cho mọi ảnh

Quy tắc kiểu “mọi ảnh phải dưới 200KB” không phù hợp với tất cả tình huống.

Một thumbnail card 300px và một mặt bằng cần zoom rõ chi tiết có yêu cầu chất lượng hoàn toàn khác nhau.

Mục tiêu đúng hơn là:

dùng file nhỏ nhất vẫn đáp ứng chất lượng ở kích thước hiển thị thực tế.

Phần tối ưu ảnh chuyên sâu nên tham khảo riêng tại hướng dẫn tối ưu hình ảnh cho website bất động sản.

3. Không lazy-load ảnh Hero/LCP – lazy-load phần thực sự nằm ngoài viewport

Lazy loading là một trong những kỹ thuật hữu ích nhất nhưng cũng là nơi nhiều website tối ưu sai.

Ảnh:

• Gallery phía dưới;
• Tiện ích;
• Nhà mẫu;
• Ảnh blog phía cuối trang;

rất phù hợp với:

loading="lazy"

Nhưng ảnh Hero/LCP lại cần được tải sớm.

web.dev cảnh báo không nên lazy-load ảnh LCP, vì điều này trì hoãn thời điểm trình duyệt bắt đầu tải tài nguyên quan trọng.

Ví dụ ảnh Hero

Trong trường hợp phù hợp, fetchpriority="high" có thể giúp trình duyệt ưu tiên tải ảnh LCP sớm hơn. web.dev cũng lưu ý chỉ nên ưu tiên một số rất ít tài nguyên quan trọng; nếu mọi ảnh đều được đặt ưu tiên cao thì cơ chế ưu tiên mất ý nghĩa.

Đừng giấu ảnh LCP trong JavaScript nếu không cần

Cấu trúc:

HTML → tải JS → chạy JS → JS mới tạo ảnh Hero

làm trình duyệt phát hiện tài nguyên quá muộn.

Tốt hơn, ảnh quan trọng nên có thể được browser phát hiện trực tiếp từ HTML khi kiến trúc cho phép.

4. Giảm JavaScript và script bên thứ ba để cải thiện INP

Một trang có thể tải hình ảnh khá nhanh nhưng bấm nút “Xem bảng giá” mất gần một giây mới phản hồi. Khi đó vấn đề không còn là dung lượng ảnh mà là main thread đang bận xử lý JavaScript.

Website BĐS thường tích hợp:

• Google Tag Manager;
• Google Ads;
• Meta Pixel;
• Zalo;
• Chatbot;
• Heatmap;
• Popup;
• Slider;
• Map;
• CRM tracking;
• A/B testing.

Mỗi script riêng lẻ có thể không quá nặng, nhưng tổng hợp lại có thể làm phản hồi tương tác chậm.

web.dev hiện xác định INP là Core Web Vital đo khả năng phản hồi trong suốt phiên truy cập và khuyến nghị mức tốt là ≤ 200 ms. JavaScript chạy dài và script bên thứ ba là những nguyên nhân cần kiểm tra khi INP kém.

Lập danh sách third-party

Đừng để website tích lũy tag qua nhiều năm mà không ai biết tag nào còn sử dụng.

Tạo bảng:

Script	Mục đích	Có đang dùng dữ liệu?	Cần tải ngay?
Analytics	Đo lường	Có	Tùy kiến trúc
Chat A	Chat	Có	Có thể tải khi tương tác
Heatmap cũ	Phân tích UX	Không	Nên bỏ

Trì hoãn những gì chưa cần

Có thể cân nhắc:

• defer;
• async;
• Load sau interaction;
• Load sau consent nếu áp dụng;
• Chỉ tải trên template cần thiết.

Ví dụ widget chỉ dùng trên trang liên hệ không cần được nạp ở toàn site.

Giảm JavaScript của chính website

Kiểm tra:

• Slider có thật sự cần thư viện lớn?
• Animation nào không tạo giá trị?
• Plugin có tải JS trên mọi URL?
• Filter có render lại hàng nghìn node?
• Có long task nào xuất hiện khi khách click?

5. Dùng cache và CDN đúng lớp

“Bật cache” không phải chỉ có một công tắc.

Một website có thể có nhiều lớp cache.

Browser cache

Cho phép trình duyệt giữ CSS, JS, ảnh, font phù hợp để các lần xem sau không phải tải lại toàn bộ.

Page cache

Lưu HTML đã render cho những trang có thể cache, giảm công việc PHP/backend/database.

Object/application cache

Lưu kết quả query hoặc object thường xuyên được sử dụng.

CDN cache

Phân phối tài nguyên từ edge gần người dùng và giảm tải origin.

Với website BĐS có nhiều ảnh, CDN thường đặc biệt hữu ích cho:

• Ảnh dự án;
• Thumbnail;
• CSS;
• JavaScript;
• Font;
• Các file tĩnh khác.

Cache phải có chiến lược invalidation

Ví dụ dự án vừa đổi giá nhưng CDN/page cache vẫn hiển thị dữ liệu cũ trong 24 giờ là một vấn đề nghiêm trọng hơn việc trang chậm thêm vài trăm mili giây.

Các nội dung thay đổi nhanh như:

• Giá;
• Giỏ hàng;
• Trạng thái tin;
• Chính sách;

cần TTL hoặc cơ chế purge phù hợp.

6. Tối ưu CSS, font và tài nguyên chặn render

Trình duyệt cần CSS để biết trang sẽ được vẽ như thế nào. Nếu phần đầu trang phụ thuộc vào nhiều stylesheet lớn hoặc font tải chậm, nội dung quan trọng có thể hiển thị muộn.

Loại CSS không cần thiết

Nhiều theme/framework tải:

• CSS shop;
• CSS portfolio;
• CSS popup;
• CSS icon;
• CSS slider;

trên mọi trang dù template không sử dụng.

Nên kiểm tra khả năng:

• Bundle hợp lý;
• Loại bỏ unused CSS;
• Chỉ tải component khi cần;
• Minify khi hệ thống hỗ trợ an toàn.

Font: càng nhiều không càng đẹp

Một website dùng:

• 2 font family;
• 5 weight;
• italic;
• icon font;

có thể phát sinh rất nhiều request.

Nên:

• Giới hạn family/weight thực sự dùng;
• Subset khi phù hợp;
• Self-host nếu kiến trúc và license cho phép;
• Thiết lập font-display phù hợp;
• Không preload mọi font.

Không preload bừa bãi

Preload khiến browser tải tài nguyên sớm. Nếu preload 10 file “cho chắc”, những file đó có thể cạnh tranh bandwidth với chính ảnh LCP.

Chỉ preload tài nguyên thực sự critical.

7. Tối ưu hosting, backend, TTFB và database

Nếu HTML ban đầu trả về chậm, tối ưu ảnh phía frontend không giải quyết được toàn bộ vấn đề.

TTFB cao có thể xuất phát từ:

• Hosting quá tải;
• PHP/backend xử lý lâu;
• Database query chậm;
• API chậm;
• Không có page/object cache;
• DNS/network;
• Redirect chain.

Đừng nâng VPS trước khi tìm bottleneck

CPU mạnh hơn có thể che vấn đề trong thời gian ngắn nhưng không sửa được query không có index hoặc request gọi API tuần tự.

Nên kiểm tra:

• Server timing/APM;
• Slow query log;
• PHP execution time;
• Database query count;
• External API time;
• Cache hit/miss;
• CPU/RAM/IO trong giờ cao điểm.

Database web BĐS cần chú ý gì?

Website có nhiều tin đăng thường query theo:

• Khu vực;
• Giá;
• Diện tích;
• Loại hình;
• Trạng thái;
• Ngày đăng.

Nếu database không có index phù hợp, một bộ lọc tưởng đơn giản có thể quét lượng dữ liệu lớn.

Đừng “dọn database” bằng cách xóa dữ liệu tùy tiện. Việc quan trọng hơn là:

• Schema hợp lý;
• Index đúng;
• Query đúng;
• Pagination;
• Archive dữ liệu khi cần;
• Kiểm soát log/revision/session.

Nền tảng rộng hơn về server và vận hành có thể xem tại bảo mật và hiệu năng website bất động sản.

8. Tối ưu riêng các module “nặng” đặc thù website BĐS

Đây là phần tạo khác biệt giữa tối ưu một website thông thường và một website bất động sản.

Gallery dự án

Không tải toàn bộ ảnh full resolution ngay khi mở trang.

Nên:

• Ảnh preview nhẹ;
• Responsive thumbnail;
• Lazy-load ảnh ngoài viewport;
• Full image chỉ tải khi mở lightbox nếu phù hợp.

Mặt bằng

Ảnh mặt bằng thường cần độ phân giải cao để zoom.

Đừng dùng file full-resolution làm thumbnail.

Có thể:

Thumbnail → click → tải bản lớn.

Google Maps

Nếu map nằm sâu trong trang, cân nhắc:

Placeholder → “Xem bản đồ” → mới tải iframe/API.

Cách này tránh việc mọi visitor phải tải Maps dù họ không bao giờ cuộn đến phần vị trí.

Video

Thay vì nhúng nhiều player hoạt động ngay:

• Dùng poster/thumbnail;
• Chỉ tạo iframe/player sau click;
• Không autoplay video nặng nếu không có lý do rõ.

Chatbot

Chỉ tải widget đầy đủ khi cần hoặc theo chiến lược delay/interaction nếu nền tảng hỗ trợ.

Bộ lọc tìm kiếm

Đừng reload và render lại toàn bộ trang cho từng checkbox nếu không cần.

Nhưng cũng không nên đưa toàn bộ 10.000 listing vào browser rồi lọc bằng JavaScript.

Kiến trúc phù hợp thường là:

Client gửi điều kiện → backend/search engine xử lý → trả một batch kết quả → render phần cần thiết.

Infinite scroll

Không nên tải trước hàng trăm card.

Sử dụng pagination hoặc incremental loading phù hợp và kiểm soát số item trong DOM.

9. Thiết lập performance budget và monitoring để website không chậm trở lại

Tối ưu tốc độ một lần chưa đủ.

Sau vài tháng, đội marketing có thể thêm:

• 2 pixel mới;
• 1 chatbot;
• 1 thư viện animation;
• video Hero;
• popup;
• heatmap.

Website lại quay về trạng thái cũ.

Performance budget đặt ra giới hạn trước khi release.

Ví dụ, đội phát triển có thể quy định:

Hạng mục	Quy tắc nội bộ mẫu
LCP	Không release nếu field/lab regression nghiêm trọng
JavaScript	Plugin mới phải giải thích lý do
Hero	Có responsive source và ưu tiên tải đúng
Third-party	Có owner và mục đích sử dụng
Map/video	Ưu tiên click-to-load khi phù hợp

Không nhất thiết mọi website phải dùng cùng một giới hạn byte hay request. Performance budget nên được xây từ baseline của chính hệ thống.

Cách xử lý từng Core Web Vital trên website BĐS

LCP cao

Kiểm tra:

• TTFB;
• Ảnh Hero;
• Lazy-load nhầm LCP;
• CSS background làm ảnh được phát hiện muộn;
• Slider;
• Font;
• Render-blocking CSS.

web.dev khuyến nghị để tài nguyên LCP được browser phát hiện sớm, tránh lazy-loading nó, và có thể dùng fetchpriority="high" trong trường hợp thích hợp.

INP cao

Kiểm tra:

• Long JavaScript tasks;
• Click filter;
• Popup;
• Gallery;
• Menu mobile;
• Chat;
• Third-party scripts;
• DOM quá lớn.

Đặc biệt nên test những tương tác thật như mở bộ lọc, đổi tab mặt bằng hoặc submit form thay vì chỉ xem thời gian tải ban đầu.

CLS cao

Kiểm tra:

• Ảnh không có width/height;
• Iframe map/video không reserve kích thước;
• Banner xuất hiện muộn;
• Font swap;
• Popup/banner chèn vào giữa layout;
• Form báo lỗi làm đẩy nội dung mạnh.

Ví dụ tối ưu một trang dự án BĐS

Giả sử trang gồm:

• Hero;
• 20 ảnh gallery;
• Video;
• Map;
• 10 ảnh tiện ích;
• 5 mặt bằng;
• Form;
• Zalo;
• Analytics;
• Meta Pixel.

Không nên tải tất cả khi người dùng vừa mở URL.

Mạch tải hợp lý có thể là:

Giai đoạn 1 – ưu tiên ngay

• HTML;
• Critical CSS;
• Logo;
• Hero/LCP;
• Headline;
• CTA.

Giai đoạn 2 – tải bình thường

• Ảnh preview đầu gallery;
• Nội dung text;
• CSS/JS cần cho tương tác chính.

Giai đoạn 3 – lazy load

• Ảnh tiện ích;
• Gallery phía dưới;
• Thumbnail mặt bằng.

Giai đoạn 4 – tải theo interaction

• Ảnh mặt bằng full resolution;
• Video player;
• Google Maps;
• Một số widget chat.

Đây là tư duy ưu tiên tài nguyên theo giá trị của từng thời điểm, thay vì “load hết rồi cache”.

Có nên dùng slider Hero?

Không phải slider nào cũng xấu, nhưng nó có thể làm quá trình tối ưu LCP phức tạp hơn.

Nếu có 5 ảnh Hero:

• Chỉ slide đầu cần ưu tiên cao;
• Các slide sau không nên cạnh tranh bandwidth với slide đầu;
• Không nên preload toàn bộ;
• Kiểm tra JS slider có gây long task không.

web.dev đưa ra ví dụ chỉ tăng ưu tiên cho ảnh đầu carousel và giảm ưu tiên của các ảnh chưa hiển thị để tránh cạnh tranh tài nguyên.

Nếu Hero chỉ cần truyền một thông điệp chính, một ảnh tĩnh thường đơn giản và dễ tối ưu hơn.

CDN có làm website luôn nhanh hơn không?

Không phải trong mọi trường hợp.

CDN giúp đáng kể khi:

• Người dùng ở nhiều vị trí;
• Website có nhiều file tĩnh;
• Origin có khoảng cách địa lý lớn;
• Traffic cao;
• Edge cache hit tốt.

Nhưng CDN không sửa được:

• JavaScript chạy 2 giây;
• Database query chậm;
• Ảnh quá lớn;
• DOM khổng lồ;
• API backend chậm.

Đừng dùng CDN để che một kiến trúc frontend/backend thiếu tối ưu.

Minify CSS/JS có còn quan trọng?

Có, nhưng thường không phải việc đầu tiên cần làm trên một trang dự án nặng.

Nếu website đang tải:

• 10MB ảnh;
• video;
• Google Maps;
• 7 third-party scripts;

thì tiết kiệm thêm vài KB từ minification không phải bottleneck lớn nhất.

Ưu tiên theo tác động:

bỏ tài nguyên không cần → giảm kích thước → tải đúng thời điểm → rồi mới tinh chỉnh chi tiết.

Preconnect, preload và fetchpriority nên dùng thế nào?

Preconnect

Có thể hữu ích khi trang chắc chắn cần kết nối sớm tới một origin quan trọng.

Preload

Dùng để giúp browser phát hiện sớm một tài nguyên critical mà bình thường được phát hiện muộn.

fetchpriority

Gợi ý mức ưu tiên tải.

Không nên áp dụng các thuộc tính này theo checklist máy móc. web.dev nhấn mạnh fetchpriority chỉ là một hint, và preload/fetchpriority giải quyết những bài toán khác nhau.

Hãy kiểm chứng bằng waterfall trước và sau thay đổi.

Tốc độ website có phải yếu tố SEO không?

Google hiện cho biết Core Web Vitals được sử dụng trong các hệ thống ranking, nhưng không tồn tại một “page experience signal” duy nhất và điểm Core Web Vitals tốt không bảo đảm trang đứng top. Nội dung phù hợp và hữu ích vẫn là nền tảng.

Do đó, mục tiêu không nên là:

“Làm PageSpeed 100 để SEO lên top.”

Mà là:

“Giảm thời gian chờ, giảm lag, giữ ổn định giao diện và giúp người dùng hoàn thành hành động nhanh hơn.”

Điều này hỗ trợ cả SEO, trải nghiệm và chuyển đổi.

Những lỗi tăng tốc website thường gặp

• Lazy-load ảnh Hero: làm LCP bắt đầu tải muộn;
• Preload quá nhiều: tài nguyên không quan trọng cạnh tranh bandwidth;
• Cài 2–3 plugin cache: rule xung đột và khó debug;
• Delay toàn bộ JavaScript: menu/form/tracking có thể hỏng;
• Nén ảnh quá mức: mặt bằng không đọc được;
• Chỉ tối ưu desktop: bỏ qua mobile thực tế;
• Chỉ test homepage: không phát hiện trang dự án chậm;
• Nâng hosting trước khi profile: không biết bottleneck;
• Xóa database “rác” tùy tiện: rủi ro mất dữ liệu;
• CDN cache sai: hiển thị giá/trạng thái cũ;
• Tập trung điểm Lighthouse thay vì user: bỏ qua field data;
• Không kiểm tra sau mỗi lần marketing thêm script.

Checklist tăng tốc website BĐS

Đo lường

• [ ] Kiểm tra Search Console Core Web Vitals;
• [ ] Test PageSpeed Insights;
• [ ] Kiểm tra DevTools waterfall;
• [ ] Test nhiều template;
• [ ] Ưu tiên dữ liệu mobile.

LCP

• [ ] Xác định LCP element;
• [ ] Hero đúng kích thước;
• [ ] Không lazy-load ảnh LCP;
• [ ] Browser phát hiện ảnh sớm;
• [ ] Dùng fetch priority nếu phù hợp;
• [ ] TTFB không quá cao.

Hình ảnh

• [ ] Có responsive images;
• [ ] Thumbnail riêng;
• [ ] Gallery lazy-load;
• [ ] Full image chỉ tải khi cần;
• [ ] WebP/AVIF khi phù hợp;
• [ ] Giữ chất lượng mặt bằng.

JavaScript

• [ ] Audit third-party scripts;
• [ ] Xóa tag không còn dùng;
• [ ] Không tải plugin ở trang không cần;
• [ ] Kiểm tra long task;
• [ ] Test tương tác filter/gallery/menu;
• [ ] INP hướng tới ≤ 200 ms.

Backend

• [ ] Page cache;
• [ ] Browser cache;
• [ ] CDN khi phù hợp;
• [ ] Kiểm tra TTFB;
• [ ] Slow query log;
• [ ] Index database;
• [ ] Theo dõi server resource.

Module BĐS

• [ ] Map tải trễ/click-to-load nếu phù hợp;
• [ ] Video tải theo nhu cầu;
• [ ] Gallery không tải full ngay;
• [ ] Mặt bằng dùng thumbnail + ảnh lớn;
• [ ] Filter không xử lý dataset quá lớn trên browser;
• [ ] Chat không chặn nội dung chính.

CLS

• [ ] Ảnh có kích thước xác định;
• [ ] Video/map reserve không gian;
• [ ] Banner/popup không đẩy nội dung;
• [ ] Form error không làm layout nhảy mạnh;
• [ ] CLS hướng tới ≤ 0,1.

Câu hỏi thường gặp

PageSpeed 100 có cần thiết không?

Không. Điểm cao hữu ích cho việc kiểm thử nhưng không phải mục tiêu kinh doanh cuối cùng. Google cũng lưu ý việc cố đạt điểm hoàn hảo chỉ vì SEO có thể không phải cách sử dụng thời gian hiệu quả nhất. Hãy ưu tiên Core Web Vitals và trải nghiệm thực tế.

Có nên lazy-load tất cả ảnh?

Không. Ảnh ngoài viewport nên cân nhắc lazy-load; ảnh Hero/LCP cần được phát hiện và tải sớm. web.dev cảnh báo lazy-loading ảnh LCP gây trì hoãn không cần thiết.

WebP có đảm bảo website nhanh?

Không. Nếu file WebP rộng 5000px vẫn được tải cho thumbnail 300px, website vẫn lãng phí dữ liệu. Định dạng chỉ là một phần; kích thước, responsive source và thời điểm tải đều quan trọng.

Có nên dùng VPS thay shared hosting?

Phụ thuộc traffic, workload và bottleneck. VPS không tự động sửa code/database chậm. Hãy đo TTFB, CPU/RAM/IO và query trước khi nâng hạ tầng.

CDN có cần cho website chỉ phục vụ khách tại Việt Nam?

Có thể vẫn hữu ích với website nhiều asset hoặc traffic lớn, nhưng mức lợi ích phụ thuộc origin, nhà cung cấp và vị trí người dùng. Nên đo trước/sau thay vì coi CDN là bắt buộc.

INP kém thường do đâu?

Thường cần kiểm tra JavaScript chạy dài, script bên thứ ba, event handler, render/DOM và các tương tác phức tạp như filter, gallery hoặc menu. web.dev khuyến nghị giảm công việc trên main thread và tối ưu code xử lý tương tác khi INP cao.

Tối ưu tốc độ có giúp tăng lead không?

Tốc độ không tự đảm bảo có lead. Nhưng website phản hồi nhanh giúp giảm ma sát trong hành trình xem dự án, mở gallery, dùng bộ lọc và submit form. Vì vậy nên đánh giá hiệu năng cùng KPI chuyển đổi chứ không chỉ điểm kỹ thuật.

Kết luận

Tăng tốc website bất động sản không phải một danh sách thao tác như “nén ảnh – bật cache – cài CDN”. Cách hiệu quả hơn là xác định bottleneck theo từng lớp:

đo → ưu tiên LCP → giảm dữ liệu → giảm JavaScript → cache/CDN → tối ưu render → xử lý backend → tối ưu module BĐS → giám sát liên tục.

Đặc biệt với web BĐS, hãy ưu tiên những gì người dùng nhìn và thao tác trước: Hero, thông tin dự án, CTA, gallery đầu tiên và bộ lọc. Các tài nguyên nặng như video, map, ảnh full-resolution hay widget phụ có thể tải sau khi chúng thực sự cần thiết.

Ở cấp hệ thống, hiệu năng nên được quản lý cùng bảo mật và hiệu năng website bất động sản, đồng thời kiểm tra trên phiên bản mobile – nơi điều kiện thiết bị và mạng thường làm lộ rõ nhất những vấn đề mà máy tính văn phòng tốc độ cao có thể che giấu.