First Input Delay: Ý nghĩa và cách tối ưu SEO hiện đại

First Input Delay là gì?

First Input Delay (FID) đo khoảng thời gian từ lúc người dùng thực hiện tương tác đầu tiên với trang, chẳng hạn click một liên kết, chạm một nút hoặc sử dụng một điều khiển có JavaScript, đến lúc trình duyệt thực sự có thể bắt đầu xử lý event handler tương ứng.

Điểm quan trọng là FID chỉ đo độ trễ trước khi bắt đầu xử lý. Nó không đo toàn bộ thời gian cần để JavaScript chạy xong, trình duyệt cập nhật giao diện và frame mới được hiển thị. Đây chính là một trong những giới hạn khiến Google và Chrome chuyển sang INP.

Ví dụ, bạn bấm nút “Thêm vào giỏ hàng” lúc main thread đang bận thực thi một tác vụ JavaScript dài. Trình duyệt phải chờ tác vụ đó hoàn tất trước khi callback của nút bắt đầu chạy. Khoảng chờ này chính là FID.

FID còn là Core Web Vital năm 2026 không?

Không. FID đã được INP thay thế ngày 12/03/2024. Chrome sau đó kết thúc hỗ trợ FID trong các công cụ Web Vitals từ tháng 09/2024, dù API PerformanceObserver vẫn có thể cung cấp dữ liệu first-input cho những hệ thống cần đo lịch sử hoặc theo dõi riêng.

Hiện tại, ba Core Web Vitals chính là:

• LCP – Largest Contentful Paint: đo loading performance.
• INP – Interaction to Next Paint: đo responsiveness.
• CLS – Cumulative Layout Shift: đo visual stability.

Google Search Central hiện khuyến nghị website hướng tới LCP trong 2,5 giây, INP dưới hoặc bằng 200 ms và CLS dưới hoặc bằng 0,1 ở mức phân vị 75 của dữ liệu thực tế. Vì vậy, nếu một báo cáo SEO năm 2026 vẫn coi FID là Core Web Vital chính, tôi sẽ cập nhật lại ngay.

Vì sao Google thay FID bằng INP?

FID chỉ quan sát tương tác đầu tiên. Một trang có thể phản hồi rất nhanh cho lần click đầu nhưng chậm ở các lần mở menu, chọn bộ lọc, thêm sản phẩm, gửi form hoặc chuyển tab sau đó.

INP giải quyết giới hạn này bằng cách theo dõi độ trễ của các tương tác trong suốt phiên và báo một giá trị đại diện cho khả năng phản hồi của trang. Nhờ đó, chỉ số mới phản ánh tốt hơn trải nghiệm “website có phản hồi nhanh khi tôi thực sự sử dụng hay không?”.

Tôi xem FID là một lát cắt rất hẹp của responsiveness; INP là phép đo rộng hơn và phù hợp hơn với website hiện đại có nhiều JavaScript, SPA, bộ lọc, form, modal và giao diện tương tác.

FID và INP khác nhau như thế nào?

Chính khác biệt ở phần processing và presentation khiến INP thực tế hơn. Một button có FID rất thấp nhưng callback chạy 800 ms vẫn tạo trải nghiệm chậm; INP có khả năng phản ánh tình huống đó còn FID thì không.

Cơ chế hoạt động của FID và main thread

Trên trình duyệt, main thread xử lý nhiều công việc quan trọng như parse HTML, một phần rendering, style/layout và phần lớn JavaScript của trang. Main thread chỉ có thể xử lý một task tại một thời điểm.

Nếu người dùng tương tác đúng lúc main thread đang chạy một task nặng, event của người dùng phải chờ. Với FID, chúng ta quan tâm khoảng chờ này. Với INP, chúng ta còn phải tính cả thời gian xử lý handler và thời gian tới frame tiếp theo.

Tôi thường hình dung main thread như quầy xử lý một người tại một thời điểm. Nếu quầy đang bận với một tác vụ 400 ms, người dùng vừa click sẽ phải chờ. Nhưng ngay cả sau khi tới lượt, nếu logic xử lý click lại chạy thêm 300 ms và giao diện cần thêm thời gian render, trải nghiệm vẫn chậm. INP nhìn được bức tranh rộng hơn đó.

Long Task là gì?

Trong hướng dẫn hiệu suất của Chrome, một task kéo dài hơn 50 ms được coi là Long Task. Phần thời gian vượt quá 50 ms là blocking period.

