DEV Community: Anh Nguyen Duc

Website nha khoa mẫu số 4: cách đọc cấu trúc trang dịch vụ và đặt lịch trước khi chọn

Anh Nguyen Duc — Sun, 15 Nov 2026 14:59:00 +0000

Khi chọn giao diện cho website phòng khám nha khoa, người ta thường quyết định bằng trang chủ: ảnh đẹp không, màu có sang không. Nhưng trang chủ không phải nơi khách đặt lịch. Khách đặt lịch ở trang dịch vụ — nơi họ đọc về niềng răng, implant hay bọc sứ — và ở cái form hẹn giờ nằm cuối hành trình đó. Một giao diện nha khoa tốt hay dở lộ rõ nhất ở hai chỗ này, không phải ở banner.

Bài này là cách mình "đọc" một mẫu giao diện nha khoa trước khi quyết định, lấy mẫu số 4 trên MuaTheme làm ví dụ để đối chiếu — bạn có thể mở trang sản phẩm của mẫu và kiểm tra từng điểm dưới đây ngay trên bản demo của nó.

Điểm 1: Trang dịch vụ có tách riêng từng dịch vụ không?

Phòng khám có nhiều dịch vụ với mức giá và quy trình khác hẳn nhau. Cấu trúc đúng là mỗi dịch vụ một trang con: niềng răng, cấy implant, bọc răng sứ, tẩy trắng, điều trị tuỷ, nha khoa trẻ em. Khi xem demo, hãy bấm vào từng mục dịch vụ và kiểm tra xem chúng là các trang riêng có nội dung riêng, hay chỉ là các neo cuộn xuống cùng một trang dài.

Trang riêng quan trọng vì hai lý do: khách chỉ đọc đúng dịch vụ họ cần, và Google cũng chỉ xếp hạng tốt cho trang nào tập trung đúng một chủ đề dịch vụ. Mẫu giao diện nào dựng sẵn khung trang dịch vụ riêng sẽ tiết kiệm cho bạn rất nhiều công về sau.

Điểm 2: Trong trang dịch vụ có đủ "khung thuyết phục" không?

Một trang dịch vụ nha khoa đầy đủ thường có các khối theo thứ tự: giới thiệu ngắn dịch vụ này dành cho ai; quy trình thực hiện từng bước; bảng giá tham khảo; câu hỏi thường gặp riêng cho dịch vụ đó; và nút đặt lịch. Khi đọc demo, mình kiểm tra xem các khối này có sẵn trong bố cục không, hay bạn sẽ phải tự chắp vá bằng các khối trống.

Đặc biệt là khối giá: nhiều mẫu giao diện giấu giá vào trang liên hệ. Với nha khoa, giá tham khảo ngay trong trang dịch vụ là yếu tố lọc khách và tạo liên hệ mạnh nhất — khách biết mình đủ khả năng chi trả mới bấm nút hẹn.

Điểm 3: Luồng đặt lịch đi từ đâu tới đâu?

Hãy tự đóng vai khách: từ trang dịch vụ niềng răng, bạn bấm nút đặt lịch thì chuyện gì xảy ra? Có ba khả năng thường gặp: mở một form đặt lịch có chọn dịch vụ, ngày và giờ; nhảy về trang liên hệ chung; hoặc chỉ hiện số điện thoại. Chỉ khả năng đầu tiên mới là "đặt lịch" đúng nghĩa.

Tiếp theo, kiểm tra form gồm những trường gì. Form đặt lịch nha khoa lý tưởng gồm: họ tên, số điện thoại, dịch vụ quan tâm, ngày và khung giờ mong muốn, ghi chú triệu chứng ngắn. Nhiều hơn thế, khách sẽ bỏ dở. Và sau khi gửi, phải có màn hình xác nhận rõ ràng — không có xác nhận, khách không biết phòng khám đã nhận được yêu cầu hay chưa và sẽ gọi điện hỏi lại, hoặc tệ hơn, đặt lịch ở phòng khám khác.

Điểm 4: Trên điện thoại, nút gọi và đặt lịch có luôn trong tầm tay không?

Phần lớn khách tìm phòng khám bằng điện thoại, thường là khi đang đau hoặc đang ngồi chờ ở đâu đó. Mở demo bằng điện thoại và cuộn trang dịch vụ: nút gọi điện và nút đặt lịch có cố định ở cạnh dưới màn hình không, chữ có đủ lớn để đọc ngoài trời nắng không, form đặt lịch có gõ thoải mái bằng một tay không. Đây là những chi tiết nhỏ quyết định tỉ lệ đặt lịch thực tế hơn mọi hiệu ứng chuyển động.

