Cách làm website nhanh hơn: danh sách kiểm tra thực tế

Để làm website nhanh hơn, hãy đo trước bằng PageSpeed Insights, rồi sửa nguyên nhân lớn nhất mà nó chỉ ra — thường là hình ảnh quá lớn, quá nhiều JavaScript, font nặng hoặc script bên thứ ba. Hãy nhắm tới các mục tiêu “tốt” của Core Web Vitals của Google: nội dung chính hiển thị trong 2,5 giây, phản hồi khi chạm trong 200 mili giây, và gần như không có hiện tượng bố cục bị nhảy. Hầu hết website đạt được điều này chỉ với vài thay đổi, không cần viết lại.

Đo trước khi thay đổi bất cứ thứ gì

Đoán mò làm mất thời gian. Hai công cụ miễn phí phục vụ gần như mọi người:

PageSpeed Insights (pagespeed.web.dev) — dán một URL trực tiếp. Nó hiển thị dữ liệu thực địa từ người dùng Chrome thật (nếu website của bạn có đủ lượt truy cập) và dữ liệu lab từ một lượt tải mô phỏng, cùng danh sách các vấn đề cụ thể.
Lighthouse trong Chrome DevTools — cùng bài kiểm tra lab, chạy trên bất kỳ trang nào bạn mở được, kể cả bản xem trước. Hãy kiểm tra ở chế độ di động; điện thoại trên mạng chậm hơn là nơi các vấn đề lộ ra.

Các con số quan trọng là Core Web Vitals của Google. Tính đến tháng 9 năm 2026, tài liệu của Google trên web.dev đưa ra các ngưỡng “tốt” sau, đo ở phân vị thứ 75 của các lượt tải trang:

Chỉ số	Đo lường gì	Tốt
Largest Contentful Paint (LCP)	Nội dung chính (ảnh hero, tiêu đề) xuất hiện nhanh đến mức nào	2,5 s trở xuống
Interaction to Next Paint (INP)	Trang phản ứng với nhấp chuột, chạm và gõ nhanh đến mức nào	200 ms trở xuống
Cumulative Layout Shift (CLS)	Bố cục nhảy nhiều đến mức nào trong khi tải	0,1 trở xuống

INP đã thay thế chỉ số First Input Delay cũ vào năm 2024. Nếu một công cụ vẫn báo cáo FID, nó đã lỗi thời.

Hãy ghi lại các con số ban đầu. Sau mỗi lần sửa, hãy kiểm tra lại để biết điều gì đã giúp.

Thời gian đi đâu: các lựa chọn và đánh đổi

Mỗi nguyên nhân phổ biến đều có cách sửa, và mỗi cách sửa đều có chi phí. Hãy bắt đầu với những cách ở trên cùng — chúng rẻ nhất và phổ biến nhất.

Nguyên nhân	Cách sửa thường gặp	Đánh đổi
Hình ảnh lớn	Thu nhỏ về kích thước hiển thị, nén, dùng WebP hoặc AVIF	Giảm chất lượng nhẹ nếu nén quá mức
Hình ảnh tải sai thứ tự	Lazy-load hình ảnh phía dưới màn hình; ưu tiên tải ảnh hero	Không có, miễn là ảnh hero không được lazy-load
Quá nhiều JavaScript	Tách code theo từng trang, bỏ thư viện không dùng	Cần tái cấu trúc một phần
Render chỉ ở phía client	Prerender hoặc render phía máy chủ cho trang công khai	Cần thiết lập build hoặc máy chủ nhiều hơn
Font web	Ít họ font và độ đậm hơn, preload font chính, `font-display: swap`	Ít sự đa dạng về kiểu chữ hơn
Script bên thứ ba	Gỡ bỏ những cái không dùng, tải phần còn lại sau khi trang xong	Mất một widget hoặc công cụ theo dõi
Phản hồi máy chủ chậm	Caching, CDN, lưu trữ tĩnh cho trang nội dung	Cần suy nghĩ về việc vô hiệu hóa cache

Hình ảnh

Hình ảnh là vấn đề phổ biến nhất và dễ sửa nhất. Một bức ảnh 4.000 pixel hiển thị ở 800 pixel buộc mỗi người truy cập phải tải về gấp năm lần những gì họ thấy.

Phục vụ hình ảnh đúng với kích thước hiển thị, với kích thước srcset đáp ứng cho điện thoại và máy tính.
Dùng định dạng hiện đại (WebP hoặc AVIF) và mức nén hợp lý.
Đặt width và height cho mọi hình ảnh để trình duyệt dành sẵn không gian. Chỉ riêng việc này đã sửa được phần lớn hiện tượng dịch chuyển bố cục.
Lazy-load hình ảnh phía dưới màn hình bằng loading="lazy".
Đừng bao giờ lazy-load hình ảnh chính ở đầu trang. Hướng dẫn LCP của Google nói rất thẳng: lazy-load ảnh LCP luôn làm nó chậm hơn. Hãy đặt fetchpriority="high" thay thế.