Không phải cứ task 51 ms là website lập tức “tệ”, nhưng khi main thread thường xuyên có task dài, xác suất người dùng tương tác đúng lúc bị block tăng lên. Đây là nguyên nhân quan trọng của input delay và INP kém.

Các Long Task thường xuất hiện từ:

• Parse, compile và execute JavaScript lớn.
• Event handler làm quá nhiều việc.
• Render hoặc layout phức tạp.
• Script của bên thứ ba.
• Framework hydration/client-side rendering nặng.
• Xử lý dữ liệu lớn ngay trên main thread.

Những tương tác nào liên quan tới FID và INP?

Responsiveness tập trung vào các tương tác rời rạc như click, tap và key press. Các thao tác liên tục như scroll không được FID đo theo cách tương tự.

Với INP, điều tôi quan tâm là các tương tác tạo phản hồi trực quan hoặc logic trên trang:

• Mở menu.
• Nhấn CTA.
• Chọn bộ lọc.
• Thêm vào giỏ hàng.
• Chọn checkbox/radio.
• Nhập liệu và thao tác form.
• Mở modal hoặc accordion.
• Chuyển tab nội dung.

Nếu website của bạn chỉ tối ưu màn hình đầu nhưng các tương tác này chậm sau khi trang đã tải xong, INP có thể vẫn kém.

Ngưỡng FID cũ là bao nhiêu?

Khi FID còn là Core Web Vital, ngưỡng được dùng là:

• Tốt: ≤100 ms.
• Cần cải thiện: trên 100 ms đến 300 ms.
• Kém: trên 300 ms.

Ngưỡng này được đánh giá ở phân vị 75 của lượt tải trang thực tế, tách mobile và desktop. Tôi giữ phần này trong bài để bạn đọc dữ liệu lịch sử, nhưng không dùng nó làm KPI Core Web Vitals hiện tại.

Ngưỡng INP chuẩn hiện nay

INP hiện được đánh giá ở phân vị 75 của lượt tải trang thực tế:

• Tốt: ≤200 ms.
• Cần cải thiện: >200 ms đến ≤500 ms.
• Kém: >500 ms.

Đây là ngưỡng tôi dùng khi Audit Core Web Vitals năm 2026. Không nên so trực tiếp con số INP với ngưỡng 100 ms của FID vì hai metric đo phạm vi khác nhau.

Core Web Vitals ảnh hưởng SEO như thế nào?

Google Search Central xác nhận Core Web Vitals được các ranking systems sử dụng. Tuy nhiên, Google cũng nhấn mạnh không có một “page experience signal” duy nhất và đạt điểm Core Web Vitals tốt không bảo đảm Top đầu.

Search vẫn ưu tiên nội dung liên quan và hữu ích. Vì vậy, Search Intent và chất lượng nội dung vẫn phải được giải quyết song song với hiệu suất kỹ thuật. Page Experience là một phần của bức tranh rộng hơn, gồm khả năng sử dụng trên mobile, HTTPS, quảng cáo không cản trở nội dung, interstitial hợp lý và trải nghiệm tổng thể.

Vì vậy, tôi không viết “INP kém chắc chắn làm mất Top”. Cách hiểu đúng hơn là: responsiveness tốt giúp trải nghiệm trang tốt hơn và Core Web Vitals là một trong nhiều nhóm tín hiệu mà Google sử dụng.

Trong Technical SEO, tôi đặt Core Web Vitals cạnh crawl, index, canonical, rendering và performance chứ không biến chúng thành toàn bộ SEO.

INP có ảnh hưởng conversion không?

Một giao diện phản hồi chậm có thể làm người dùng bối rối, nhấn lặp, bỏ form hoặc rời trang. Vì vậy, responsiveness có ý nghĩa trực tiếp với UX và conversion.

Tuy nhiên, tôi không sử dụng claim chung như “mỗi 100 ms làm mất 1% doanh thu” cho mọi website. Mối quan hệ giữa latency và doanh thu phụ thuộc ngành, thiết bị, funnel, audience, thương hiệu và cách đo.

Cách đúng hơn là đo trên chính dữ liệu của bạn:

• INP theo page/template.
• Conversion rate theo device.
• Error/double-click behavior.
• Funnel abandonment.
• Revenue hoặc Lead rate theo nhóm trải nghiệm.

