Bản đồ tối ưu tốc độ website

Cái gì & vì sao

Tốc độ không phải "nice to have" — nó là tiền

• Tốc độ = SEO + tỷ lệ chuyển đổi — Google dùng tốc độ làm tín hiệu xếp hạng; mỗi giây chậm thêm kéo CVR xuống

  Google chính thức đưa Core Web Vitals vào thuật toán xếp hạng từ 2021. Song song đó, dữ liệu ngành thương mại điện tử cho thấy cứ mỗi giây tải chậm thêm, tỷ lệ chuyển đổi giảm trung bình 7-12% — tức tốc độ ảnh hưởng trực tiếp tới doanh thu, không chỉ thứ hạng tìm kiếm.

• Core Web Vitals là gì — 3 chỉ số Google dùng để đo "cảm giác nhanh" thực tế của người dùng

  Core Web Vitals gồm 3 chỉ số: LCP (Largest Contentful Paint — tốc độ vẽ nội dung chính), INP (Interaction to Next Paint — độ trễ phản hồi thao tác) và CLS (Cumulative Layout Shift — độ ổn định bố cục). Cả 3 đo trải nghiệm thật của người dùng, không phải benchmark phòng lab.

Đo lường

Không đo được thì không tối ưu được

• PageSpeed Insights / Lighthouse — Chấm điểm 0-100 + Core Web Vitals thật từ Chrome UX Report

  PageSpeed Insights chạy Lighthouse (đo lab, mô phỏng thiết bị/mạng chuẩn hoá) và đối chiếu với dữ liệu CrUX (đo thật từ người dùng Chrome) cho cùng một URL. Đây là điểm khởi đầu tốt nhất vì miễn phí, chính thức từ Google, và cho cả góc nhìn lab lẫn field.

• Ngưỡng đạt/không đạt của Core Web Vitals — LCP ≤ 2.5s · INP ≤ 200ms · CLS ≤ 0.1 = "Good"

  Google phân loại mỗi chỉ số thành 3 mức: Good, Needs Improvement, Poor. Ngưỡng "Good": LCP ≤ 2.5 giây, INP ≤ 200 mili-giây, CLS ≤ 0.1. Để trang được coi là đạt Core Web Vitals, cả 3 chỉ số đều phải nằm ở mức Good với ít nhất 75% lượt truy cập.

• WebPageTest — Waterfall chi tiết, test từ nhiều vùng địa lý + kết nối mạng thật

  WebPageTest cho phép chọn vị trí server test (gần người dùng Việt Nam hơn), loại thiết bị, tốc độ mạng (3G/4G/cáp quang), và trả về waterfall chi tiết từng request — hữu ích khi PageSpeed Insights không đủ chi tiết để tìm nguyên nhân gốc.

• RUM (Real User Monitoring) — Đo tốc độ thật của từng khách truy cập, không phải mẫu giả lập

  RUM thu thập chỉ số hiệu năng trực tiếp từ trình duyệt của khách truy cập thật (qua Performance API/web-vitals.js), khác với lab test chỉ mô phỏng một kịch bản cố định. RUM cho thấy sự khác biệt giữa thiết bị mạnh/yếu, mạng nhanh/chậm — thứ lab test không phản ánh được.

Network / CDN

Rút ngắn khoảng cách vật lý và số vòng bắt tay

• DNS prefetch / preconnect — "Mách trước" trình duyệt về domain sẽ cần, tiết kiệm 100+ms

  <link rel="dns-prefetch"> và <link rel="preconnect"> cho trình duyệt phân giải DNS và mở kết nối TCP/TLS tới các domain quan trọng (CDN, Google Fonts, API bên thứ ba) trước khi trình duyệt thực sự cần dùng — loại bỏ độ trễ round-trip khi request đầu tiên thật sự diễn ra.

• CDN edge cache — Trả response từ điểm gần người dùng thay vì origin server ở xa

  CDN (Cloudflare, Fastly…) lưu bản sao HTML/asset ở các edge node phân tán toàn cầu. Khi cache HIT, request không bao giờ chạm tới origin server — giảm cả round-trip time lẫn tải cho server gốc. Cache MISS vẫn phải đi tới origin, nên cấu hình Cache Rule đúng (TTL, cache key) quyết định tỷ lệ HIT.

