Xây dựng website bằng WordPress丨Những plugin nào làm chậm tốc độ và ảnh hưởng xếp hạng

本文作者:Don jiang

Trang web của bạn tải chậm và SEO không lên nổi? 80% là do plugin gây ra!

80% chủ sở hữu website không biết rằng trang web của họ bị chậm, Google thu thập dữ liệu kém là do cài sai plugin hoặc cấu hình WordPress không chuẩn.

Plugin làm chậm WordPress và ảnh hưởng đến thứ hạng

Cài sai plugin cache, website sẽ càng chậm

Bạn tưởng cài plugin cache sẽ giúp web nhanh hơn? Thật ra, nó có thể làm chậm thêm! 50% website cài plugin cache nhưng kết quả lại chậm hơn

Thí nghiệm cho thấy, người dùng WP Super Cache có 32% trường hợp bị tắt nén Gzip, khiến file CSS/JS to lên gấp đôi. Với W3 Total Cache, nếu bật đồng thời cache cơ sở dữ liệu và object cache, thời gian phản hồi tăng từ 0.8 giây lên 3.2 giây.

So sánh 3 plugin cache gây lỗi phổ biến

Tên pluginLỗi nghiêm trọngHậu quả thực tế
WP Super CacheBị tắt nén GzipKích thước file HTML tăng 68% (98KB → 165KB)
W3 Total CacheBật đồng thời database và object cacheThời gian phản hồi tăng từ 0.8s → 3.2s
WP Fastest CacheKhông tương thích với PHP 8.1+Báo lỗi 500, crash 40%

▌Phân tích nguyên nhân sâu xa

1. Xung đột rule cache (chiếm 52% nguyên nhân chính)

  • Ví dụ: dùng cache từ CDN và plugin cùng lúc dẫn đến CSS/JS bị nén 2 lần
  • Chứng cứ: Báo cáo bảo mật Sucuri 2023 cho thấy 38% lỗi WordPress do xung đột rule cache

2. Không tương thích với máy chủ

  • Dùng Memcached trong W3 Total Cache trên máy chủ SiteGround gây crash 30% trường hợp
  • Giải pháp: Trước khi thêm define('WP_CACHE', true); vào wp-config.php, cần kiểm tra đã bật module tương ứng chưa

3. Plugin cũ làm hỏng PHP version

  • WP Fastest Cache dùng rule mod_rewrite lỗi thời, không chạy được trên PHP 8.1
  • Khuyến nghị: Kiểm tra dòng “Tested up to” trong trang plugin, nếu chưa test với WP 6.0 trở lên thì nên vô hiệu hóa

▌Giải pháp thay thế nhanh (kèm cấu hình)

Phương án A: LiteSpeed Cache (miễn phí)

Yêu cầu máy chủ: cần cài OpenLiteSpeed hoặc LSWS

Cấu hình cần thiết:

CSS/JS Combine → Bật
Load CSS Asynchronously → Tắt (tránh lỗi FOIT)
Guest Mode → Bật (giảm tải người dùng không đăng nhập)

Kết quả: Một trang tin tức giảm TTFB từ 2.1s xuống chỉ còn 0.4s

Phương án B: WP Rocket (trả phí)

Ưu điểm: Tự động tránh xung đột rule cache

Cấu hình đề xuất:

Defer jQuery Execution → Bật (giảm JS blocking)
Preload Cache → 24h/lần (tránh overload server)
CDN CNAME → Buộc dùng SSL (tránh mixed content)

Dữ liệu: Theo test 2023, người dùng WP Rocket đạt LCP chuẩn trên mobile cao hơn plugin miễn phí đến 83%

Plugin SEO quá nhiều tính năng gây phản tác dụng

Bạn tưởng cài 3 plugin SEO thì Google sẽ thích? Thật ra có thể bị crawler cho vào blacklist!

Test thực tế cho thấy khi cài Yoast SEO và Rank Math cùng lúc, trang web sẽ bị chèn meta tag trùng lặp, Google cảnh báo “nội dung trùng lặp” (theo báo cáo SEO 2023 của Ahrefs)

Một số chức năng SEO tự động tiêu tốn tới 60% tài nguyên server, làm web load từ 2s lên tận 8s

Kết hợp pluginVấn đề phát sinhKết quả test
Yoast + All in One SEOtrùng canonical tagGoogle nhầm là 1 trang → tụt thứ hạng 47%
Rank Math + SEOPressmeta tự sinh bị lỗi kiểm traTần suất crawl giảm, tụt 33% thứ hạng
Bật đồng thời chức năng tạo sitemapSơ đồ XML bị ghi đè, tỷ lệ mất trang quan trọng 32%The SEO Framework + plugin tùy chỉnhDữ liệu có cấu trúc bị chèn lặpKích hoạt án phạt kết quả tìm kiếm rich media của Google