Điểm 5: Phần blog và hỏi đáp có được coi trọng không?

Nha khoa là ngành khách tự tìm hiểu rất nhiều trước khi chọn phòng khám: "niềng răng có đau không", "implant kiêng ăn gì", "bọc sứ có phải mài răng thật không". Một mẫu giao diện tốt cho nha khoa sẽ có bố cục bài viết dễ đọc, có mục bài liên quan theo dịch vụ, để phòng khám xây dựng dần thư viện nội dung đón khách từ Google. Nếu phần blog trong demo trông như phần phụ bị bỏ quên, đó là dấu hiệu mẫu này được thiết kế cho ngành khác rồi gắn nhãn nha khoa.

Cách đối chiếu với mẫu số 4

Mở trang theme phòng khám nha khoa và đi qua bản demo của mẫu bằng đúng 5 điểm trên: trang dịch vụ tách riêng chưa, khung thuyết phục trong trang dịch vụ đủ chưa, luồng đặt lịch đi tới form hẹn giờ hay chỉ tới trang liên hệ, trải nghiệm điện thoại ra sao, và phần blog có tử tế không. Mẫu nào đạt cả năm, bạn gần như không phải thuê người sửa lại cấu trúc — chỉ cần thay nội dung và hình ảnh của phòng khám mình vào.

Kết lại

Đọc một mẫu giao diện nha khoa đừng bắt đầu từ trang chủ. Hãy bắt đầu từ trang dịch vụ và cái form đặt lịch — hai nơi quyết định phòng khám có thêm bệnh nhân hay không. Năm điểm kiểm tra trong bài là đủ để phân biệt một mẫu dựng cho ngành nha thật sự với một mẫu đa năng đội lốt nha khoa, và áp dụng được cho bất kỳ mẫu nào bạn đang cân nhắc, không riêng mẫu số 4.

Landing page bán khoá học/sản phẩm: cấu trúc 1 trang chuyển đổi cao

Anh Nguyen Duc — Sun, 15 Nov 2026 14:57:06 +0000

Một landing page chỉ có đúng một việc: biến người xem thành người mua hoặc người để lại thông tin. Không menu dài, không bài viết lan man, không lối rẽ. Vậy mà phần lớn landing page thất bại không phải vì sản phẩm dở, mà vì cấu trúc trang đẩy khách ra ngoài trước khi họ kịp hiểu mình được gì.

Bài này là khung cấu trúc mình dùng khi dựng hoặc rà soát một landing page bán khoá học hay sản phẩm số — theo đúng thứ tự cuộn trang của khách, từ lúc họ chạm đất tới lúc bấm nút mua.

Khối 1: Lời hứa rõ ràng trong 5 giây đầu

Đầu trang chỉ cần trả lời một câu: "Tôi học/mua xong thì được gì cụ thể?" Một tiêu đề nêu kết quả cuối cùng, một dòng phụ làm rõ đối tượng và thời gian, và một nút mua/đăng ký nhìn thấy ngay không cần cuộn. Sai lầm thường gặp là tiêu đề kiểu slogan chung chung ("Vươn tới thành công cùng chúng tôi") — khách không mua slogan, họ mua kết quả đo được.

Nếu có một con số đáng tin — số học viên, số năm kinh nghiệm của giảng viên, tỉ lệ hoàn thành — hãy đặt một con số đó ở đây. Chỉ một, đừng bày cả dãy huy chương.

Khối 2: Nỗi đau và sự đồng cảm — ngắn nhưng đúng

Ngay sau lời hứa, một đoạn ngắn mô tả đúng tình trạng hiện tại của khách: đã tự học rời rạc mãi không hệ thống, mua sách về để đó, xem video miễn phí mà không làm được. Mục đích của khối này không phải để bán, mà để khách gật đầu "đúng mình rồi". Viết bằng ngôn ngữ khách dùng để than với bạn bè, không phải ngôn ngữ marketing.

Khối này chỉ nên dài vài gạch đầu dòng. Kéo dài quá, trang thành bài tâm sự và khách chán trước khi thấy giải pháp.

Khối 3: Sản phẩm/khoá học gồm những gì — liệt kê cụ thể