• HTTP/2 và HTTP/3 — Nhiều request chạy song song trên 1 kết nối, bỏ head-of-line blocking

  HTTP/1.1 giới hạn ~6 kết nối song song mỗi domain. HTTP/2 multiplex nhiều request qua 1 kết nối TCP duy nhất. HTTP/3 (dựa trên QUIC/UDP) đi xa hơn — loại bỏ head-of-line blocking ở tầng transport, cải thiện đáng kể trên mạng di động không ổn định.

• TLS 1.3 + session resumption — Bắt tay mã hoá nhanh hơn — 0-RTT cho kết nối lặp lại

  TLS 1.3 rút ngắn bắt tay từ 2 round-trip xuống 1, và hỗ trợ 0-RTT resumption cho khách quay lại — trình duyệt không cần bắt tay lại từ đầu. Bật trên Nginx/Cloudflare gần như miễn phí về công sức nhưng tiết kiệm 100-150ms mỗi kết nối HTTPS mới.

Server / PHP

Nơi WordPress tiêu tốn thời gian nhiều nhất nếu chưa tối ưu

• OPcache — Lưu bytecode PHP đã biên dịch, khỏi parse lại file .php mỗi request

  PHP mặc định biên dịch lại toàn bộ file .php thành bytecode ở mỗi request. OPcache giữ bytecode đã biên dịch trong bộ nhớ, bỏ qua bước parse/compile lặp lại — thường giảm 30-50% thời gian xử lý PHP thuần trên WordPress.

• PHP-FPM worker pool — Worker "nguội" phải khởi động mới chậm hơn nhiều so với worker đã warm

  PHP-FPM cấp một worker process cho mỗi request. Nếu pm.max_children đặt quá thấp, request phải chờ worker rảnh hoặc khởi động worker mới ("cold start") — chậm hơn đáng kể so với việc có sẵn pool worker đã warm.

• WordPress bootstrap — wp-settings.php chạy hàng chục hook init trước khi theme render bất cứ gì

  Mỗi request WordPress nạp wp-settings.php, khởi tạo hook system, và chạy hàng chục action "init" từ core + plugin + theme trước khi bắt đầu render. OPcache và autoloader tối ưu (Composer classmap thay vì require rải rác) giúp bước này nhanh hơn rõ rệt.

• Giảm số plugin active — Mỗi plugin active là code chạy thêm ở init — không dùng thì tắt

  Nhiều site WordPress tích luỹ 30+ plugin qua thời gian, trong đó nhiều plugin trùng chức năng (2-3 plugin SEO, 2-3 plugin cache…) hoặc không còn dùng. Audit định kỳ và gộp chức năng trùng lặp là cách rẻ nhất để giảm thời gian xử lý server mà không cần nâng cấp hạ tầng.

Database / Cache

Điểm nghẽn lớn nhất trên phần lớn site WordPress

• Redis object cache — Lớp cache giữa PHP và MySQL — tránh lặp lại cùng một truy vấn

  WordPress có object cache API nhưng mặc định chỉ lưu trong bộ nhớ của 1 request (non-persistent). Cài Redis + plugin object-cache biến nó thành persistent cache — kết quả truy vấn được tái sử dụng giữa các request, giảm số lần chạm MySQL tới 80-90%.

• Full-page cache — Lưu sẵn HTML hoàn chỉnh, bỏ qua toàn bộ PHP + DB ở lần sau

  Full-page cache (FastCGI cache, Varnish, hoặc plugin cache của WordPress) lưu HTML output cuối cùng của một trang. Ở lần truy cập sau, server trả thẳng file HTML đã lưu — bỏ qua hoàn toàn PHP-FPM, WordPress bootstrap và mọi truy vấn database.

