INP WordPress kém: cách tìm plugin gây chậm bằng số đo thật

Muốn biết plugin nào làm INP kém, hãy lấy URL của tác vụ dài rồi đọc thư mục ngay sau /wp-content/plugins/. Đó là tên plugin. Trên trang chủ netsolutions.vn, Lighthouse mobile ngày 10/10/2026 liệt kê 20 tác vụ dài, tổng 13.126 ms. Riêng plugin slider revslider chiếm 9.443 ms, tức 72%. Bài này đi từng bước từ URL đến tên plugin, kể cả chỗ cách quy này bó tay.

INP kém thường bắt nguồn từ một đoạn script chiếm luồng chính

INP đo thời gian từ lúc người dùng bấm, chạm hoặc gõ phím đến khi trang vẽ xong phản hồi. Khi trình duyệt còn bận chạy JavaScript, nó chưa vẽ được. Cú bấm phải chờ. Tác vụ nào chiếm luồng chính quá 50 ms được gọi là tác vụ dài. Trên WordPress, đoạn mã đó thường đến từ plugin, giao diện hoặc thẻ theo dõi.

Google chia INP thành ba mức, tính ở phân vị 75 của lượt tải thật, tách riêng điện thoại và máy tính:

An INP below or at 200 milliseconds means a page has good responsiveness. An INP above 200 milliseconds and below or at 500 milliseconds means a page’s responsiveness needs improvement. An INP above 500 milliseconds means a page has poor responsiveness.

— web.dev — Interaction to Next Paint (INP), 25/10/2026

Hai điểm cần nhớ. Một: INP là số đo thực địa, lấy từ người dùng thật, và chỉ hiện khi trang đủ lượt truy cập. Hai: Lighthouse chạy ở chế độ mặc định, mở trang rồi đo, không có cú bấm nào, nên báo cáo của nó không có INP. Nó cho TBT (Total Blocking Time) và danh sách tác vụ dài. Đó là số đo phòng thí nghiệm. Dùng nó để truy thủ phạm, không dùng nó thay cho INP thật.

Cách đọc LCP, INP và CLS cùng lúc nằm ở bài Core Web Vitals: cách cải thiện. Bài này chỉ làm một việc: đi từ INP kém đến script, rồi từ script đến đúng plugin.

Bước 1: xác nhận INP kém là thật trước khi gỡ bất cứ thứ gì

Mở PageSpeed Insights, nhập URL, đọc khối dữ liệu người dùng thật ở đầu báo cáo. Nếu INP của trang hoặc của cả tên miền trên 200 ms ở phân vị 75, vấn đề có thật. Search Console cho cùng thông tin theo nhóm URL, trong báo cáo Core Web Vitals. Cả hai dùng dữ liệu 28 ngày gần nhất, nên một thay đổi hôm nay phải chờ gần một tháng mới hiện trọn trong số thực địa.

Site ít truy cập thường không đủ dữ liệu để hiện INP. Khi đó bạn chỉ có số lab: TBT và danh sách tác vụ dài. Hãy ghi rõ đó là số lab. Rồi tự bấm thử các nút chính trên điện thoại: menu, form, nút gọi. Trang phản hồi chậm thấy được bằng tay thì đáng sửa. Trang phản hồi nhanh mà Lighthouse đỏ thì chưa chắc.

Trước khi đụng vào site, ghi lại ba thứ: INP thực địa hiện tại nếu có, TBT lab, và ngày đo. Không có mốc trước thì không ai chứng minh được mốc sau tốt hơn. Net Solutions chưa có số INP thực địa riêng cho trang chủ, nên mọi số bên dưới đều là số lab và được ghi rõ như vậy.

Bước 2: lấy danh sách tác vụ dài kèm URL, rồi đọc URL

Có hai nguồn. Một là báo cáo Lighthouse, mở từ PageSpeed Insights hoặc từ DevTools: mục Avoid long main-thread tasks liệt kê 20 tác vụ dài nhất của lượt đo, mỗi tác vụ kèm URL script. Hai là tab Performance của Chrome DevTools: ghi lại lúc tải trang, các khối có góc đỏ là tác vụ dài, bấm vào khối để thấy script chạy trong đó.

