Introduction

This page details best practices when creating experiences intended for web deployment. It is a companion to the article Performance tradeoffs between Player Licensing and Views Licensing. Be sure to review both articles.

An experience running on the web can, and most likely will be launched on smartphones or other mobile devices that might not benefit from a good internet connection. With this in mind, the creator of the experience must optimize it so that content is displayed quickly.

Respect these recommendations when building any experience that will be deployed to the web.

Aspect Ratio and Experience Resolution

Aspect Ratio

Each Intuiface experience has a defined pixel height and width, determining the overall aspect ratio. Player will respect the experience aspect ratio when displaying it in the web browser. We recommend you choose an aspect ratio compatible with as many devices as possible. The ideal experience aspect ratio will cover the entire screen with content, eliminating the visibility of black bars outside the edges of the running experience.

The table below represents a summary of existing ratios:

Looking at the table above, experiences created with an aspect ratio of 16:9 or 16:10 will be appropriate for most devices. For experiences created to run on mobile devices such as smartphones, an experience having a ratio of 19.5:9 will most likely cover the entire screen.

Experience Resolution

The difference between an experience's resolution and the target display's resolution (e.g. when the experience has a 4k resolution and the display is 2k) will impact the size of controls that appear in Intuiface assets (e.g. video controls, asset pin buttons, etc…). With this in mind, you should test the rendering on different target devices before going too deep into creating your Intuiface experience.

The images below show examples of different experience resolutions when viewed on Google Pixel 7, which has a screen resolution of 1080x2400.

• Experience resolution: 1080x1920 (aka FullHD)
  
  
  
• Experience resolution: 412x915
  
  
  
• Experience resolution: 2160x3840 (aka 4k)
  
  

As you can observe, the minimum size of the asset controls should enable the user to interact with them. However, the visual size differs from one experience resolution to another.

You can also design controls from scratch by creating them in Composer using the “Button Asset” or “Image Button Asset” and apply the desired triggers and actions to them. (For example, when a button is pressed, then start playback of a video). This approach enables full customization. However, keep in mind the created custom controls will be scaled according to the resolution of the experience - i.e. different button pixel dimensions will be required to achieve the same visual size.

Experience Resources

Experience resources include images, videos, and even fonts used in the experience. The larger the resource, the longer the experience will take to be downloaded and displayed. Media resources are one of the main factors impacting the loading of a web experience.

Another critical aspect not to be missed is the licensing type used for displaying the web experience. When creating a deployment URL, you must choose between Views Licensing and Player Licensing.

We detail how licensing impacts resource download, but here is a summary:

• Views Licensing: Resources will be streamed, meaning they will only be downloaded when displayed. The advantage of Views Licensing is the web page will be displayed more quickly when accessed since it will not need to download all of the experience's resources in advance.

• Player Licensing: All resources (displayed or not) will be downloaded as soon as the experience is launched. This means the loading indicator will be displayed as long as it takes to download all the resources. The advantage of this mode is faster scene-to-scene transitions and the ability to run offline.

Let’s look at how to optimize the media assets you will use in your Intuiface experiences for the web.

Images

Image Size

Images have a predetermined fixed size. An Intuiface experience loads the images and displays them in a container - the Image Asset - which, in turn, has a size that can either be fixed or variable (e.g. when resizing the container using pinch-to-zoom gestures on a touchscreen).

Let's start with the case of a fixed-size container. Ideally, the image should be the same size as the Asset Image container that will display it. For example, if the Image Asset is 500 pixels high and 500 pixels wide, the provided image file should also be 500 pixels high and 500 pixels wide. If a larger image is used - for example, 1000 pixels high and 1000 pixels wide - then both download and display times will take longer without adding any visual value to the user experience. In addition, the browser will have to scale the image downwards, negatively affecting the rendering speed. In this case, image quality will even be lost.

In the case of an Image Asset that can be enlarged, it is advisable to provide the image at the maximum potential size. For example, if your Image Asset container is 500 pixels high and wide, but your design permits users to enlarge the image by 3x, then use a version of the image that is 1500 pixels high and 1500 pixels wide.

Device-to-Pixel Ratio

Some devices have a physical resolution that differs from its logical resolution. This means that for one pixel of the experience, the device will use several physical pixels of the screen. This is also known as Device Pixel Ratio (DPR). Current smartphones have a DPR of around two, which means that to display one pixel of the experience, they will use two physical pixels of the screen. This has an impact on the size of the images to be used. Indeed, if we take our previous example with an Asset Image of 500 pixels high and wide, we ideally need an image of 500 pixels high and wide for a device with a DPR of one. On the other hand, if the DPR is two, the ideal image size will be 1000 pixels high and wide because it will actually be displayed using 1000 physical pixels.

NOTE: On a smartphone, this difference may not necessarily be very visible to the user.

Image Optimization

When saving an experience, Composer automatically generates alternative images for any image used in an Image Asset that is not the same size as the Image Asset container.