Đây là khối khách đọc kỹ nhất. Với khoá học: số bài, số giờ, học qua hình thức nào, có bài tập và sửa bài không, học trên điện thoại được không, có cộng đồng học viên không. Với sản phẩm số: file gồm những gì, định dạng, dùng được trên thiết bị nào, cập nhật ra sao.

Nguyên tắc: cụ thể thắng hoa mỹ. "36 bài học, 9 giờ video, 12 file bài tập có lời giải" thuyết phục hơn "khoá học toàn diện, chuyên sâu" rất nhiều. Kèm ảnh chụp thật bên trong sản phẩm — mục lục khoá học, một trang tài liệu — để khách thấy thứ họ sắp mua là có thật.

Khối 4: Bằng chứng xã hội — ít mà thật

Đánh giá của học viên/khách hàng cũ, kèm tên và bối cảnh cụ thể ("chị H., kế toán, học để chuyển sang làm freelancer"). Ảnh chụp màn hình tin nhắn cảm ơn thật (đã xin phép) có sức nặng hơn hẳn những đoạn nhận xét viết sẵn bóng bẩy. Nếu sản phẩm mới chưa có học viên, hãy thành thật dùng bằng chứng thay thế: kinh nghiệm của người dạy, sản phẩm mẫu miễn phí, hoặc cho học thử một phần.

Tuyệt đối tránh con số bịa. Một landing page bị phát hiện bịa đánh giá sẽ mất luôn uy tín của người bán, không chỉ của trang đó.

Khối 5: Giá, ưu đãi và giảm rủi ro

Trình bày giá rõ ràng: giá gốc, giá hiện tại (nếu giảm thật, ghi rõ giảm tới khi nào), và quan trọng nhất — chính sách hoàn tiền hoặc học thử. Với khoá học và sản phẩm số, cam kết hoàn tiền trong 7–14 ngày nếu không phù hợp là đòn bẩy chuyển đổi mạnh nhất, vì nó chuyển toàn bộ rủi ro từ người mua sang người bán.

Nếu có nhiều gói, bảng so sánh 2–3 gói với gói giữa được làm nổi bật là cấu trúc kinh điển mà hiệu quả. Đừng bày 5 gói — khách phân vân là khách rời đi.

Khối 6: Câu hỏi thường gặp — dọn đường cho cú bấm cuối

Liệt kê 5–7 câu hỏi chặn đứng quyết định mua: học không hiểu thì sao, không có thời gian thì sao, thanh toán thế nào, nhận sản phẩm/khoá học bằng cách nào, có hỗ trợ sau mua không. Trả lời ngắn, thẳng, không né tránh điều kiện bất lợi. Ngay sau khối này là nút mua cuối cùng — đặt ở đây vì đây là điểm khách đã hết lý do từ chối hợp lý.

Yếu tố kỹ thuật: nhanh, một mục tiêu, đo được

Ba yêu cầu kỹ thuật không thể thiếu: trang tải nhanh trên điện thoại (phần lớn traffic đến từ quảng cáo mobile); toàn trang chỉ có một hành động chính duy nhất lặp lại ở các nút; và gắn đo lường để biết khách rời ở khối nào. Khi dựng bằng WordPress, một giao diện landing page chuyên dụng sẽ giúp nhiều: nó loại bỏ sẵn menu, sidebar và các yếu tố gây xao nhãng, chừa đúng khung một cột cho cấu trúc trên. Bạn có thể xem các mẫu theme WordPress landing page và đối chiếu xem mẫu nào để sẵn đủ 6 khối này.

Kết lại

Landing page chuyển đổi cao không phải trang đẹp nhất, mà là trang có thứ tự đúng: hứa rõ, đồng cảm ngắn, sản phẩm cụ thể, bằng chứng thật, giá minh bạch kèm giảm rủi ro, và hỏi đáp dọn đường cho nút mua cuối. Cứ rà mọi landing page theo đúng 6 khối này, bạn sẽ thấy ngay trang của mình đang rò khách ở khối nào.

Cách mình rà soát một website WordPress bị chậm (audit thực tế)

Anh Nguyen Duc — Sun, 15 Nov 2026 14:06:41 +0000

