Browshot blog

We can now host and server your thumbnails and screenshots. We offer 3 types of hosting: Amazon S3, CDN, and Browshot. We also introduce a new thumbnail API.

S3 hosting

We can upload thumbnails and screenshots into your S3 bucket. You need to set up the ACL to let the Browshot account write files into your bucket.

CDN hosting

You can serve thumbnails from a CDN powered by GoGrid. Check out the map to see the where the CDN nodes are present.

Browshot hosting

We can provide affordable bandwidth and storage on our server, with images available over HTTP and HTTPS.

Please contact us to enable any of the 3 hosting options for your account, and for pricing information.

New thumbnail API

We have a new API call to retrieve thumbnails that is consistent with the other API calls. The old way of getting screenshots still works, and is still fully supported.

We keep improving our services on many levels as well. We have made screenshots much faster and even more reliable for both desktop browsers and mobile browsers.

See more...

We have just release a PHP library with full support for the API 1.7. The source code, with unit tests, is available on github, along with the Perl, Python and Ruby libraries.

You can download it from our website, and check out the code samples.

See more...

The API 1.7 offers additional meta data about the target page. If you use details=3 for screenshot/create, screenshot/info or screenshot/list, you get he following information about the page:

• URLs of images
• URLs of scripts
• URLs of style sheets (CSS)
• URLs of iframes
• URLs of embeds elements (including Flash objects)
• URLS of Java applets

All URLs are absolute.

We have also done some clean up:

• since all instances are now always active, the active data is not sent anymore
• browser/create and instance/create are disabled by default, only customers who have contacted us to get private instances can use them

The Perl, Python and Ruby libraries have been updates to handle the new details option.

See more...

We have made additional improvements to make screenshots faster. We have added 2 new options in the API 1.6 to tune the delay between the page load and the screenshots.

Some pages may require a few seconds after the page has loaded to run JavaScript, make AJAX calls, or start Flash elements. The delays used to be fixed: 5 seconds of delay if the page contains JavaScript, and other 10 seconds of delay if Flash elements are present.

With the API 1.6, you can tune these two values:

• delay=0 (0 to 5): never wait to execute JavaScript after the page has fully loaded
• flash_delay=0 (0 to 10): never wait for Flash to run after the page has fully loaded

You can save up to 15 seconds on each screenshot! You could also decide to introduce delays for specific URLs only, it is up to you.

Free screenshots limit

We have limited the number of free screenshots to 100 per account per month. This limit is reset on the first day of each month.

If you want to use free screenshots as part of a free and public website, contact us to see how we can offer more free screenshots for your account.

Private browsers

There are now only very few cases that require private browsers. Those may be needed mostly for very high volumes. We have decided to restrict the use of the the API browser_create and instance_create to those few users only.

See more...

Screenshots take only an average of 15s only, including the time to load the target page. But we are always trying to make the service better. Having even faster screenshots was the #1 improvement asked. We have heard you, and we have made several improvements.

Faster dashboard

Although most of the screenshots are done in 15 seconds or less, the dashboard was refreshed every 45 seconds only. This may have given the impression of slow screenshots too many users. The status of the screenshots is now updated every 2s.

Faster first screenshot

There used to be a delay of up to 15 second for the first screenshot requested on an idle virtual browser. This has been brought down to 1 second! The first screenshot should now be as fast as the following requests.

Faster page load

Most of the time required for a screenshot is spent waiting for the target page to load. We have tweaked all our desktop and mobile virtual browsers to browse the web faster. This should improve the loading time by about 15%.

We are looking at additional infrastructure improvements to decrease the load time of target pages.

We were able to roll out these improvements without any downtime, and without interrupting any of the screenshots in process.

See more...