Let's take the example of a 500-pixel Image Asset container that can be enlarged to triple its size. We explained that, in this case, it is better to use an image of 1500 pixels. However, Composer generates a copy of the image resized to the original size of the Asset Image container. It is this generated image that will be used in the Image Asset as long as Player considers it preferable to the original, larger image. Thus, the larger image will only be loaded and displayed when the Image asset is enlarged.

This generation of alternative images is only carried out by Composer for images coming from Content Library. If an image comes from a Headless CMS base, through a Web API Interface Asset, from an Excel spreadsheet, or web storage (e.g. accessible through a URL), then Composer will not have an alternative image. As a result, you must ensure that the images from these external sources are properly sized.

Maximum Image Size

Keep in mind that a device's Graphical Processing Unit (GPU) has its limits. It cannot load/display images beyond a certain size and will cause a browser crash. So don't use images that are, for example, 20,000 pixels high and wide.

Image Format

Image format also plays a vital role in file size. Indeed, images can be compressed into a lighter format for the web. For many years, PNG and JPG formats were the most popular web formats, but new formats specially created to make the web faster have emerged. This is the case of the WebP format developed by Google.

The WebP format is now supported by most browsers (e.g. see WebP image format | Can I use... Support tables for HTML5, CSS3, etc ).

Converting all images used in your experience into the WebP format is a good practice. One effective tool for the conversion is Squoosh. This converter enables you to convert images into a specified file format, resize them, choose the compression quality, and even view/compare the converted image with the original one.

Videos

Video files can also have a major impact on experience performance.

Remember, as previously explained, a web-deployed experience running in a Player-licensed experience will download the video entirely when the experience is launched. In contrast, a web-deployed experience running in a Views-licensed experience will only stream the video content when the user requests playback.

This means videos will significantly impact the loading time of a Player-licensed experience.

When thinking of size and compression, avoid using GIFs. The GIF format is a highly demanding and poorly optimized resource. You should always prefer video format, which can be better compressed and streamed.

Just like images, videos can also be compressed. For video, there are two aspects to take into consideration:

1. video container (mp4, webm, etc.)
2. video codec (h.264, av1, etc.)
   Today, the AV1 codec offers the best compression rate. However, it is not yet supported by all browsers (Can I use av1 in my preferred web browser? ).

To ensure compatibility across all browsers, it is preferable to use an mp4 container and an h.264 codec (Can I use h.264 in my preferred web browser? ).

You can use tools such as ffmpeg to convert your GIFs and videos. Below, you will find some handy command lines for converting video files on a Windows-based device using ffmpeg:

ffmpeg -i input-video.mp4 -c:v libx264 -preset slow output-video.mp4

ffmpeg -i input-animated.gif -movflags faststart -pix_fmt yuv420p -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" output-video.mp4

For websites, another approach is to use YouTube videos when possible. Using YouTube videos eliminates your responsibility for managing quality, as it automatically adapts video quality according to the available bandwidth. So, if the network is bad, the YouTube video will be streamed in lower quality (240p, for example), but it will not block the Player and the rest of the experience from loading. Also note that a YouTube video is always streamed (never downloaded), even in the case of web-deployed experience running with Player licensing. Therefore, a YouTube video will not increase the resource download time when launching the experience, regardless of the licensing option.

Fonts

Fonts are another resource that can affect the loading time of a web-deployed experience, as their associated files can be quite large.

Font files will not be downloaded onto a device for web-deployed experiences if the font is already present on that device, speeding the loading time. We recommend you consider using fonts likely to be installed on any device, such as the Arial font.

If you prefer a custom font, choose lighter fonts like Google Font. Use it for your Text, Button, and other assets. Composer's default font is Segoe UI; its font file adds almost 8MB to your experience, a large amount.

To optimize fonts further, third-party tools like FontForge can reduce the font size by removing characters you don't intend to use. However, this approach does require some technical knowledge.

Total Experience Size

The total size of the experience is important because the browser can use only a certain amount of your device’s disk space. As you can read in this third-party article, Storage for the Web :

• with Chrome, a website can use up to 60% of the on-device storage

• with Firefox, a website can use up to 50% of the on-device storage

• with Safari, a website can use up to 1GB of the on-device storage
  Beyond that, the browser will display a popup every 200MB to ask the user if it can use more disk space.

When designing a web-deployed experience that could run in any browser, keeping the experience size below 1GB is preferable.

Also, specific to Safari, web-deployed experiences share a domain quota. Since all Intuiface experiences are hosted on web.intuiface.com, multiple web-deployed Intuiface experiences running in Safari on the same device will share the quota. To avoid filling the storage quota when running multiple experiences under the same domain in Safari, the sum of the experiences' storage requirements must be below 1GB.

• NOTE: Each Progressive Web App running on MacOS, iPadOS, or iOS has its own dedicated storage space and is thus not affected by the shared domain quota rule.

Video explanation - Design guidance for web-published experiences

You will find in the Quarterly Q&A Live - Winter Edition - January 2024 video, some design suggestions and performance optimizations for your web experiences.