Does a protection script slow the page down
Contents
Share
Binetro's documentation does not set a time budget for the script during page load. The Core Web Vitals thresholds answer a different question: which loading, responsiveness, and stability experience Google treats as good for a page. Those numbers cannot be tied to seconds of a protection script. No such measurement is in the documents that were read.
Click fraud does not depend on paint speed. Below is which thresholds exist at all, what the script does on failure, and what "the site got slower" these documents do not prove.
Thresholds of page experience
The Web Vitals documentation, updated on 31 October 2024, sets three stable metrics. LCP measures loading; a good experience is no later than 2.5 seconds from the start of the load. INP measures responsiveness; a good experience is 200 milliseconds or less. CLS measures visual stability; a good experience is 0.1 or less. The threshold for most users is the 75th percentile of loads, separately for phones and for computers. A page passes if all three hold at that percentile.
The metrics are meant to be field metrics. A lab does not replace them: the score is affected by the device, the network, other processes, and how a person touches the page. Lighthouse in the lab does not measure INP, because there is no user input; Total Blocking Time is watched there instead. The thresholds are Google's recommendation for page experience as of the page's update. The document does not measure a protection script and does not tie these numbers to a search position.
If a lab report showed Total Blocking Time rising after the script was installed, that is not yet a failed INP and not proof that the 75th percentile of field loads went past 2.5 seconds. Field and lab are counted separately.
What the script does when there is no answer
If the script received no answer — an error, a timeout, or a 5xx response — the visit is allowed. The check itself has no such mode: the allow-on-failure is done by the script on the site. If the answer could not be assembled, the visitor is allowed too. A wait that did not end in an answer does not turn into a block. For page speed the only boundary that follows is behavioral: an unfinished check does not hold the visitor in a block. How many milliseconds the script is willing to wait, the documents do not set.
The decision on a visit is computed from data already loaded and does not go to the network or the database at the moment of the check. A failure of an external source does not stop the check: it continues on the latest data. The log is written separately. A log-write error does not change the decision. The hot path does not add a network trip "right now, in order to decide." That is not an LCP figure and not a promise that paint will not move.
What the documents do not promise
The documents that were read describe the decision on a visit and an allow if the script did not get an answer in time. They do not set a time budget for the script during page load, and they do not set a way to measure the effect of protection on ad spend before and after. The absence of a promise is not a measurement. For a decision about speed this is a boundary on claims, not a figure for the effect on search or on the cost of a lead.
Invalid clicks are not counted by LCP thresholds. Click fraud and sklikivanie do not get smaller because INP fit into 200 milliseconds. Who clicks ads is not visible in CLS. A refund for click fraud does not depend on a script time budget: there is no such budget in the documentation.
| Question | What can be said | What cannot be said |
|---|---|---|
| What loading experience is good | LCP no later than 2.5 s at the 75th percentile | That the Binetro script fits that threshold |
| What responsiveness is good | INP of 200 ms or less, a field metric | That lab Total Blocking Time equals INP |
| What happens if the check fails | The script allows the visit | How long it waited for an answer |
| Does the decision go to the network | No, it is computed from data already loaded | That page paint is unchanged by this |
| Effect on ad spend | A before-and-after method is not set | That protection sped up or slowed the site by N ms |
Check three things, and do not mix them. Read field LCP, INP, and CLS at the 75th percentile, separately for phone and computer. Read a lab report as a lab: INP is not in it. Check failure behavior separately: no answer means the visit was allowed, and the log does not affect the decision. A figure for "the script adds this many milliseconds" cannot be taken from these sources.
How to take apart a "the script is slow" argument
The argument usually starts from a lab report: the script was installed, Total Blocking Time rose, and that is read as a failed page experience. The Web Vitals documentation of 31 October 2024 does not allow that reading. INP is not measured in the lab, because there is no input. The field threshold is the 75th percentile, separately for phone and computer, and a page passes only if LCP is no later than 2.5 seconds, INP is 200 milliseconds or less, and CLS is 0.1 or less at that percentile.
So compare three rows, not one lab column. The three field metrics before and after installation. The lab report as a lab, with Total Blocking Time instead of INP. The check log separately: whether there was an answer, or the visit was allowed because of an error, a timeout, a 5xx, or an answer that could not be assembled.
The hot path of the decision does not go to the network at the moment of the check and does not wait for the log. A log-write error does not change the decision, and a failure of an external source leaves the check on the latest data. That is how the decision is built, not an LCP millisecond count. The documents do not set a time budget for the script, and they do not set a "ad spend before and after" method either. If you are asked for a figure of the effect on rank or on the cost of a lead, the honest answer is that these documents contain no such measurement, and the page-experience thresholds are not tied to the script.