JavaScript

Nhiều website xây bằng AI là ứng dụng một trang (SPA): trình duyệt tải một gói JavaScript rồi mới vẽ trang. Gói càng lớn, màn hình trắng càng lâu. Các cách sửa, theo thứ tự công sức tăng dần:

Gỡ bỏ những gì bạn không dùng. Yêu cầu danh sách các phụ thuộc và cắt những thư viện từng được thêm rồi bị quên — một thư viện ngày tháng chỉ để xử lý một ngày, một bộ biểu tượng đầy đủ chỉ cho năm biểu tượng.
Tách theo route. Chỉ tải mã của bảng quản trị khi có người mở nó, không tải trên trang chủ.
Prerender các trang công khai. Một trang tiếp thị được gửi đi dưới dạng HTML thật sẽ hiển thị trước khi bất kỳ JavaScript nào chạy. Điều này cũng giúp công cụ tìm kiếm; xem SEO cho website xây bằng AI.

INP chậm thường có nghĩa là một tác vụ dài chặn trang — lọc một danh sách khổng lồ mỗi lần gõ phím, hoặc render lại toàn bộ bảng khi một ô thay đổi. Bảng Performance của Chrome DevTools cho thấy đó là gì.

Font

Mỗi họ font và độ đậm là thêm một tệp. Hai họ và ba đến bốn độ đậm thường là đủ. Preload font được dùng phía trên màn hình, dùng font-display: swap để văn bản hiển thị ngay, và tự lưu trữ font nếu dịch vụ font bên ngoài chậm với người truy cập của bạn.

Script bên thứ ba

Widget chat, phân tích, bản đồ nhiệt, pixel quảng cáo, video nhúng và nguồn mạng xã hội đều tải mã từ các máy chủ khác. Mỗi cái trông nhỏ; cộng lại, chúng thường là phần chậm nhất của trang. Hãy giữ những cái bạn thực sự xem. Tải phần còn lại sau khi trang đã tương tác được, và thay các nhúng nặng (trình phát YouTube, bản đồ) bằng một bản xem trước nhẹ, chỉ tải nội dung thật khi người dùng nhấp.

Thời gian phản hồi máy chủ

Time to first byte (TTFB) — thời gian máy chủ bắt đầu trả lời — nằm bên dưới mọi chỉ số khác. Các trang tĩnh được phục vụ từ CDN (mạng lưới máy chủ gần người truy cập; xem CDN là gì) thì nhanh gần như ở mọi nơi. Các trang do máy chủ dựng cho mỗi yêu cầu phụ thuộc vào máy chủ đó và cơ sở dữ liệu của nó. Caching các công việc lặp lại và thêm chỉ mục cơ sở dữ liệu cho các truy vấn chậm là những cách sửa thông thường.

Các lệnh hiệu quả

Hãy cụ thể: nêu tên trang, chỉ số và ràng buộc. Dán các phát hiện của PageSpeed Insights nếu bạn có.

PageSpeed Insights báo LCP là 4,8 s trên di động cho trang chủ, và phần tử LCP là ảnh hero. Thu nhỏ và chuyển ảnh hero sang WebP, phục vụ kích thước đáp ứng, đặt width và height, đặt fetchpriority="high" và đảm bảo ảnh này không bị lazy-load. Lazy-load mọi hình ảnh phía dưới màn hình. Đừng thay đổi thiết kế.

Kiểm tra các phụ thuộc của ứng dụng này. Liệt kê từng gói, thứ gì dùng nó và nó làm bundle tăng bao nhiêu. Gỡ những gói không dùng và tách các route /admin và /settings thành các chunk riêng chỉ tải khi được truy cập.

Ô tìm kiếm trên /products cảm thấy chậm. Hãy debounce bộ lọc, tránh render lại toàn bộ danh sách trên mỗi lần gõ phím, và phân trang hoặc virtualize danh sách nếu nó có hơn 200 mục.

Từng bước

Kiểm tra trang trực tiếp trong PageSpeed Insights trên di động. Ghi lại LCP, INP và CLS, và ba vấn đề hàng đầu được liệt kê.
Sửa hình ảnh trước: kích thước, định dạng, kích thước khai báo, lazy loading phía dưới màn hình, ưu tiên cho ảnh hero.
Cắt script bên thứ ba mà bạn không dùng, và trì hoãn phần còn lại.
Cắt bớt font xuống mức thiết kế cần.
Thu nhỏ JavaScript: gỡ các gói không dùng, tách theo route.
Prerender các trang công khai nếu chúng vẫn được render ở client và LCP vẫn chậm.
Kiểm tra máy chủ: caching, chỉ mục cơ sở dữ liệu, lưu trữ tĩnh cho nội dung ít thay đổi.
Xuất bản lại và kiểm tra lại. Dữ liệu thực địa trong PageSpeed Insights cập nhật trong các tuần sau đó khi có lượt truy cập thật, nên hãy đánh giá kết quả ban đầu bằng dữ liệu lab.