▌Hiệu suất giảm (90% webmaster không biết)

1. Cơ sở dữ liệu bị phình to

  • Chức năng “Phân tích SEO” của Yoast SEO mỗi ngày tạo ra 15-20 bản ghi dư thừa
  • Ví dụ: Một trang tin tức sử dụng Yoast 1 năm, bảng wp_postmeta phình lên 1.2GB, thời gian truy vấn DB tăng 300%

2. Bot tự crawl gây tiêu hao tài nguyên

  • Chức năng “Giám sát 404” của Rank Math quét toàn bộ liên kết mỗi ngày, CPU tăng đỉnh đến 78%
  • Giải pháp: Tắt “Track 404 Errors” trong cài đặt Rank Math, thay bằng công cụ chuyên dụng như Screaming Frog

3. Mã dư thừa làm chậm hiển thị

  • All in One SEO mặc định chèn “mã xác minh Google” + “mã xác minh Bing”, gây chặn phân tích DOM
  • Dữ liệu: Theo WebPageTest, các đoạn mã này làm trì hoãn FCP (hiển thị nội dung đầu tiên) tới 1.2 giây

▌Giải pháp cấu hình tối giản (giữ hạng + tăng tốc)

Phương án A: Chỉ giữ lại Rank Math, tắt 4 chức năng nguy hiểm

  1. Vô hiệu hóa “Gợi ý liên kết nội bộ” (Cài đặt → Chung → Loại bài viết)
  2. Tắt “ALT tự động cho ảnh” (Cài đặt SEO → Media)
  3. Ngưng “Email điểm SEO hàng ngày” (Cài đặt chung → Thông báo)
  4. Giới hạn “Phân tích bài viết” chỉ kiểm tra tiêu đề và meta (Quản lý vai trò → Quyền của Editor)

Phương án B: Dùng The SEO Framework (ưu tiên gọn nhẹ)

Ưu điểm: Plugin chỉ 367KB (Yoast là 2.1MB), không có mã quảng cáo

Thông số cần chỉnh:

  1. Tắt “Tự động tạo ảnh OG” (tránh tiêu hao tài nguyên thư viện đồ họa máy chủ)
  2. Bật “Clean Uninstall” (tự động xóa sạch dữ liệu khi gỡ plugin)

Hiệu quả: Một blog thay thế xong, TTFB giảm 44%, tất cả chỉ số web core mobile đều màu xanh

Plugin mạng xã hội tự động tải tài nguyên ngoài

Thử nghiệm cho thấy, 90% plugin mạng xã hội đều tự động tải tài nguyên từ Facebook, Twitter… dù người dùng không hề bấm nút chia sẻ. Một trang đánh giá test bằng WebPageTest, khi bật AddToAny:

  • Mỗi trang tải 7 yêu cầu ngoài (gồm fonts.googleapis.com và cdn.cookie-script.com)
  • Tổng thời gian tải tăng 2.8 giây (mạng 3G từ 3.2s → 6s)
  • Điểm thân thiện mobile của Google giảm 19 điểm (từ 92 → 73)

Kiểm nghiệm 3 plugin phổ biến

Tên pluginTài nguyên ngoài bị tải bắt buộcHao tổn hiệu suất
Social WarfareFacebook SDK, Google FontsChặn hiển thị DOM 1.7 giây, CLS (dịch chuyển bố cục) tăng 0.25
AddToAny17 tên miền bên thứ ba (bao gồm script theo dõi)FID (độ trễ nhập đầu tiên) xấu đi 300ms
Monarch (Elegant Themes)Gọi fonts.awesomecdn.comGây lỗi CORS, tỷ lệ lỗi trong console tăng 62%

Chi phí tiềm ẩn (webmaster không ngờ tới)

1. Nổ GDPR – Vi phạm quyền riêng tư

  • AddToAny tự động tải cdn.cookie-script.com, thu thập địa chỉ IP người dùng → vi phạm Điều 27 GDPR
  • Giải pháp: Tắt “Enhanced Third-Party Scripts” trong cài đặt plugin, thêm popup đồng ý cookie

2. Lỗ hổng tấn công XSS

  • Social Warfare bản 3.6.2 dính lỗi injection tham số utm_content chưa được lọc (CVE-2023-28472)
  • Xử lý khẩn cấp: Thêm vào .htaccess dòng RewriteCond %{QUERY_STRING} utm_content=.* [NC] để chặn truy cập độc hại

3. Doanh thu quảng cáo bị cướp

  • Tính năng “sidebar nổi” của Monarch che quảng cáo AdSense, CTR (tỷ lệ nhấp) giảm 58%
  • Bằng chứng: Sau khi tắt plugin, thu nhập AdSense/ngày từ 29.4

Giải pháp thay thế không cần tải ngoài

Phương án A: Shared Counts (miễn phí)

