Full-page screenshots

By default, the only thing you need to do is to set the full_page parameter to true:

https://api.screenshotone.com/take?url=https://example.com&full_page=true&access_key=...

The API tuned to balance performance and quality for the full-page screenshots. However, if you need to improve the quality of rendering, for the full-page screenshots, there is a few things you can do:

1. Understand how viewport dimensions affect full-page screenshots.
2. Try different rendering algorithms.
3. Tune scrolling of the page.
4. Reduce animations.
5. Wait more.

However, improving the quality of rendering might lead to a performance degradation.

Viewport dimensions

The viewport_width and viewport_height options play an important role in full-page screenshots:

Viewport width and height

The viewport_width option directly determines the width of your final full-page screenshot because:

• Responsive design: Different viewport widths trigger different layouts and CSS breakpoints. A mobile viewport (e.g., 375px) will render a mobile layout, while a desktop viewport (e.g., 1920px) will render a desktop layout.
• Content visibility: Wider viewports may show navigation menus, sidebars, or multi-column layouts that are hidden or stacked differently on narrower viewports.

By default, the viewport width is 1280 pixels.

The viewport_height option affects full-page screenshots differently depending on the algorithm used:

For the default algorithm:

• The viewport height is temporarily stretched to match the full page height during rendering.
• Your specified viewport_height is less relevant as it gets overridden.

For the “by_sections” algorithm:

• The viewport_height determines the size of each section that is captured.
• The API scrolls by the viewport height, captures a screenshot, then scrolls again.
• This affects lazy-loaded content: elements that load when they enter the viewport are triggered as the page scrolls through each section.
• Smaller viewport heights mean more sections and more scroll events, which can trigger more lazy-loaded content but takes longer.

By default, the viewport height is 1024 pixels.

Capturing beyond viewport

The capture_beyond_viewport option works together with viewport dimensions to control how content is captured:

Default behavior (capture_beyond_viewport=true):

• The browser can capture content that extends beyond your viewport_width and viewport_height.
• This is the default for full-page screenshots and is essential for capturing the entire page height.
• The viewport dimensions still control the initial page layout and width of the screenshot.

When set to false:

capture_beyond_viewport=false

• Content is clipped to the exact viewport dimensions.
• For full-page screenshots, this usually produces undesired results as it clips the page.
• Only useful in specific cases where you want to limit the capture area strictly to the viewport.

Important note for “by_sections” algorithm:

• When using full_page_algorithm=by_sections, the capture_beyond_viewport option is automatically set to false internally.
• This is because the algorithm captures each section within the viewport and stitches them together.
• You don’t need to worry about this option when using the “by_sections” algorithm.

Different rendering algorithms

By default, the API uses the full_page uses a simple algorithm to screenshot the full page—it asks the browser to render it and usually that means that the browser just stretches the viewport to render the full-page screenshot. It rarely but leads to rendering issues.

You can try to use a different algorithm instead—by_sections:

full_page_algorithm=by_sections

It might be better in most cases. Since it will try to scroll the page and render it section by section, and then stitch all the sections into one image.

But while scrolling the page, not every element might triggered due the speed of the scrolling and the delay between the scrolls. Try to tune scrolling.

Tune scrolling

Try to decrease or increase the size of the scroll step:

full_page_scroll_by=500

And increase the delay between the scrolls, it might help to render the page correctly

full_page_scroll_delay=1500

It might help to render the page better and trigger more lazy-loaded elements.

Reduce animations

Request websites to reduce the number of animations by adding the reduced_motion parameter:

reduced_motion=true

Wait more

Add from 5 to 10 seconds to wait for the page to load:

delay=5

Block ads, trackers, banners and other elements

Request the API to block ads, trackers, banners and other elements by use the following parameters:

block_ads=true&block_trackers=true&block_cookie_banners=true&block_chats=true&block_banners_by_heuristics=true

Summary

Combining all the tips above, you might try to get the best results with something like that:

https://api.screenshotone.com/take?access_key=...&url=https://example.com&full_page=true&full_page_algorithm=by_sections&full_page_scroll_by=500&full_page_scroll_delay=1500&reduced_motion=true&delay=5&block_ads=true&block_trackers=true&block_cookie_banners=true&block_chats=true&block_banners_by_heuristics=true

Support

Rendering full-page screenshots reliably is a real challenge. And even after a lot of tuning, it might not work for all the pages.

If you have any questions or suggestions, please contact us at support@screenshotone.com.