Các lỗi thường gặp

Chỉ kiểm tra trên laptop nhanh. Người truy cập của bạn dùng điện thoại tầm trung và mạng di động không ổn định. Hãy kiểm tra ở chế độ di động.
Theo đuổi điểm 100 tuyệt đối. Điểm lab chỉ là hướng dẫn. Khi Core Web Vitals đã ở mức tốt, nội dung và khả năng sử dụng quan trọng hơn vài điểm cuối cùng.
Lazy-load mọi thứ, kể cả ảnh hero. Điều đó làm LCP tệ hơn.
Thêm một plugin hoặc thư viện tăng tốc bổ sung. Gỡ bớt trọng lượng hầu như luôn tốt hơn thêm mã để quản lý nó.
Tối ưu bản xem trước, không phải website trực tiếp. Các bản xem trước phát triển chạy bản build chưa tối ưu. Hãy đo URL đã xuất bản.
Chỉ tăng tốc một lần. Mỗi widget, hình ảnh và tính năng mới đều thêm trọng lượng. Hãy kiểm tra lại sau các thay đổi lớn.

Danh sách kiểm tra tốc độ

LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 trên di động
Hình ảnh đã thu nhỏ, nén, dùng định dạng hiện đại, có width và height
Ảnh hero không bị lazy-load; hình ảnh phía dưới màn hình được lazy-load
Không có thư viện JavaScript không dùng; các route nặng đã được tách
Hai họ font hoặc ít hơn, font chính đã được preload
Chỉ những script bên thứ ba bạn thực sự dùng, và tải muộn
Các trang công khai được prerender hoặc tĩnh khi có thể
Đã kiểm tra lại trên URL trực tiếp sau khi xuất bản

Tốc độ và bố cục di động đi đôi với nhau; xem cách làm website responsive trên di động. Để có một lượt rà soát đầy đủ trước khi ra mắt, cách đưa một nguyên mẫu AI lên sản phẩm thật bao quát phần còn lại.

Tốc độ trên Mythex

Trên Mythex, bạn thực hiện các thay đổi này bằng cách yêu cầu trong khung chat, hoặc trong trình soạn thảo mã ở gói Pro. Hãy kiểm tra URL đã xuất bản, không phải Preview, vì Preview chạy máy chủ phát triển. Các front end tĩnh được triển khai như website tĩnh khi bạn xuất bản (website tĩnh), phù hợp với các trang nội dung. Các ứng dụng có máy chủ sẽ scale về 0: chúng ngủ khi không dùng và thức dậy ở lượt truy cập tiếp theo, nên yêu cầu đầu tiên sau một khoảng nghỉ sẽ chậm hơn, và cơ sở dữ liệu đính kèm sẽ ngủ sau 5 phút không hoạt động (giới hạn lưu trữ). Nếu một trang công khai chỉ chậm ở lần truy cập đầu tiên, đó là nguyên nhân có khả năng nhất. Giữ các trang tiếp thị ở dạng tĩnh sẽ giúp ích. Sau khi thay đổi, hãy xuất bản lại và tải lại trang với bộ nhớ đệm bị bỏ qua.

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

Thời gian tải trang tốt là bao nhiêu?

Core Web Vitals của Google đưa ra mục tiêu rõ ràng nhất: nội dung chính phải hiển thị trong 2,5 giây (LCP), trang phải phản hồi tương tác trong 200 mili giây (INP), và độ dịch chuyển bố cục phải giữ ở mức 0,1 hoặc thấp hơn (CLS), đo ở phân vị thứ 75 của các lượt truy cập thực tế.

Tốc độ website có ảnh hưởng đến SEO không?

Có, nhưng ở mức nhỏ. Google sử dụng các tín hiệu trải nghiệm trang, bao gồm Core Web Vitals, nhưng nội dung phù hợp quan trọng hơn nhiều. Tốc độ ảnh hưởng lớn hơn đến người truy cập, những người rời khỏi trang chậm trước khi đọc bất cứ thứ gì.

Vì sao điểm PageSpeed Insights của tôi lần nào cũng khác?

Điểm lab đến từ một lượt tải mô phỏng duy nhất, nên thời gian mạng và máy chủ thay đổi giữa các lần chạy. Hãy chạy vài lần và xem xu hướng, và đặt trọng số cao hơn cho phần dữ liệu thực địa, vốn đến từ người dùng Chrome thật.

Điều gì làm chậm hầu hết các website?

Thường là hình ảnh quá lớn, quá nhiều JavaScript, font web và các script bên thứ ba như widget chat, pixel quảng cáo và nhúng. Phản hồi máy chủ chậm hoặc backend khởi động nguội sẽ cộng thêm vào tất cả những thứ đó.