Accelerating Webviews With Speed Kit

‍

Key Takeaways

• Disabled by Default: To ensure maximum stability and prevent conflicts, Speed Kit does not accelerate content within mobile app webviews by default.
• Core Technical Prerequisite: Speed Kit's engine depends on a service worker, which is often absent by default in standard webview environments (e.g., iOS WKWebView) and must be explicitly enabled by the app developer.
• Customer Responsibility: Activating webview acceleration is the sole responsibility of the customer's development team, who must implement the necessary technical requirements and validate the integration within their native app.

Introduction

A webview is a component used by native mobile applications to render web content—like HTML pages, articles, or product listings—directly within the app's interface. This allows businesses to seamlessly integrate their website into their iOS (WKWebView) or Android (WebView) applications without sending users to an external browser. While this creates a fluid user experience, the web content loaded in a webview can still suffer from performance bottlenecks. This document outlines how Speed Kit addresses webview performance and the necessary steps to enable acceleration.

Default Behavior: Prioritizing Application Stability

By default, Speed Kit is configured to not accelerate content loaded inside mobile app webviews. This is a deliberate precautionary measure to guarantee the stability of your application.

The Technical Challenge: A Two-Part Problem

Activating Speed Kit in a webview requires solving two distinct challenges: ensuring the service worker is active and confirming it can operate without interference.

1. Absent Service Worker Environment: The first step is enabling the service worker itself. In many standard environments, such as Apple's WKWebView for iOS, the service worker is not active by default and must be explicitly enabled by your app developer.
2. Interference from Native App Logic: Even with service workers enabled, the native application can unintentionally interfere with Speed Kit’s operations. For example, your app might already have its own code to handle network requests from the webview, perhaps to add custom authentication headers or to log traffic. This existing logic can prevent Speed Kit’s service worker from properly intercepting requests, leading to failed accelerations or unexpected caching behavior.

Because of these potential interactions between the native code and the webview, we disable Speed Kit by default. Activation requires testing within your actual application to ensure that Speed Kit can operate correctly alongside your existing app logic.

How to Enable Webview Acceleration: A Customer Implementation Guide

Activating Speed Kit within a mobile application's webview is the sole responsibility of the customer's development team. Our team is not able to debug native application code (e.g., in Swift, Kotlin, or Java).

While we are happy to provide support regarding Speed Kit's own configuration and behavior, your developers must perform the implementation and ensure a stable integration. Ultimately, the customer's development team is responsible for making the integration work within their unique application environment.

Technical Requirements

The primary obstacle is that standard webview configurations, especially on iOS, do not enable service workers by default. Your developers will need to adjust the webview's setup.

For iOS (WKWebView)

To enable service workers, the webview must be initialized with a custom configuration that uses a non-persistent data store. The key steps are:

1. Create a WKWebViewConfiguration object.
2. Set its websiteDataStore property to WKWebsiteDataStore.nonpersistent(). The default data store does not support the Service Worker API.
3. Initialize the WKWebView with this custom configuration.

For All Webviews

• HTTPS Required: The Service Worker API requires that all content is loaded securely over HTTPS.
• No Native Interference: The customer's team must ensure that no other native app logic (e.g., custom network interceptors for logging or header injection) is interfering with the service worker's ability to handle requests.

Validation and Activation Process

1. Customer Implements & Tests: Your team is responsible for implementing the technical requirements above and thoroughly testing the integration in a staging or development version of your app.
2. Request Activation: Once you have validated that Speed Kit works correctly and does not conflict with your app's functionality, contact our support team to request activation for your production environment.