URL là manh mối. WordPress xếp tệp theo thư mục, nên phần đầu của đường dẫn cho biết ai sở hữu script:

Quy tắc đọc theo thư mục mặc định của WordPress. Plugin gộp và nén tệp vào thư mục cache sẽ làm mất tên plugin trong URL.

Báo cáo Lighthouse là một lượt mô phỏng. Muốn thấy trên máy thật, dùng Long Animation Frames API (LoAF), có từ Chrome 123. Dán đoạn sau vào Console, tải lại trang rồi bấm thử:

new PerformanceObserver(l => {
  for (const e of l.getEntries())
    for (const s of e.scripts)
      console.log(Math.round(e.duration), Math.round(s.duration), s.sourceURL, s.invoker,
        (s.sourceURL.match(/\/wp-content\/plugins\/([^\/]+)\//) || [, "-"])[1]);
}).observe({type: 'long-animation-frame', buffered: true});

Mỗi dòng in ra năm thứ: thời gian cả khung hình, thời gian riêng của script, URL script, invoker (cách script được gọi) và tên plugin, hoặc dấu gạch nếu không nằm trong thư mục plugin. Chúng tôi chạy thử đoạn này trên Chrome 155, trang chủ netsolutions.vn, ngày 25/10/2026, máy tính để bàn không giả lập CPU.

Một khung 97 ms hiện ba dòng: jQuery 11 ms, mpc-massive 34 ms, contact-form-7 23 ms. Số đầu giống nhau vì ba script cùng một khung. Số thứ hai mới là phần của từng script. Dòng có invoker TimerHandler:setTimeout cho biết mã chạy trong một hàm hẹn giờ, và script đặt hẹn giờ đó có thể là script khác. Nhóm thuộc tính scripts được mô tả trong hướng dẫn Find slow interactions in the field của web.dev.

Trang chủ Net Solutions: một plugin chiếm 72% tác vụ dài

Chúng tôi chạy Lighthouse 12.8.2, mobile, trên trang chủ netsolutions.vn ngày 10/10/2026, rồi chạy lại ngày 25/10/2026. Lighthouse mobile giả lập CPU chậm gấp 4 lần, nên số lab lớn hơn số trên máy để bàn. Lý do nằm ở bài điểm PageSpeed mobile thấp hơn desktop.

Nguồn: Net Solutions đo bằng Lighthouse 12.8.2, mobile, trang chủ netsolutions.vn, một lượt mỗi ngày. Lighthouse chỉ liệt kê 20 tác vụ dài nhất; dấu — là nguồn không có trong 20 tác vụ đó.

Một plugin, revslider, chiếm 9.443 ms, tức 72%. Riêng một tác vụ 7.867 ms của tệp tptools.js bản 6.7.34 đã là 59,9% tổng. Bốn plugin cộng lại được 10.010 ms, 76,3%. Hai thẻ bên thứ ba, Google tag và Facebook, cộng 1.389 ms, 10,6%. Vì vậy chỉ hoãn thẻ quảng cáo thì phần lớn vấn đề vẫn còn.

Bạn có thể lặp lại bảng này với báo cáo của chính mình. Lưu báo cáo bằng lệnh sau (cần Node và Chrome):

npx lighthouse https://ten-mien-cua-ban.vn/ --only-categories=performance --form-factor=mobile \
  --output=json --output-path=bao-cao.json --chrome-flags=--headless=new

Rồi chạy đoạn Python này với tệp vừa lưu. Chính đoạn mã này đã tạo các số trong bảng ở trên:

import json, re, sys
from collections import Counter
from urllib.parse import urlparse


def nhom_tac_vu(duong_dan):
    lhr = json.load(open(duong_dan, encoding="utf-8"))
    trang = urlparse(lhr["finalDisplayedUrl"])
    tong = Counter()
    for t in lhr["audits"]["long-tasks"]["details"]["items"]:
        u = urlparse(t["url"])
        m = re.search(r"/wp-content/plugins/([^/]+)/", u.path)
        if m:
            khoa = "plugin: " + m.group(1)
        elif "/wp-content/themes/" in u.path:
            khoa = "giao diện"
        elif "/wp-includes/" in u.path:
            khoa = "lõi WordPress"
        elif u.netloc == trang.netloc and u.path in ("", "/"):
            khoa = "mã nội tuyến trong HTML"
        elif u.netloc == trang.netloc:
            khoa = "tệp khác cùng tên miền"
        else:
            khoa = u.netloc or t["url"]
        tong[khoa] += t["duration"]
    return tong


if __name__ == "__main__":
    tong = nhom_tac_vu(sys.argv[1])
    cong = sum(tong.values())
    for khoa, ms in tong.most_common():
        print(f"{ms:8.0f} ms  {ms / cong:6.1%}  {khoa}")

Bước 3: tách plugin khỏi thẻ bên thứ ba, vì cách xử lý khác nhau

Tên miền khác trong URL là bên thứ ba. Ở trang chủ NS, mục third-party-summary ghi Google Tag Manager chặn luồng chính 619 ms và Facebook 512 ms (lượt 10/10). Cộng hai số được 1.131 ms; Lighthouse làm tròn tới hàng chục nên hiện 1.130 ms. Lượt 25/10 là 670 ms và 379 ms.

Hai thẻ này nằm ngoài thư mục plugin, nên tắt plugin không làm chúng biến mất. Có ngoại lệ: một số plugin theo dõi tự chèn thẻ vào trang. Khi đó URL vẫn là tên miền ngoài, còn nguồn gốc nằm ở plugin. Hãy kiểm trang quản trị trước khi kết luận.

Hướng dẫn chung; mức rủi ro thay đổi theo từng site.

Bước 4: khi URL không chỉ ra plugin, phải bấm thật hoặc tắt thử

Trang chủ NS có hai chỗ mà phép quy bó tay. Lượt 10/10 có 1.351 ms tác vụ dài (10,3%) mang URL của chính trang, tức mã nội tuyến trong HTML. Mục bootup-time ghi thêm 509 ms “Unattributable”, phần Lighthouse không gán được cho script nào. Lượt 25/10 có 1.287 ms nội tuyến và 248 ms không quy được trong danh sách tác vụ dài. Mã nội tuyến có thể do plugin, giao diện hoặc thẻ theo dõi in ra. URL không nói được.

Cách một là bấm thật. Mở DevTools, tab Performance, bấm Record, bấm vào menu hoặc nút cần kiểm, rồi dừng ghi. Trong track Interactions, chọn cú bấm dài nhất. DevTools tách nó thành độ trễ đầu vào, thời gian xử lý và độ trễ trình bày. Mở Bottom-Up hoặc Call Tree để thấy hàm và tệp chạy lâu nhất trong cú bấm đó.

Cách hai là tắt thử từng plugin trên staging. Sao lưu site, sao chép sang staging, tắt một plugin, đo lại TBT ít nhất ba lượt, ghi số, bật lại, rồi sang plugin kế tiếp. Một thay đổi mỗi lần. Lý do: TBT của cùng trang chủ lệch giữa hai lượt, 10.613 ms rồi 10.950 ms, dù công cụ và cấu hình giống nhau. Mức thay đổi vài phần trăm sau khi tắt một plugin chưa phải bằng chứng.

Bước 5: chọn tắt, hoãn hay thay theo mức đóng góp

Xếp thủ phạm theo phần trăm đóng góp rồi xử lý từ trên xuống. Có ba lựa chọn. Tắt, khi plugin không cần ở trang đó. Hoãn, khi script cần nhưng chưa cần ngay, như thẻ theo dõi hoặc khung chat. Thay, khi plugin cần thật nhưng nặng bất thường so với việc nó làm.

Với trang chủ NS, revslider bản 6.7.34 đứng đầu bảng ở cả hai lượt đo. Đó là kết luận cho một trang, một phiên bản và hai lượt đo. Nó không phải lời khuyên gỡ plugin này khỏi mọi site.

Sau khi sửa, chạy lại Lighthouse để thấy TBT đổi ngay. Rồi chờ 28 ngày để INP thực địa phản ánh đủ. Nếu site của bạn cần người soi, tắt thử và kiểm tay thay bạn, đó là một hạng mục của dịch vụ chăm sóc website.

Điều chúng tôi không làm

Chúng tôi không gỡ plugin chỉ vì Lighthouse đỏ. Nếu INP thực địa của trang đã từ 200 ms trở xuống ở phân vị 75, người dùng đang có trải nghiệm tốt. TBT lab cao khi đó chỉ là một lời nhắc. Chúng tôi cũng không hứa điểm Lighthouse hay mức INP sau khi sửa, vì kết quả phụ thuộc thiết bị của người dùng, nội dung trang và từng lượt đo.

Cách quy script về plugin trong bài chỉ áp dụng cho website WordPress. Site không dùng plugin, hoặc chạy trên nền khác, cần cách đọc khác. Nếu bạn cần soi toàn bộ nền kỹ thuật, không riêng INP, hãy xem audit SEO chuyên sâu.

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

INP bao nhiêu là tốt, bao nhiêu là kém? Theo web.dev, INP từ 200 ms trở xuống là tốt, trên 200 đến 500 ms cần cải thiện, trên 500 ms là kém. Mức này tính ở phân vị 75 của lượt tải thật, tách riêng điện thoại và máy tính. Nghĩa là ba trên bốn lượt truy cập phải đạt ngưỡng thì trang mới được xếp vào mức đó.

Biết plugin nào làm INP kém mà không cài thêm plugin được không? Được. Dùng Lighthouse trong PageSpeed Insights hoặc DevTools để lấy URL tác vụ dài, rồi đọc thư mục sau /wp-content/plugins/. Muốn thấy trên máy thật, dán đoạn mã LoAF ở Bước 2 vào Console của Chrome. Cả hai đều có sẵn trong trình duyệt, không cần cài gì lên website.

Query Monitor có chỉ ra plugin làm INP kém không? Không. Query Monitor đo phần việc PHP và truy vấn cơ sở dữ liệu ở máy chủ, còn INP bị chặn bởi JavaScript chạy trong trình duyệt. Dùng nó khi trang chậm lúc tải. Dùng Lighthouse hoặc DevTools khi trang chậm lúc bấm. Cách dùng Query Monitor có trong bài tại sao website chậm.

Tắt từng plugin để thử có an toàn không? An toàn khi làm trên bản staging có sao lưu, tắt từng plugin một và kiểm tay sau mỗi lần. Đừng tắt hàng loạt trên site đang chạy: plugin thanh toán, bảo mật hoặc SEO có thể làm mất đơn hoặc đổi thẻ meta. Chưa có staging thì nhờ người quản trị site làm giúp.

Hoãn script bên thứ ba có làm mất số đo quảng cáo không? Có thể, nếu hoãn sai. Thẻ chuyển đổi phải bắn trước khi người dùng rời trang hoặc bấm nút. Sau khi hoãn, mở chế độ xem trước của Tag Manager, làm một chuyển đổi thử và kiểm sự kiện còn bắn. Sau đó so số chuyển đổi một tuần trước và một tuần sau.

Site ít truy cập, không có dữ liệu INP thì làm sao? Dữ liệu thực địa chỉ hiện khi trang có đủ lượt truy cập, nên site nhỏ thường không có INP. Khi đó dùng TBT và tác vụ dài của Lighthouse làm số lab, ghi rõ là lab, và tự bấm thử các nút chính trên điện thoại thật. Đừng suy ra INP từ điểm Lighthouse.

Cập nhật 30/10/2026 bởi Công ty TNHH Net Solutions.