Log out

Are you sure you want to log out?

Sitestream - Instruction and FAQ

Start implementing
  1. What is image streaming?
  2. Implementation instructions
    1. Script
    2. Prefix
    3. Scaling & resizing
    4. A/B testing
    5. Deploy to production
  3. Developer checklist
  4. Q/A testing in staging
  5. FAQ

1. What is Sitestream Engine?

The Sitestream Engine ensures every image displays instantly in the highest possible quality - for every user's connection speed, device and browser. We do this by teaching our system which image format that renders what image type the fastest in every unique user circumstance. The Sitestream Engine also ensures that every image is served using the least amount of data possible. That way you can be sure that your image delivery has the lowest possible data usage - while not sacrificing performance.

By simply implementing our script and the prefix on your regular HTML image tags we automatically fetch your images and ensure delivery is optimized for every unique visitor on your site. If you are implementing the service yourself (not using the WordPress plug-in), it is therefore recommended to place our lightweight and async script tag at the top of the tag.

2. Implementation instructions

Below follows instructions for implementing the Sitestream Engine technology. Please note that if any new pages and/or images are added to the website(s) after the implementation has been completed, the below described implementation steps are again required to be performed for the newly added pages and/or images.

If you have a Wordpress site, implement the technology using our Wordpress Plugin that you can download here.

To get a key to be able to implement the technology properly, please follow the instructions under Pricing.

2.1. Script

Add the script to the <head> tag

The script tag needs to be present on every page where the service should be used for streaming images. Your unique key (“YOUR_KEY” below) is required for the streaming solution to work. The same key is used both for the script and the prefix.

<script src="https://cdn.sitestream.co/YOUR_KEY/loader/latest.js" async></script>

The script tag should include the async attribute as in the example above.

For best performance, place the script tag at the first line, above all other script tags (but still within the <head> tag).

2.2. Prefix

Prefix all image tag sources

Prefix all image tag sources (src), including picture tags and src-set attributes. The Sitestream Engine supports CSS, so it is possible to prefix CSS background image URLs as well. We recommend that your website uses lazy loading. You can use whatever lazy loading you like. If you do not use any lazy loading, we recommend implementing native lazy loading on all image tags.

For instructions how to implement native lazy loading, see here: https://developer.mozilla.org/en-US/docs/Web/Performance/Lazy_loading

Your unique key (“YOUR_KEY” below) is required for the Sitestream Engine to work. The same key is used both for the script and the prefix.

The image prefix:

https://cdn.sitestream.co/YOUR_KEY/i?

Example

Original tag:

<img src=”https://example.com/image.jpg” >

With the prefix added:

<img src=”https://cdn.sitestream.co/YOUR_KEY/i?https://example.com/image.jpg” >

With the prefix and native lazy loading added:

<img src=”https://cdn.sitestream.co/YOUR_KEY/i?https://example.com/image.jpg” loading="lazy" >

Please note

A prefixed image URL should either:

  • A) include the full path to the image, i.e. including “https://www.example.com/”, or
  • B) include the URL relative to root, e.g. “/image.jpg”, however not a URL relative to page, e.g. “image.jpg”.

All prefixed images must be publicly available online, so that our image transcoder is able to access, download and transcode the images with purpose to enable the streaming functionality.

If an image is replaced on your site with the same URL and name, e.g. “background.jpg”, the new image must have a new name (e.g. “new_background.jpg”).

2.3. Scaling and resizing an image

The service features the possibility of scaling and resizing your image(s).

You have three options when scaling and resizing and image:

  1. Only use the “width” attribute, which will proportionally scale the image to the specified width (in pixels)
  2. Only use the “height” attribute, which will proportionally scale the image to the specified height (in pixels)
  3. Use both “width” and “height” attributes, which will scale and if needed crop the image according to the specified width and height
    1. If the width and height is not proportional to the original image size, the image will be cropped from the centre of the image

The image prefix including scaling:

https://cdn.sitestream.co/YOUR_KEY/w_500,h_300/i?

Examples