Web.dev có nhiều case study cho thấy cải thiện INP có thể đi cùng cải thiện business outcome, nhưng tôi không lấy kết quả của một doanh nghiệp khác làm lời hứa cho website của bạn.

Ba thành phần tạo nên INP

Một interaction có thể được chia thành ba phần:

1. Input Delay

Từ lúc người dùng tương tác tới khi callback bắt đầu chạy. Đây là phần gần nhất với khái niệm FID cũ.

2. Processing Duration

Thời gian các event callback thực thi. Nếu click handler xử lý dữ liệu lớn, chạy nhiều framework update hoặc gọi các hàm đồng bộ nặng, phần này sẽ tăng.

3. Presentation Delay

Sau khi JavaScript xử lý xong, trình duyệt còn phải cập nhật style, layout, paint và trình bày frame tiếp theo. DOM lớn hoặc layout phức tạp có thể kéo dài giai đoạn này.

Vì thế, chỉ giảm input delay chưa đủ. Tối ưu INP phải giảm tổng latency từ tương tác tới frame phản hồi tiếp theo.

Nguyên nhân phổ biến khiến INP kém

JavaScript khởi động quá nặng

Script lớn không chỉ tốn thời gian tải. Sau khi tải, trình duyệt còn phải parse, compile và execute. Công việc này có thể tạo Long Task và chiếm main thread đúng lúc người dùng bắt đầu tương tác.

Event handler làm quá nhiều việc

Một click có thể kích hoạt validation, xử lý dữ liệu, DOM update, analytics tracking và nhiều logic khác. Nếu tất cả chạy đồng bộ trong một task, processing duration tăng mạnh.

Third-party JavaScript

Analytics, Ads tag, chat, heatmap, A/B testing, popup và widget có thể cạnh tranh main thread. Tôi không mặc định “script bên thứ ba = xấu”; vấn đề là số lượng, timing và giá trị mà từng script mang lại.

DOM và rendering phức tạp

INP không chỉ là JavaScript. Layout lớn, style calculation phức tạp, layout thrashing và DOM quá lớn có thể làm presentation delay kéo dài.

Client-side rendering/hydration nặng

Một trang trông đã hiển thị nhưng framework vẫn đang hydrate hoặc execute JavaScript lớn có thể tạo cảm giác “nhìn thấy nhưng chưa dùng được”. Đây là tình huống FID trước đây từng phản ánh một phần, còn INP cho cái nhìn đầy đủ hơn.

Code Splitting có tự động sửa INP không?

Không. Code Splitting giúp chia bundle để tải code theo nhu cầu, nhưng nó không đồng nghĩa mọi task runtime đều dưới 50 ms.

Tôi phân biệt:

• Code splitting: giảm lượng code cần tải/khởi tạo ở một thời điểm.
• Task yielding: chia công việc runtime để main thread có cơ hội xử lý interaction/render.
• Web Worker: chuyển công việc tính toán phù hợp ra khỏi main thread.

Ba kỹ thuật có thể bổ sung nhau, nhưng không nên dùng tên thay thế cho nhau.

Cách tối ưu Long Tasks đúng hơn

Chrome khuyên khi callback có quá nhiều việc, hãy làm ít việc nhất có thể và yield về main thread ở những điểm phù hợp để browser có cơ hội xử lý interaction hoặc render.

Tôi thường kiểm tra:

• Hàm nào chiếm nhiều CPU.
• Có thể bỏ phần công việc không cần thiết không.
• Có thể xử lý sau frame phản hồi đầu tiên không.
• Có thể chia công việc thành nhiều task không.
• Có thể chuyển pure computation sang Worker không.

Mục tiêu không phải “ép mọi hàm dưới 50 ms bằng mọi giá”, mà là tránh để main thread bị chiếm liên tục tới mức người dùng cảm thấy trang treo.

Web Worker giúp INP như thế nào?

Web Worker cho phép chạy JavaScript trên thread riêng cho những công việc không cần truy cập DOM trực tiếp. Điều này có thể giảm congestion trên main thread và giúp trang phản hồi interaction nhanh hơn.

Các ứng viên phù hợp gồm:

• Sort/filter dữ liệu lớn.
• Tính toán phức tạp.
• Parsing dữ liệu.
• Model hoặc thuật toán chạy lâu.

Worker không có quyền DOM trực tiếp, nên không phải mọi JavaScript đều chuyển sang Worker được. Tôi chỉ dùng khi chi phí tính toán thật sự đáng kể.

