When an advertiser decides to defend against bots, the first question is usually technical: block by IP, or put a script on the page? These are two different ways of looking at a visit. IP blocking judges where the request came from. A JavaScript check judges what kind of program sent it. Each approach has its own blind spot, and that is exactly why serious protection does not pick one, it combines them.
Below: how each approach works, what it catches well, where it gets things wrong, and how to make them work together without slowing the page down.
IP blocking: how it works
The server receives a request and knows little about it: the IP address, the browser headers, the referring page. But an IP tells you a lot:
- who owns the network: a home ISP, a mobile carrier, a hosting company, a cloud (via the autonomous system number, ASN);
- country and city, accurate enough for a geo filter;
- flags in databases: known VPN, proxy, Tor, spam-trap address;
- history: how many times this address has already shown up and how it ended.
The decision is made before the page is served. That is the main strength of the approach: it costs nothing in speed and works even against programs that cannot run scripts.
What IP blocking catches
- Server-side bots. Most cheap bots, scrapers and scanners live in data centers. Blocking hosting ASNs removes them with almost no errors. More in VPN, proxy and data center IP detection.
- Known VPNs and server proxies. Their addresses land in databases regularly.
- Repeat addresses. A per-IP click cap and an IP blacklist stop persistent visitors and the competitor clicking from their office.
- Wrong geo. A click from a country you never targeted is almost never a buyer.
Where IP blocking falls short
- Residential and mobile proxies. The bot goes online through a home subscriber's address or a carrier SIM card. To an IP filter, that is a regular person. There is a separate article on this: residential and mobile proxies.
- Shared addresses. Hundreds of subscribers sit behind one mobile IP, dozens of employees behind an office one. Blocking such an address cuts off real people.
- Rotation. A bot that changes its address on every click slips past frequency caps and blacklists.
- Database lag. A fresh address reaches the databases hours or days later, and by then it has done its job.
- No view inside. An IP says nothing about whether this is a browser or a script, whether it has a screen, whether the mouse moves.
JavaScript check: how it works
The page serves the visitor a small script. It runs in the browser and collects what is visible only from the inside:
- automation signs: the
webdriverflag, traces of browser control tools, quirks typical of headless mode; - device fingerprint: screen, GPU, fonts, the browser's feature set;
- system settings: time zone, language, keyboard layout;
- consistency: whether what the
User-Agentheader claims matches what the browser can actually do; - behavior: mouse and finger movement, scrolling, time to first action.
The script sends the result to the server, and the server makes the call. How a fingerprint is built and where it gets faked is covered in headless browsers and browser fingerprinting.
What a JavaScript check catches
- Programs without a browser. Scrapers and simple bots that download the page but do not run the script never send an answer. That alone is a strong signal.
- Headless browsers and automation. Even on a residential IP, a bot driving a browser leaves traces.
- Spoofed devices. An iPhone with a server GPU and a 1920x1080 screen gives itself away through the contradiction.
- Network and system mismatch. A German IP with an Asian time zone and language. The network cannot see this, the script can.
- Mechanical behavior. Perfectly straight movements, instant exits, a click with no movement before it.
Where a JavaScript check falls short
- Time. The script has to be downloaded, executed and answered by the server. That is a delay IP blocking does not have.
- Not every visit runs it. In-app browsers of social networks sometimes load the page in the background and freeze timers; old phones run the script slowly; some people leave before the check finishes.
- It can be faked. The data comes from the client, so an advanced bot can substitute it. Antidetect browsers exist precisely for that.
- False positives on unusual devices. In-app WebViews, privacy-hardened browsers, anti-fingerprinting extensions all look like spoofing, even though a human is behind the screen.
- It depends on where it is installed. The script works only where it is placed. If the link leads to a page without it, there is no check.
The two approaches side by side
| IP blocking | JavaScript check | |
|---|---|---|
| When it decides | before the page is served | after the script loads |
| Speed impact | almost none | a few tenths of a second |
| Server-side bots | catches them very well | catches them, but later and at higher cost |
| Bots on residential and mobile IPs | barely sees them | sees them through browser and behavior |
| Programs without JavaScript | only if the address is a server | catches them by the missing answer |
| Spoofing | proxies swap the address | antidetect browsers swap the data |
| Main error risk | shared addresses, broad blocks | WebViews, privacy browsers, slow phones |
The table shows the key point: the weak spots of the two approaches barely overlap. What the network misses, the browser sees, and vice versa.
Why they are combined
With IP blocking alone, all the fraud on residential and mobile addresses passes the filter, and that is the most expensive part of it: the clicks look real and are paid at full price. With the script alone, every server-side bot gets the page, downloads the script and loads your server, while simple bots that never ran the check look the same as people who did not wait for the page to load.
A working setup looks like this:
- Network as the first layer. Data centers, known bots, blacklisted addresses and wrong geo are cut hard. Cheap, fast and nearly error-free.
- Browser as the second layer. Everything that passed the network is checked by the script: automation, fingerprint, time zone and language, behavior.
- A trust score instead of bans. Soft signals such as a proxy flag, a mobile address, a time zone mismatch or a missing click ID do not block a visit on their own, they add up. The decision is made on the total.
- Per-source statistics as the third view. Even the best single-visit check is no substitute for looking at the whole traffic source: share of suspicious visits, conversions, approval rate. That is how click farms and systematic ad fraud become visible.
This way errors land in the advertiser's favor: a real person on a VPN is not cut off for a single signal, and a bot on a home address does not get through just because the address is clean.
How it affects page speed
Speed matters for more than convenience: every extra second of load time lowers conversion, and protection that scares buyers away costs more than the bots. What you can do:
- Settle the network part early. While the browser loads the script, the server can already check the IP, ASN and databases. By the time the script reports back, half the decision is ready.
- A small script and one connection. The fewer requests and the closer the server is to the visitor, the shorter the wait. A compressed script and a reused connection save tens of milliseconds on mobile.
- Do not wait for behavior where you do not need it. Mouse movement checks require the visitor to do something on the page. Turn them on for strict sources, not for all traffic.
- Drop server-side bots before the script. If a bot is filtered out by the network, there is no need to serve it the script. That saves server resources and keeps your stats cleaner.
- Measure. Look at the time from click to page display on real visits, not a lab test on a fast computer.
Bottom line on speed: implemented sensibly, a combined check adds fractions of a second to load time. That is far less than you lose to heavy images and third-party counters, and incomparably cheaper than paid bot clicks.
Example: three visits through two layers
To see how the approaches complement each other, take three clicks on one campaign targeting Germany.
Visit A. A cloud hosting address in Frankfurt, the browser header says a fresh Chrome on Windows. The network layer drops it immediately: a hosting network in ad traffic is a server, not a buyer. The script was not even needed, the page was never served, and the server spent no resources.
Visit B. A home ISP address in Munich, clean in the databases, click ID present. Nothing to object to on the network side. The script reports: automation flag on, software GPU, time zone America/New_York, no mouse movement before the click. IP blocking would have let this visit through and you would have paid for it as a real one. The browser layer stops it.
Visit C. A mobile address of a German carrier, flagged as shared, a social network's in-app browser, time zone Europe/Berlin, German language. The script ran with a delay because the app loaded the page in the background. If the filter blocked mobile addresses or demanded an instant script response, this buyer would have been lost. The trust score sees that the signals agree and lets the visit through.
In this example, each layer alone would have been wrong at least once: the network alone would have passed visit B, and a strict script without a trust score would have risked dropping visit C. Together they got all three right. Real traffic works the same way: the cheap network layer removes most of the junk, the browser layer catches what is disguised as people, and the sum of signals protects against needless rejections.
Where the check is unnecessary or harmful
- Pages without paid traffic. If no ads lead to a page, a strict browser check gets in the way more often than it helps.
- Sources where almost everyone uses an in-app browser. Relax the requirement to run the script there and rely on the trust score.
- Search engine crawlers on your main site. Protect campaign landing pages, not the whole site with its SEO traffic. More on choosing in anti-bot protection for a website.
How this works in ArtisanClo
ArtisanClo uses both layers: network checks filter out data center, VPN and proxy traffic, while the browser check catches automation and device spoofing on addresses that look clean from the network side. Every click in the log shows the reason code behind the decision, so you see at once whether the network or the browser fired. The built-in tracker counts spend, conversions, profit and ROI by campaign, so you can see how much money went to junk traffic and which source brings it. All checks are listed on the features page.
In short
IP blocking and a JavaScript check answer different questions: where did the visit come from, and what program sent it. The first is fast, cheap and reliable against server-side bots, but blind to proxies on home and mobile addresses. The second sees the browser from the inside, but costs time, can be faked by advanced bots and misfires on unusual devices. Their weak spots barely overlap, so the network goes first, the browser second, soft signals add up to a trust score, and the result is checked against per-source statistics. To work out what missed bots actually cost you, read how much budget is lost to bots.
