Skip Images and Fonts in Puppeteer to Speed Up Headless Loads
Reduce Puppeteer bandwidth and load time by aborting image, stylesheet, and font requests with request interception.
Loading…
ReadMeFeed / Community knowledge
#headless-browser
Real questions. Useful conversations. Find the people who know your stack.
puppeteerRun isolated parallel sessions in Puppeteer with BrowserContext instead of multiple browsers
Launch one Chromium instance and create a BrowserContext per session to isolate cookies, storage and permissions for parallel scraping or testing without paying launch overhead per user.
Karma browser capture architecture: a CI design decision
Decide when to use Karma with real browsers versus JSDOM, and configure a minimal CI-friendly karma.conf.js.
karmaRunning JavaScript Tests in CI: Configuring Karma with ChromeHeadless
Stop CI failures caused by missing display servers. Learn how to configure Karma with ChromeHeadless and Puppeteer for reliable, headless JavaScript unit testing.
Puppeteer headless mode log capture in Linux containers
Deploying Puppeteer in Linux-based containers using headless: "new" can result in browser initialization failures that do not throw explicit JavaScript exceptions. While the browser.on('disconnected') event captures stdout and stderr, logs are frequently truncated when the process is terminated by system-level signals, such as an Out-of-Memory (OOM) killer.
Pre-compiled binaries vs. source builds for nodewebkit environments
Setting up a repeatable development environment for nodewebkit headless rendering requires a decision between pre-compiled binaries and custom source builds. Pre-compiled binaries enable faster pipeline setup but depend on matching glibc versions between build and host, and can be limited by the lag between upstream WebKit releases and the Node wrapper. Sour
nodewebkitPlaywright and CI/CD: Headless Execution vs Local Headed Rendering
Environment Disparity in Browser Execution Playwright tests often pass in local development environments where the browser runs in headed mode, but fail when deployed to production CI/CD pipelines running in headless mode. This discrepancy frequently manifests as element visibility failures or unexpected layout shifts that trigger timeout errors during inter
playwrightKarma browser launcher configuration for environment parity
Maintaining a repeatable development environment requires consistent browser execution across local machines and continuous integration pipelines. In Karma, the browsers array allows the definition of multiple targets, such as Chrome and ChromeHeadless , to validate cross-browser compatibility. A challenge arises when transitioning from headed browsers for l