async và defer khác nhau thế nào?

Cả async và defer cho phép trình duyệt tiếp tục parse HTML trong lúc tải script, nhưng cách thực thi khác nhau.

Third-party script nên được tải bất đồng bộ khi có thể, nhưng tôi luôn kiểm tra yêu cầu của từng vendor. Một thay đổi async/defer sai có thể làm mất tracking hoặc phá thứ tự dependency.

Tối ưu Third-party JavaScript

Tôi bắt đầu bằng inventory. Với mỗi tag hoặc plugin, cần trả lời:

• Nó phục vụ mục tiêu gì?
• Có còn được dùng không?
• Cần tải ngay ở mọi trang không?
• Có thể tải khi consent hoặc interaction không?
• Có thể giới hạn theo template không?
• Có script khác trùng chức năng không?

Web.dev khuyến nghị loại bỏ script không tạo giá trị hoặc tối ưu cách tải bằng async, defer, lazy load và các kỹ thuật phù hợp. Với Website Marketing, tôi đặc biệt rà Ads tag, analytics, chatbot, heatmap, popup và A/B testing vì chúng thường tích lũy theo thời gian. Trong Digital Marketing, mỗi công cụ theo dõi chỉ nên tồn tại khi nó phục vụ một quyết định hoặc mục tiêu đo lường rõ.

Google Analytics có phải thủ phạm INP không?

Không nên kết luận như vậy chỉ vì website có GA4. Bất kỳ JavaScript bên thứ ba nào cũng có chi phí, nhưng mức ảnh hưởng phụ thuộc triển khai, số tag, trigger và code xung quanh.

Nếu website dùng Google Tag Manager, tôi kiểm tra:

• Tag có fire trên mọi page dù không cần không?
• Event có duplicate không?
• Nhiều pixel có chạy cùng lúc không?
• Custom HTML tag có JavaScript nặng không?
• Chat/heatmap có thể delayed không?

Tối ưu performance không có nghĩa xoá toàn bộ measurement. Tôi muốn hệ đo đủ dùng nhưng không biến main thread thành nơi chạy mọi tool Marketing cùng lúc.

Đo INP bằng công cụ nào?

Vì INP là field metric, tôi ưu tiên dữ liệu người dùng thật.

PageSpeed Insights

PageSpeed Insights hiển thị dữ liệu Chrome User Experience Report (CrUX) khi URL/origin đủ dữ liệu, đồng thời có phần lab diagnostics hỗ trợ điều tra nguyên nhân.

Search Console Core Web Vitals

Search Console nhóm URL theo dữ liệu Core Web Vitals thực tế. Đây là công cụ tốt để xem template/nhóm URL nào đang có vấn đề ở quy mô site.

Chrome UX Report

CrUX cung cấp field data từ Chrome users đủ điều kiện và là nguồn dữ liệu của nhiều báo cáo Core Web Vitals.

Real User Monitoring

RUM của riêng website có thể giúp tôi nối interaction chậm với page, component, device, version hoặc user journey cụ thể. Đây là lớp hữu ích khi CrUX cho biết “có vấn đề” nhưng chưa chỉ ra component nào.

Lighthouse có đo FID hay INP không?

FID phụ thuộc tương tác người dùng thật nên không thể đo trực tiếp trong một lab load không có interaction thực. Với INP, lab troubleshooting cũng cần tái hiện interaction.

Lighthouse thường dùng các diagnostics và metric như Total Blocking Time (TBT) để giúp tìm main-thread blocking trong quá trình tải. TBT có thể giúp phát hiện rủi ro, nhưng không phải INP và không nên đổi tên TBT thành “INP lab”.

Tôi dùng Lab để chẩn đoán, Field Data để đánh giá trải nghiệm thực.

Field Data và Lab Data khác nhau thế nào?

Field Data đến từ người dùng thật với thiết bị, mạng, trạng thái cache và hành vi thật. Đây là nền tảng của đánh giá Core Web Vitals.

Lab Data chạy trong môi trường kiểm soát để tái hiện và debug. Nó rất tốt để tìm Long Task, script nặng, layout và waterfall, nhưng không đại diện hoàn toàn cho mọi người dùng.

Tôi thường đi theo quy trình:

1. Field Data phát hiện nhóm URL kém.
2. RUM xác định interaction/component nếu có.
3. Chrome DevTools tái hiện trong lab.
4. Sửa code.
5. QA lab.
6. Theo dõi Field Data sau khi đủ thời gian.

WordPress thường bị INP kém vì đâu?

Với WordPress, vấn đề thường không nằm ở “WordPress chậm” một cách chung chung mà ở stack cụ thể.

Tôi thường rà:

• Theme/Page Builder tạo JavaScript lớn.
• Plugin popup, slider, wishlist, chat, tracking.
• Plugin load asset trên mọi trang.
• JavaScript legacy không còn dùng.
• Third-party iframe/widget.
• DOM quá sâu do builder.
• Menu/mobile drawer có handler nặng.
• WooCommerce variation/cart script.

Với quản trị Website, tôi không bật “Delay JS” hàng loạt rồi coi như xong. Mỗi script cần được test vì trì hoãn sai có thể làm menu, checkout, analytics hoặc form lỗi.

Cách tôi tối ưu INP cho WordPress

1. Loại plugin và script không cần

Giảm JavaScript là chiến thắng sạch nhất nếu tính năng thật sự không còn dùng.

2. Chỉ load asset nơi cần

Slider chỉ có ở Homepage thì không nên bắt mọi Blog tải script slider. Form, map và widget cũng tương tự.

3. Kiểm tra main thread bằng DevTools

Tôi dùng Performance panel để tìm Long Task, function tốn CPU và script nguồn nào đang chiếm thời gian.

4. Tối ưu interaction quan trọng

Menu, Add to Cart, Filter, Search, Form Submit và Checkout cần được test trên mobile yếu, không chỉ desktop máy mạnh.

5. Kiểm soát third-party

Tracking và chat phải có governance. Một website không nên giữ 5 pixel cũ chỉ vì “không biết ai đang dùng”.

6. Theo dõi lại bằng Field Data

Core Web Vitals đánh giá dữ liệu thực ở phân vị 75, nên tôi không kết luận thành công chỉ từ một lần chạy PageSpeed 100 điểm.

Có nên trì hoãn toàn bộ JavaScript để đạt INP tốt?

Không. Một số JavaScript là thiết yếu cho tương tác. Nếu delay script menu tới sau click đầu tiên, bạn có thể tạo chính độ trễ mà mình muốn loại bỏ.

Tôi phân loại:

• Critical interaction JS: cần sẵn sàng đúng lúc.
• Non-critical UI: có thể load sau.
• Marketing/analytics: ưu tiên theo consent và nhu cầu đo.
• Below-the-fold feature: có thể lazy/init khi gần viewport.

Mục tiêu là ít JavaScript cần thiết hơn ở đúng thời điểm, không phải “delay tất cả”.

FID tốt nhưng INP xấu có thể xảy ra không?

Có, và đây chính là lý do INP thay FID.

Ví dụ:

1. Trang tải xong tương đối nhẹ.
2. Người dùng click menu lần đầu, FID chỉ 30 ms.
3. Sau đó họ mở bộ lọc sản phẩm.
4. Framework xử lý 900 ms mới render kết quả.

FID sẽ nhìn lần interaction đầu và có vẻ rất tốt. INP có thể phản ánh interaction bộ lọc chậm trong phiên. Với Ecommerce hoặc Web App, khác biệt này rất quan trọng.

INP tốt có bảo đảm website SEO tốt không?

Không. Google nói rõ Core Web Vitals tốt không bảo đảm trang đứng Top. Nội dung liên quan, Search Intent, crawl/index, chất lượng, links và nhiều hệ thống khác vẫn quyết định khả năng cạnh tranh.

Tôi xem INP là một phần của Page Experience. Nếu Website đang có nội dung yếu nhưng đội kỹ thuật chỉ chăm chăm đưa INP từ 210 ms xuống 180 ms, đó có thể không phải ưu tiên tạo tác động lớn nhất.

Trong SEO tổng thể, Performance được ưu tiên theo mức độ ảnh hưởng thực cùng Technical, Content, Architecture và Conversion.

Checklist chuyển từ FID sang INP

Những sai lầm phổ biến khi tối ưu FID/INP

Chỉ nhìn điểm PageSpeed một lần

Lab score dao động và không đại diện đầy đủ field experience. Tôi quan tâm xu hướng và dữ liệu thực tế.

Chỉ giảm bundle size

Bundle nhỏ hơn tốt, nhưng event handler runtime vẫn có thể nặng. INP cần nhìn interaction sau khi tải.