• N+1 queries — Vòng lặp gọi lại 1 truy vấn cho từng item thay vì gộp thành 1 lần

  Lỗi kinh điển: lặp qua danh sách N bài viết và gọi get_post_meta() riêng cho từng bài thay vì 1 truy vấn duy nhất lấy meta cho cả N bài. Kết quả là N+1 truy vấn thay vì 2 — plugin/theme viết ẩu thường có hàng trăm truy vấn kiểu này trên 1 trang.

Frontend / Assets

Thứ trình duyệt phải tải, parse và vẽ ra màn hình

• Critical CSS inline — CSS cho phần above-the-fold nhúng thẳng vào HTML, phần còn lại defer

  Trình duyệt phải tải xong mọi CSS trong <head> trước khi vẽ pixel đầu tiên (render-blocking). Inline trực tiếp CSS cần cho phần nhìn thấy ngay (above-the-fold) vào <style> trong HTML, rồi tải phần CSS còn lại không đồng bộ — trang vẽ ra gần như ngay lập tức.

• defer / async JavaScript — <script> không có defer chặn cả trình duyệt parse HTML

  Script mặc định chặn parser HTML tại vị trí nó xuất hiện. Thêm defer để script tải song song nhưng chỉ chạy sau khi HTML parse xong (giữ đúng thứ tự); dùng async cho script độc lập (analytics) không cần chờ thứ tự.

• Ảnh WebP / AVIF — Nhẹ hơn JPEG/PNG 25-50% ở cùng chất lượng nhìn thấy được

  WebP và AVIF là định dạng ảnh nén hiệu quả hơn JPEG/PNG truyền thống, thường nhẹ hơn 25-50% ở cùng mức chất lượng. Với ảnh hero (thường là LCP element), đây là một trong những đòn bẩy tối ưu có tác động lớn nhất trên mỗi KB tiết kiệm được.

• Lazy-load ảnh — Chỉ tải ảnh khi sắp cuộn tới — nhưng KHÔNG áp dụng cho ảnh LCP

  loading="lazy" trì hoãn tải ảnh ngoài viewport cho tới khi người dùng cuộn gần tới. Rất hiệu quả cho ảnh phía dưới trang, nhưng áp dụng nhầm cho ảnh hero (LCP element) sẽ khiến trình duyệt trì hoãn chính phần tử cần vẽ sớm nhất — xem thêm mục "Bẫy thường gặp".

• font-display: swap — Hiện chữ bằng font hệ thống ngay, đổi sang web font khi tải xong

  Mặc định, một số trình duyệt ẩn hoàn toàn text cho tới khi web font tải xong (FOIT — Flash of Invisible Text). font-display: swap buộc trình duyệt hiện chữ bằng font dự phòng ngay lập tức, rồi swap sang web font thật khi sẵn sàng — người dùng đọc được nội dung sớm hơn nhiều.

• Preload tài nguyên quan trọng — <link rel="preload"> cho CSS/font chính — nhưng đừng lạm dụng

  rel="preload" mách trình duyệt tải sớm một tài nguyên quan trọng (font chính, ảnh hero, CSS critical) song song với HTML thay vì đợi phát hiện ra nó khi parse tới. Preload thừa (nhiều hơn 3-4 tài nguyên) lại phản tác dụng vì cạnh tranh băng thông với chính những gì thật sự cần sớm.

Core Web Vitals

Nguyên nhân gốc + cách sửa cho từng chỉ số

• LCP — Largest Contentful Paint — Phần tử lớn nhất (thường là ảnh hero) vẽ xong lúc nào

  Nguyên nhân phổ biến nhất: ảnh hero nặng chưa nén, server phản hồi chậm (TTFB cao), hoặc CSS/JS chặn render trước khi ảnh kịp tải. Cách sửa: nén + đúng kích thước ảnh hero, preload nó, không lazy-load nó, và giảm TTFB bằng cache.

• CLS — Cumulative Layout Shift — Nội dung nhảy vị trí sau khi đã hiển thị, gây click nhầm

  Nguyên nhân: ảnh/quảng cáo/embed không khai báo kích thước trước, font swap làm đổi độ rộng chữ, hoặc nội dung được chèn động (banner, cookie notice) đẩy layout xuống. Cách sửa: luôn khai báo width/height hoặc aspect-ratio cho mọi phần tử, và dành sẵn không gian cho nội dung động.