Example of scaling an image proportionally, using the “width” attribute to proportionally scale the image to a width of 500 pixels:

<img src=”https://cdn.sitestream.co/YOUR_KEY/w_500/i?https://example.com/image.jpg” >

Example of scaling an image, using the “width” and “hight” attributes to scale an image, and if need crop the image, to a width and height of 400 pixels:

<img src=”https://cdn.sitestream.co/YOUR_KEY/w_400,h_400/i?https://example.com/image.jpg”>

Please note

The first time a new image size is requested, Sitestream will download and on-the-fly scale the image and provide it to the site visitor. In parallel, Sitestream will transcode the image for that specific image size, and when ready the image will be served in optimal format to all future site visitors.

2.4. If you consider to A/B test the service

Only server-side A/B tests are supported (not front-end A/B tests)

Please note that only server-side A/B tests are supported, it is not possible to A/B test the image technology using a front-end A/B test (e.g. Google Optimize).

For server-side A/B tests: create a clone of the pages within the decided scope, with the image technology implemented. After Go-live, route the traffic 50% / 50% (or with any other ratios which you have decided) between the original pages and the image technology version of the pages.

2.5. Deploying to production (“go-live”)

You are free to start using the service as soon as you have signed up.

Depending on your needs and to verify correct implementation, you could use a step-by-step process for going live, but this is entirely up to you:

  • Optional: Start with non-public URL:s to verify the implementation on pages and images not available to the public
  • Optional: Start with a sub-set of the site to verify the implementation before scaling up to full site

3. Developer checklist

Below checklist is recommended to be reviewed after implementation, before go-live:

  • Make sure that no resource URLs except images of type JPG, PNG, Webp & Avif are prefixed
  • Make sure that the script is added to every page where the image prefix is used
  • Make sure that all images that are prefixed are publicly accessible over the internet
  • If the technology is implemented on staging environment for testing purposes, make sure that the images are not behind password protection or limited to a specific IP address

4. Q/A testing in staging environment

Here are some ideas of what to look for if you decide to test the solution before implementation on your site.

Visual review of images

  • Click through/scroll all pages in scope of the implementation
  • Review all images visually, e.g., images not broken, blurry or missing
  • Hover with mouse over images, and again verify images not broken, blurry or missing

5. FAQ

Can the streaming service handle relative URLs?

Yes, as long as they are relative to root

Does the Sitestream engine work with CSS image backgrounds?

Yes.

What image file types does the streaming service support for streaming?

JPG, PNG, Webp and Avif.

Why are the images not streamed when I’m testing the website in a local development environment?

The Sitestream Engine requires the images to be publicly accessible over the internet. If not, the Sitestream Engine will fallback/redirect to the original image link.

How does the solution work?

The first time an image is requested, e.g. when a site visitor (or a bot/crawler) is accessing a page, a request for the image will be sent to the Sitestream server. Since this is the first time the image is being requested, the image is not transcoded, so the visitor will simply be redirected to the original image source. In parallel the image will be downloaded and transcoded by Sitestream. When transcoding of the image is completed, the following image requests will be served by Sitestream to all users visiting the site. If Sitestream for some reason fails to transcode the image, site visitors will as a fallback solution be redirected to the original image source.

What happens if I cancel my subscription but still have your technology installed?

If you are thinking of cancelling your subscription, we would of course like to know why and if you have any problems related to the service, and see if we can support you in any way. Please contact us and we will do our best to help!

However, if you still want to cancel the subscription, you must first remove our tech from your implementation, since the service will become deactivated at the start of your next billing period and no longer work for streaming the content to your site’s visitors. So you will no longer be able to display any content to them if the technology is still installed but your subscription deactivated.

What happens if my payment fails?

If your payment fails, we urge you to ensure that you as soon as possible remediate the problem, e.g. ensures that the payment card had sufficient funds or change to a working card. However, if the payment continue to fail and we can’t come to a solution of the problem, we have the rights to suspend the service and will do so within three (3) billing periods. When that happens, the streaming will no longer work on your site and there will be no images shown if the technology is still installed.