Delay mọi script

Có thể làm tính năng không sẵn sàng khi người dùng cần.

Đổ lỗi cho plugin mà không profiling

Tên plugin không cho biết function nào đang block main thread. Hãy đo trước khi gỡ.

Chỉ tối ưu desktop

Thiết bị yếu thường có CPU chậm hơn và dễ bộc lộ Long Task. Field Data ở mobile rất quan trọng.

Đạt INP tốt rồi bỏ qua UX

Một button phản hồi 100 ms nhưng thiết kế gây nhầm lẫn vẫn là UX kém. Core Web Vitals không thay thế Product/UX Design.

INP, LCP và CLS nên ưu tiên chỉ số nào trước?

Không có thứ tự cố định. Tôi ưu tiên theo dữ liệu thực tế và mức độ ảnh hưởng.

Nếu LCP 6 giây, người dùng chưa thấy nội dung chính thì vấn đề loading có thể cần xử lý trước. Nếu LCP tốt nhưng checkout phản hồi 800 ms, INP trở thành ưu tiên lớn. Nếu layout nhảy làm người dùng bấm nhầm, CLS cần được sửa.

Core Web Vitals là bộ ba bổ sung nhau. Với phần nội dung, tôi vẫn ưu tiên People-first Content thay vì hy sinh giá trị bài viết chỉ để đổi lấy vài điểm hiệu suất:

• LCP: trang có hiện nội dung chính nhanh không?
• INP: trang có phản hồi nhanh khi dùng không?
• CLS: giao diện có ổn định không?

Audit hiệu suất tốt phải xem cả ba cùng business flow.

Core Web Vitals trong chiến lược SEO năm 2026

Google hiện khuyến nghị website đạt Core Web Vitals tốt, nhưng cũng nói đừng tập trung chỉ một hoặc hai khía cạnh Page Experience. Tôi đồng ý với cách tiếp cận này.

Với SEO, tôi kết hợp:

• Core Web Vitals.
• Mobile usability.
• HTTPS.
• Không lạm dụng intrusive interstitial.
• Nội dung chính dễ nhận diện.
• Technical SEO.
• People-first Content.

Đây là lý do SEO Onpage và Technical SEO cần đi cùng Performance thay vì chạy thành các checklist tách rời.

Khi nào nên Audit hiệu suất toàn website?

Tôi khuyên Audit sâu khi:

• Search Console báo nhiều URL INP Poor.
• Website dùng Page Builder/Plugin stack lớn.
• Mobile có conversion thấp bất thường.
• Checkout, form hoặc filter phản hồi chậm.
• Website vừa thêm nhiều tracking/pixel.
• Sau redesign, Core Web Vitals xấu đi.
• Đội kỹ thuật tối ưu lâu nhưng Field Data không cải thiện.

Lúc đó, Audit Website nên kiểm tra Performance cùng Technical, JavaScript, DOM, third-party và Conversion Flow thay vì chỉ chạy Lighthouse rồi gửi điểm số.

Kết luận

First Input Delay là một metric quan trọng trong lịch sử Core Web Vitals vì nó giúp ngành web bắt đầu đo responsiveness bằng dữ liệu người dùng thật. Nhưng năm 2026, tôi không còn tối ưu FID như KPI SEO chính.

INP đã thay thế FID vì nó phản ánh trải nghiệm tương tác toàn diện hơn: từ input delay, thời gian xử lý callback tới presentation delay và theo dõi interaction trong suốt phiên.

Xuyên Việt Media và bạn nên chuyển câu hỏi từ “FID đã dưới 100 ms chưa?” sang “những tương tác quan trọng trên website có phản hồi dưới ngưỡng INP tốt ở dữ liệu người dùng thật hay chưa?”. Từ đó, việc giảm Long Task, kiểm soát JavaScript, tối ưu event handler, rendering và third-party code mới có mục tiêu rõ ràng.

“Tôi không tối ưu một website để nút PageSpeed chuyển sang màu xanh. Tôi muốn khi bạn mở menu, lọc sản phẩm, gửi form hay bấm mua hàng, website phản hồi ngay lúc bạn cần. INP có ý nghĩa vì nó đưa Performance trở lại đúng câu hỏi: người dùng có cảm thấy giao diện đang nghe họ hay không?”

Anh Thắng Giấu Tên – CEO Xuyên Việt Media