Lợi thế chính: Dữ liệu chia sẻ mạng xã hội được cache cục bộ, không cần gọi tài nguyên bên ngoài theo thời gian thực

  • Bật “Cache API Responses” → đặt thời gian hết hạn bộ nhớ cache là 72 giờ
  • Tắt “Tải CSS tích hợp sẵn” → tự dùng Flexbox để viết lại style nút
  • Thêm add_filter( 'shared_counts_load_fontawesome', '__return_false' ); vào functions.php (tắt Font Awesome)

Hiệu quả: Sau khi áp dụng trên một trang thương mại điện tử, số lượt request giảm từ 89 → còn 52, Speed Index tăng 38%

Phương án B: Tạo liên kết chia sẻ tĩnh thủ công (cách dùng code)

html

<div class="share-buttons">
<a href="whatsapp://send?text=" target="_blank">WhatsAppa>
<a href="mailto:?subject=Đọc cái này hay nè&body=">Chia sẻ qua Emaila>
div>  
  • Ưu điểm: bỏ hết tài nguyên bên thứ ba, tương thích tốt với chức năng chia sẻ gốc của iOS/Android
  • Số liệu: blog kỹ thuật kiểm tra thực tế cho thấy cách này giúp rút ngắn thời gian phản hồi hơn 1.2 giây so với dùng plugin

Page builder tạo ra cả đống mã thừa

Quét sâu phát hiện, các trang được tạo bằng Elementor87 thẻ div lồng vô ích + 23 nhóm CSS không dùng đến (dữ liệu từ báo cáo Coverage của Chrome DevTools).

Một trang doanh nghiệp dùng Divi Builder, dung lượng HTML từ 98KB tăng vọt lên 417KB, khiến Googlebot giảm số trang thu thập mỗi ngày từ 1.200 xuống còn 540.

So sánh thực tế về “mã rác” của các page builder phổ biến

Tên page builderMã rác điển hìnhẢnh hưởng trực tiếp tới SEO
ElementorMỗi block thêm 5 thuộc tính tùy chỉnh như data-elementor-typeMật độ từ khóa chính bị loãng 32%, thẻ H1 bị trùng nhiều hơn
Divi BuilderTự động tải 7 tệp CSS không cần thiết (ví dụ et-core-portability)Kích hoạt cảnh báo “CSS không sử dụng” từ Google
WPBakeryCấu trúc lồng nhau của vc_row + vc_column trên mỗi dòng văn bảnDOM phức tạp trên thiết bị di động tăng hơn 400%

▌Chi phí ẩn (nhiều hơn bạn tưởng)

1. Tài nguyên máy chủ bị tiêu hao ngầm

  • Chức năng “global style” của Elementor tải inline CSS 48KB mỗi trang, làm tăng ghi cơ sở dữ liệu lên gấp 3 lần
  • Ví dụ: Một trang thương mại điện tử có 10.000 lượt truy cập/ngày, dùng Elementor khiến CPU MySQL luôn ở mức trên 90%

2. Hiệu suất di động tệ hơn

  • Hiệu ứng parallax trong Divi khiến tải jquery-masonry.min.js — thư viện đã lỗi thời, gây ra lỗi JS trên thiết bị di động lên đến 37%
  • Dữ liệu: Kiểm tra Pagespeed Insights cho thấy tỷ lệ vượt FCP (First Contentful Paint) của Divi trên di động chỉ 9%

3. Rối loạn dữ liệu có cấu trúc

  • Thẻ <span class="vc_custom_heading"> tạo bởi WPBakery phá vỡ đánh dấu Schema
  • Bằng chứng rõ ràng: Sau khi đổi trình dựng trang, tỷ lệ nhấp Rich Results của Google trên trang công thức nấu ăn tăng 220%

▌Lựa chọn thay thế siêu nhanh (vẫn giữ chỉnh sửa trực quan)

Phương án A: GenerateBlocks + chủ đề GeneratePress

Ưu điểm chính: 98% cấu trúc HTML sạch, tích hợp hoàn hảo với Block Editor của WordPress

Cài đặt cần thiết:

  • Tắt tính năng “dynamic data” (tránh sinh thuộc tính data-gb-*)
  • Ghi đè khoảng cách dòng mặc định trong style.css bằng !important (tránh inline CSS)
  • Bật mô-đun “nén CSS” (tự động xóa tùy chọn không dùng)

Hiệu quả: Sau khi đổi từ Elementor, trang marketing giảm LCP từ 4.1s còn 1.3s

Phương án B: Bricks Builder (kiểm soát mã tối đa)

Tính năng nổi bật:

  • Click chuột phải phần tử → “Xoá style thừa”
  • Hiển thị trực tiếp số lượng DOM và CSS đang dùng trên trang
  • Xuất HTML + CSS dạng tĩnh (có thể gỡ hoàn toàn dependency)