• INP — Interaction to Next Paint — Độ trễ giữa lúc bấm/chạm và lúc màn hình phản hồi

  Nguyên nhân: main thread bị chặn bởi JavaScript nặng (đặc biệt lúc hydration), quá nhiều event listener, hoặc third-party script chạy đồng bộ. Cách sửa: chia nhỏ tác vụ JS dài (code splitting), chỉ hydrate phần cần tương tác (islands architecture), và trì hoãn script không thiết yếu.

Cách áp dụng

5 đoạn cấu hình thật — copy về, đổi placeholder, dùng ngay

• 1. Nginx — Cache-Control cho static assets — Trình duyệt (và CDN) giữ ảnh/CSS/JS lâu dài, khỏi tải lại ở lần ghé sau.

  Đổi đường dẫn / danh sách đuôi file theo cấu trúc theme của bạn. Xem đoạn code đầy đủ trong "Starter pack" ở Page Load Simulator.

• 2. Nginx — Bật nén gzip/brotli — Giảm 60-80% dung lượng HTML/CSS/JS truyền qua mạng, TTFB nhanh hơn.

  Brotli cần module ngx_brotli — cài thêm nếu server chưa có. Xem đoạn code đầy đủ trong "Starter pack" ở Page Load Simulator.

• 3. wp-config.php — Redis object cache — DB query giảm từ hàng trăm xuống chỉ vài chục — chính là bước "DB Queries" trong mô phỏng.

  your-redis-host là placeholder — trỏ về Redis instance thật của bạn. Xem đoạn code đầy đủ trong "Starter pack" ở Page Load Simulator.

• 4. HTML — defer JS + preload critical CSS/font — Bỏ chặn render: trang vẽ ra ngay, script chạy sau khi HTML đã parse xong.

  Chỉ preload thứ thực sự dùng ở above-the-fold — preload thừa lại phản tác dụng. Xem đoạn code đầy đủ trong "Starter pack" ở Page Load Simulator.

• 5. Cloudflare — Cache Rule cho HTML — HTML được trả thẳng từ edge (CDN HIT) thay vì chạm origin mỗi request.

  Cấu hình qua Cloudflare Dashboard → Caching → Cache Rules. Đổi domain theo dự án. Xem đoạn code đầy đủ trong "Starter pack" ở Page Load Simulator.

Bẫy thường gặp

Những lỗi tưởng là tối ưu nhưng lại phản tác dụng

• Lazy-load nhầm ảnh LCP — Ảnh hero bị lazy-load = trì hoãn chính phần tử cần vẽ sớm nhất

  loading="lazy" rất tốt cho ảnh dưới fold, nhưng áp dụng cho ảnh hero (thường chính là LCP element) sẽ buộc trình duyệt trì hoãn tải nó cho tới khi "phát hiện" nó cần thiết — ngược hoàn toàn với mục tiêu. Ảnh trong viewport đầu tiên nên được preload, không lazy-load.

• Quá nhiều third-party script — GA4 + Pixel + chat widget + heatmap… mỗi cái là 1 request chặn thêm

  Mỗi script bên thứ ba (analytics, pixel quảng cáo, live-chat, heatmap) là một request độc lập, thường tải đồng bộ và có thể chặn render hoặc tương tác. Giải pháp: load async/defer, hoặc dùng web worker (Partytown) để chạy chúng ngoài main thread, sau khi trang đã sẵn sàng tương tác.

• Markup thừa từ page builder — Div lồng nhau 10-15 tầng chỉ để canh giữa 1 nút bấm

  Page builder kéo-thả (Elementor, Divi…) thường sinh ra HTML rất dư thừa — hàng trăm div lồng nhau cho một layout đơn giản. DOM lớn khiến parse HTML chậm hơn, CSS selector phức tạp hơn, và tốn bộ nhớ hơn khi render. Cân nhắc custom theme nhẹ cho các trang quan trọng nhất (trang chủ, trang sản phẩm).

Vòng đời tải trang — 24 bước