Có một kiểu tin nhắn mình nhận khá thường xuyên: "Anh ơi, web em dạo này chậm lắm, anh xem giúp em với." Nghe thì đơn giản, nhưng nếu lao ngay vào cài thêm plugin cache, nén ảnh hàng loạt hay đổi hosting, rất dễ sửa sai chỗ. Website vẫn chậm, mà mình còn không biết thứ vừa thay đổi có thật sự tác dụng hay không.

Sau vài lần mò mẫm như vậy, mình rút ra một quy trình tương đối cố định. Không có gì cao siêu, chủ yếu là đi từ ngoài vào trong, từ phần dễ quan sát đến phần khuất trong database và cấu hình máy chủ. Bài này là cách mình audit một site WordPress bị chậm trước khi quyết định tối ưu cái gì.

Trước khi sửa bất cứ thứ gì: ghi lại hiện trạng

Mình mở trang chủ, một bài viết, một trang sản phẩm hoặc dịch vụ, rồi thử trên máy tính và điện thoại, ở trạng thái đã đăng nhập và chưa đăng nhập. Mình cũng hỏi chủ site: chậm từ khi nào, chậm ở trang nào nhất, chậm khi xem web hay khi đăng bài, và gần đây có cài plugin, đổi theme hay gắn thêm công cụ quảng cáo nào không.

Nhiều khi câu trả lời đã chỉ ra một nửa nguyên nhân. Ví dụ, web chỉ chậm sau khi thêm chat, popup và mã theo dõi thì hướng kiểm tra sẽ khác hẳn web chậm dần theo thời gian vì dữ liệu ngày càng nhiều. Đừng quên sao lưu trước khi thử nghiệm. Chỉ cần một bản backup đầy đủ và biết cách khôi phục, mình sẽ yên tâm hơn khi tắt thử plugin hay đổi cấu hình sau này.

Mình thường tổng hợp các bước dưới đây thành một checklist WordPress performance audit để mỗi lần nhận site mới cứ đi theo thứ tự, vừa tránh bỏ sót, vừa dễ giải thích lại cho chủ site khi làm xong.

Bước 1: Phân biệt chậm ở frontend hay backend

Câu hỏi quan trọng nhất lúc này là: web chậm vì máy chủ phản hồi chậm, hay vì trình duyệt phải tải và xử lý quá nhiều thứ? Nếu vào wp-admin cũng ì ạch, mở danh sách bài viết hay đơn hàng đều phải chờ, vấn đề thường nằm ở hosting, database hoặc một plugin chạy ngầm. Ngược lại, nếu admin vẫn mượt mà trang ngoài nặng, mình ưu tiên xem hình ảnh, script, font và cách theme dựng giao diện.

Đừng chỉ kiểm tra trang chủ

Mình thử thêm trang có nhiều hình, trang có form, trang tìm kiếm và trang thanh toán nếu là web bán hàng. Nếu trang nào cũng chậm giống nhau, mình nghi ngờ phần dùng chung như hosting, theme hoặc plugin chạy trên toàn site. Nếu chỉ một trang bị chậm, mình tập trung vào nội dung, tính năng riêng và các đoạn mã nhúng chỉ xuất hiện trên trang đó.

Ở bước này, mình hay mở DevTools và các công cụ đo tốc độ để nhìn tổng quan, nhưng không vội tin tuyệt đối vào một điểm số. Điểm số chỉ là gợi ý, còn trải nghiệm thực tế mới giúp mình quyết định nên đào sâu vào đâu.

Bước 2: Xem hosting, PHP và cấu hình nền

Mình vào bảng điều khiển hosting để xem phiên bản PHP có quá cũ không, giới hạn bộ nhớ có quá thấp so với loại site đang chạy không, ổ đĩa có gần đầy và chứng chỉ hay cấu hình máy chủ có gì bất thường không. Nhiều web chạy ổn trên cấu hình cũ cho đến khi theme hoặc plugin cập nhật, bắt đầu nặng hơn, lúc đó các giới hạn cũ mới lộ ra.

Mình cũng kiểm tra xem site có bật nén dữ liệu, cache ở cấp máy chủ và giao thức kết nối hiện đại hay chưa. Tuy vậy, mình không coi việc nâng cấp hosting là đáp án cho mọi vấn đề. Nếu nguyên nhân là plugin nặng hoặc database phình to, đổi hosting cũng không giải quyết được gốc rễ.

Bước 3: Rà soát theme và plugin