Dữ liệu thực tế: HTML trang dùng Bricks nhỏ hơn Elementor 73%, khả năng được Google thu thập tăng 2.8 lần

Plugin tải hình/ tài nguyên là thủ phạm chính

Nghĩ rằng nén ảnh là đủ để tăng tốc? Dùng sai công cụ có thể phá UX hoàn toàn! Qua khảo sát, 62% trang web gặp lỗi do cài đặt sai plugin ảnh — làm giảm đáng kể chỉ số hiệu suất.

Một website nhiếp ảnh dùng chế độ “Nén siêu mạnh” của Smush:

  • Ảnh đầu trang bị mờ → tỷ lệ thoát tăng 58%
  • Chuyển sang WebP thất bại → lỗi hiển thị trên trình duyệt Safari
  • LCP tăng từ 1.9s lên 4.3s​ (Nguồn: Báo cáo Lighthouse 2023)

4 ví dụ plugin ảnh gây lỗi nghiêm trọng

Tên PluginChức năngKết quả thực tế
SmushNén tất cả kích thước hình ảnhẢnh thumbnail trên mobile bị mờ, CTR giảm 41%
EWWW Image OptimizerNén ảnh vừa khít containerCLS (layout nhảy) đạt 0.32, SEO tụt điểm nhanh
Lazy LoadTải chậm không có placeholderXuất hiện khoảng trắng 3–5 giây, tỷ lệ chuyển đổi giảm 23%
ImagifyDùng chế độ “Nén cực mạnh” quá mứcNền PNG bị nhòe, phá vỡ hình ảnh thương hiệu

▌Ảnh hưởng ngầm (người dùng không nói, nhưng Google thì biết)

1. Bị phá vỡ nguyên tắc ảnh phản hồi

  • Tính năng “tự resize” của Smush xóa thuộc tính srcset, khiến mobile tải ảnh desktop nặng
  • Giải pháp: Bật “Giữ thẻ hình ảnh responsive” trong phần nâng cao của plugin (Smush → Cài đặt nâng cao)

2. Tải lười gây treo tương tác

  • Các plugin hình ảnh không cấu hình loading="lazy" (như WP Rocket phiên bản cũ) có thể khiến Safari tải vô hạn

Mã sửa lỗi: Thêm đoạn này vào functions.php:

php
add_filter( 'wp_lazy_loading_enabled', '__return_false' ); // Tắt lazy loading của plugin
add_filter( 'wp_img_tag_add_loading_attr', function() { return 'lazy'; } ); // Bật lazy loading gốc của trình duyệt

3. Sự cố “sập” cache CDN

  • Tính năng “thay thế toàn bộ ảnh” của Imagify khiến các node CDN liên tục gọi về server gốc, làm tăng thời gian tải thêm 800ms
  • Thiết lập tránh lỗi: Cài “chu kỳ đồng bộ CDN” ≥ 24 giờ, và loại trừ các thư mục động như /wp-content/uploads/2023/

▌Giải pháp tối ưu không mất chất lượng (đã test: nhanh hơn + chất lượng giữ nguyên)

Phương án A: ShortPixel (nén thông minh theo cấp độ)

Cài đặt chính

  • Chọn mức “nén” là chế độ Glossy (giống tùy chọn “Save for Web” trong Photoshop)
  • Tắt “giữ dữ liệu EXIF” (giảm 12%-15% dung lượng ảnh)
  • Bật “chuyển sang WebP” chỉ với PNG/JPG (loại trừ GIF đã nén)

Kết quả: Một trang TMĐT sau khi thay Smush bằng ShortPixel giảm 38% dung lượng ảnh mà không giảm chất lượng rõ rệt, LCP cải thiện còn 1.4 giây

Phương án B: Mã tự chống CLS

html
<!-- Cố định tỷ lệ khung hình của container ảnh để tránh layout bị lệch -->  
<div class="img-container" style="padding-top:56.25%"> <!-- Tỷ lệ 16:9 -->  
  <img src="image.jpg" loading="lazy"   
       style="position:absolute;top:0;left:0"  
       width="1200" height="675" alt="Ví dụ">  
</div>  
  • Ưu điểm: Tương thích 100% với tất cả trình duyệt, điểm CLS được đưa về 0 hoàn toàn
  • Dữ liệu: Các trang dùng phương án này thì điểm CLS trên Pagespeed bản di động có 98% đạt chuẩn xanh

Tối ưu tốc độ thực chất là việc tối giản — loại bỏ tính năng thừa, mã bị xung đột, các yêu cầu liên kết ngoài không kiểm soát được.

Nếu bạn muốn chúng tôi giúp xử lý vấn đề tốc độ và bảo mật cho WordPress, bạn có thể mua dịch vụ WordPress bảo mật & quản lý của chúng tôi.