To ensure our API’s smooth operation, we have introduced the maximum allowed sizes for assets used in web pages. After monitoring our API’s response times, we’ve seen some unusual spikes. Diving deeper, we’ve seen that these spikes were caused by uploading chunks with huge image data URLs (sometimes exceeding 5MB). After looking into this client’s use case, we discovered that an image-processing plugin generates huge data URLs for IMG elements. The existing approach was causing some side effects, such as having these chunks rejected on the server side because of exceeding the maximum request payload of 2MB or being dismissed on the client side by not being able to send these chunks with beacons.
Therefore, we have introduced a maximum size for assets as follows:
Stylesheets
Each CSS stylesheet and related resources, such as fonts, should be no more than 2MB in size after compression. This limit should be more than enough for any website.
Images
Images hosted on private hosts should not exceed 2MB in size. We do not employ size limits for pictures hosted on public hosts since the player fetches them directly from their hosting location.
Additionally, we have set the maximum size for data URLs to 64KB.
The recorder will log a relevant message and replace any image exceeding the above limits with a small semi-transparent pixel image.
Media
No specific size limits for CANVAS and VIDEO elements are applied. The recorder will downsize media elements accordingly to keep chunk sizes within acceptable limits.
The maximum media element height captured is 1024 pixels (FHD quality). The recorder will initially capture the element using HD quality (768 pixels) for large-sized media. If the client’s processing power is enough, it will gradually upgrade to FHD quality; otherwise, it will keep downgrading the capture quality until this quality fits the client’s processing power without hurting your UI performance.
At Cubicast, we strongly believe in the scalability of one, and whenever possible, we utilize the client’s processing power versus the server’s. This approach is essential for maintaining our API healthy and scalable and, simultaneously, offering competitive pricing given any number of requests.