Đây thường là phần tốn thời gian nhất, nhưng cũng hay tìm thấy nguyên nhân nhất. Với plugin, mình không nhìn số lượng trước. Một site ít plugin vẫn có thể chậm nếu có một plugin làm việc nặng, ngược lại site nhiều plugin chưa chắc đã chậm nếu chúng đều cần thiết và nhẹ.

Mình đi qua từng nhóm chức năng: builder, bảo mật, sao lưu, thống kê, chat, popup, dịch tự động, tối ưu ảnh và những plugin đã lâu không cập nhật. Plugin nào trùng chức năng, không còn dùng hoặc chỉ bật trong một chiến dịch cũ thì mình đề xuất gỡ hẳn, thay vì chỉ để đó và tắt tạm.

Cách mình test plugin mà không làm vỡ site

Nếu có staging, mình tắt thử theo nhóm trên staging, ghi lại thay đổi sau mỗi vòng và kiểm tra kỹ các trang quan trọng. Nếu không có staging, mình làm ngoài giờ ít truy cập, có backup trong tay và thông báo trước cho chủ site. Riêng plugin liên quan đến WooCommerce, form và thanh toán, mình không bao giờ tắt bừa.

Với theme, mình chú ý các dấu hiệu như theme ôm quá nhiều tính năng không dùng đến, slider và hiệu ứng xuất hiện khắp nơi, hoặc child theme bị chỉnh sửa chồng chéo qua nhiều người. Nhiều trường hợp không cần đổi theme, chỉ cần tắt tính năng thừa và dọn lại trang chủ là trang đã nhẹ đi rõ rệt.

Bước 4: Ảnh, font và mã nhúng bên ngoài

Mình xem ảnh ở các trang nặng nhất: có ảnh nào đang dùng kích thước gốc cho một khung hiển thị nhỏ không, font có tải thừa kiểu và độ đậm không. Mình cũng kiểm tra video nhúng, chat, bản đồ và pixel quảng cáo, vì chúng thường được thêm theo từng chiến dịch rồi bị quên, nhưng vẫn làm trang nặng thêm.

Bước 5: Database, cron và autoload

Nếu admin chậm, mình kiểm tra thêm database: dữ liệu autoload có phình bất thường không, bản sửa đổi cũ, bình luận spam và dữ liệu tạm của plugin đã gỡ còn sót lại không. Mình cũng xem các tác vụ chạy tự động có bị dồn, lỗi hoặc chạy lặp không. Phần này mình làm cẩn thận, sao lưu database riêng và không xoá hàng loạt theo cảm tính.

Bước 6: Cache và kiểm tra lại sau khi sửa

Cache mình để gần cuối, vì cache chỉ che được triệu chứng nếu bên dưới vẫn nặng. Khi bật, mình kiểm tra riêng cho khách chưa đăng nhập, người đã đăng nhập và giỏ hàng, tránh việc trang nhanh hơn nhưng form hay thanh toán lại hoạt động sai. Sau mỗi nhóm thay đổi, mình tải lại các trang đã ghi ở đầu và đối chiếu với hiện trạng ban đầu.

Lời kết

Tóm lại, audit WordPress bị chậm không phải là cuộc đua cài thêm công cụ. Đó là quá trình loại trừ có thứ tự: hiểu trang nào chậm, chậm ở đâu, vì sao, rồi mới sửa đúng chỗ và kiểm tra lại. Cách làm này đỡ tốn công sửa đi sửa lại, và giúp mình giải thích rõ cho chủ site đã thay đổi điều gì, vì sao điều đó cần thiết.

Checklist tối ưu tốc độ WordPress: 9 việc mình luôn làm cho mọi website mới

Anh Nguyen Duc — Wed, 11 Nov 2026 04:16:29 +0000

Một website WordPress chậm thường không chậm vì một nguyên nhân lớn, mà vì nhiều thứ nhỏ cộng lại: theme nặng, ảnh chưa nén, plugin chồng chất, không có cache. Sau nhiều lần dựng web cho khách, mình rút ra một checklist cố định gồm 9 việc — làm đúng thứ tự này, đa số website đều cải thiện rõ điểm PageSpeed mà không cần đụng vào code.

1. Bắt đầu từ hosting và phiên bản PHP

Tốc độ xử lý phía máy chủ quyết định "trần" hiệu năng của cả website. Hai việc cơ bản nhất:

