标签：#screenshot

How to Handle Anti-Bot Measures When Taking Screenshots Programmatically You send a request. The page loads. The screenshot comes back blank, or shows a CAPTCHA, or captures a "Please verify you're human" wall. This is one of the most common problems when building any screenshot pipeline. Here's what's actually happening and how to deal with it. Why headless browsers get flagged Bot detection works by looking for patterns that differ from real users. Headless Chrome has several tells: navigator.webdriver returns true by default Missing Chrome-specific properties like window.chrome Inconsistent screen dimensions (no monitor attached means no GPU info) Mouse events fire at pixel-perfect coordinates with no jitter Font fingerprints differ from headed browsers Modern detection services (Cloudflare, Akamai, Datadome) look for combinations of these signals, not individual flags. Spoofing one without the others often makes the fingerprint more suspicious, not less. The practical spectrum of detection Most sites fall into one of three categories: No active detection — a basic bot check via User-Agent string at most. Simple fix: set a realistic UA. Passive fingerprinting — loads a detection script, collects signals, blocks on second or third visit. You'll see this on news sites, e-commerce, media platforms. Active challenges — Cloudflare Turnstile, hCaptcha, reCAPTCHA v3 score-based. These require real interaction or a solving service. Know which category your target falls into before spending time on it. Fixes that work for most cases 1. Use a stealth plugin For Playwright, playwright-extra with puppeteer-extra-plugin-stealth patches the most common fingerprinting vectors: npm install playwright-extra puppeteer-extra-plugin-stealth import { chromium } from 'playwright-extra'; import StealthPlugin from 'puppeteer-extra-plugin-stealth'; chromium.use(StealthPlugin()); const browser = await chromium.launch(); This handles navigator.webdriver , window.chrome , and several other

You set up Puppeteer, navigate to a page, call page.screenshot() , and the bottom half of your image is blank placeholder boxes. Welcome to lazy loading. Most modern sites defer images and heavy content until the user scrolls. Your headless browser never scrolls. So those elements never load. Here's how to deal with it. The scroll trick The most common fix is to programmatically scroll down the page before taking the screenshot: async function scrollToBottom ( page ) { await page . evaluate ( async () => { const delay = ms => new Promise ( r => setTimeout ( r , ms )); const distance = 300 ; while ( window . scrollY + window . innerHeight < document . body . scrollHeight ) { window . scrollBy ( 0 , distance ); await delay ( 150 ); } window . scrollTo ( 0 , 0 ); }); } await page . goto ( " https://example.com " , { waitUntil : " networkidle2 " }); await scrollToBottom ( page ); await page . waitForTimeout ( 1000 ); await page . screenshot ({ fullPage : true }); The 150ms delay between scrolls gives IntersectionObserver -based lazy loaders time to trigger. Too fast and you'll scroll past elements before they start loading. That final waitForTimeout after scrolling back to top lets any remaining images finish rendering. Not elegant, but necessary. Why networkidle2 isn't enough You'd think waitUntil: "networkidle2" would handle this. It waits until there are no more than 2 network connections for 500ms. But lazy-loaded images haven't even been requested yet at that point — they're waiting for a scroll event that never happens. networkidle2 only helps with content that loads on page init. For scroll-triggered content, you need the scroll. The loading="eager" override Some sites use the native loading="lazy" attribute. You can override it before images load: await page . evaluateOnNewDocument (() => { Object . defineProperty ( HTMLImageElement . prototype , " loading " , { set : function ( val ) { this . setAttribute ( " loading " , " eager " ); }, get : function () { retu

Every blog post needs an OG image. Without one, your links look blank on Twitter, LinkedIn, and Slack — just a plain URL that nobody clicks. Most developers solve this by spinning up a headless browser, loading an HTML template, taking a screenshot, and uploading it somewhere. It works, but now you're maintaining a Puppeteer instance, dealing with font rendering quirks, and burning server resources on something that should be simple. There's a faster approach: design your OG images as HTML templates and let a screenshot API handle the rendering. The Idea: HTML Templates as OG Images Think of your OG image as a tiny webpage. You already know HTML and CSS. Build a 1200×630 template with your blog title, author name, maybe a gradient background — whatever fits your brand. Host it or pass it as raw HTML. Then call an API to screenshot it. Done. A basic template might look like this: <div style= "width:1200px;height:630px;display:flex;align-items:center; justify-content:center;background:linear-gradient(135deg,#1a1a2e,#16213e); font-family:Inter,sans-serif;padding:60px" > <div style= "color:#fff;text-align:center" > <h1 style= "font-size:48px;margin:0" > {{title}} </h1> <p style= "font-size:24px;color:#8892b0;margin-top:20px" > {{author}} · {{date}} </p> </div> </div> Replace the placeholders on your server, then send the resulting HTML (or a URL pointing to it) to the API. Calling the API With ScreenshotRun , a single curl request captures the rendered template as a PNG: curl -X POST "https://api.screenshotrun.com/v1/screenshot" \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "url": "https://yourblog.com/og-template?title=My+Post+Title", "viewport_width": 1200, "viewport_height": 630, "format": "png" }' The response gives you the image file. Save it to your CDN, set the og:image meta tag, and you're done. No browser to manage, no Chrome binary eating RAM on your CI server. Wiring It Into Your Build If you publish with a static sit