Chọn hosting có ổ SSD/NVMe và máy chủ đặt gần người dùng chính (web cho khách Việt Nam thì ưu tiên server Việt Nam hoặc Singapore).
Luôn chạy PHP phiên bản mới nhất mà theme/plugin hỗ trợ (PHP 8.2/8.3 nhanh hơn hẳn PHP 7.4 trong các bài đo thực tế). Nhiều người bỏ qua bước này rồi cài đủ loại plugin tăng tốc — hiệu quả rất hạn chế vì nền đã yếu.

2. Chọn theme nhẹ ngay từ đầu

Theme là bộ khung của toàn bộ website. Một theme cồng kềnh, nhồi quá nhiều hiệu ứng sẽ khiến mọi nỗ lực tối ưu về sau khó gấp đôi. Tiêu chí của mình khi chọn theme:

Dung lượng trang demo tải nhanh, điểm PageSpeed của bản demo tốt.
Chỉ dùng các tính năng thật sự cần, tránh theme "tất cả trong một" nhưng bật gì cũng chậm.
Được cập nhật thường xuyên, tương thích phiên bản WordPress mới. Nếu đang tìm theme cho web bán hàng hoặc web doanh nghiệp, bạn có thể tham khảo kho theme WordPress có sẵn bản demo để tự kiểm tra tốc độ trước khi quyết định — cứ mở demo và đo bằng PageSpeed Insights, số liệu sẽ nói rõ hơn mọi lời quảng cáo.

3. Bật cache trang

Cache biến trang động thành file HTML tĩnh để phục vụ ngay, giảm tải cho máy chủ. Các plugin phổ biến như WP Rocket (trả phí), LiteSpeed Cache (miễn phí, rất mạnh nếu hosting dùng LiteSpeed) hay W3 Total Cache đều làm tốt. Chỉ cần bật page cache đúng cách, thời gian phản hồi thường giảm đi thấy rõ.

4. Tối ưu hình ảnh trước khi tải lên

Ảnh thường chiếm phần lớn dung lượng trang. Thói quen tốt:

Resize ảnh về đúng kích thước hiển thị, đừng tải ảnh 4000px cho khung 800px.
Chuyển sang định dạng WebP (nhẹ hơn JPEG khoảng 25–35% ở cùng chất lượng).
Nén bằng công cụ như TinyPNG hoặc plugin ShortPixel/Imagify nếu kho ảnh lớn.

5. Gỡ plugin không cần thiết

Mỗi plugin là thêm code phải tải và thêm một bề mặt lỗi bảo mật. Cứ mỗi quý, mình rà soát lại danh sách plugin: cái nào không dùng nữa thì xoá hẳn (không chỉ tắt). Đặc biệt tránh cài 2 plugin cùng chức năng — ví dụ 2 plugin cache hoặc 2 plugin SEO.

6. Dọn cơ sở dữ liệu định kỳ

Sau một thời gian, database phình ra vì các bản nháp tự động lưu, bình luận spam, transient hết hạn. Plugin như WP-Optimize giúp dọn các phần này an toàn. Nhớ sao lưu trước khi dọn.

7. Dùng CDN nếu có khách ở nhiều khu vực

Nếu người dùng phân tán nhiều tỉnh thành hoặc nhiều quốc gia, CDN như Cloudflare (có gói miễn phí) giúp phân phối file tĩnh từ máy chủ gần họ nhất, đồng thời chặn bớt truy cập xấu.

8. Bật lazy load và trì hoãn JavaScript

Lazy load khiến ảnh/video chỉ tải khi người dùng cuộn tới — WordPress đã hỗ trợ sẵn cho ảnh từ phiên bản 5.5. Với JavaScript, các plugin cache tốt đều có tuỳ chọn "delay/defer JS" giúp trang hiển thị nội dung chính trước, script phụ tải sau.

9. Đo lại và ghi chép

Sau mỗi thay đổi lớn, đo lại bằng PageSpeed Insights và Google Lighthouse, ghi lại con số trước/sau. Việc ghi chép giúp bạn biết thay đổi nào thực sự có tác dụng, thay vì "cảm giác nhanh hơn".

Kết luận

Tối ưu tốc độ WordPress không phải việc làm một lần cho xong, nhưng 9 bước trên là phần nền: hosting ổn, theme nhẹ, cache đúng, ảnh gọn, plugin ít. Làm chắc phần nền này, website của bạn đã nhanh hơn phần lớn các web WordPress mặc định — và người dùng (cũng như Google) sẽ cảm nhận được.