Why Slow Location Calls Stall Your Hybrid App—and How to Fix It

Background

Our project is a hybrid application running inside Mobile QQ. After entering page A, we need to decide—based on the user's geographic location (which can be cached)—whether to redirect to a new gray‑scale page B or continue rendering page A.

The "Most Proper" Implementation

The straightforward approach is to obtain the user's location, call a backend CGI to get the city, and then decide whether to redirect.

Pseudocode

// Call the Mobile QQ API to get the current location (latitude & longitude)
getLocation(function(data){
    // Call the CGI to obtain city information
    getCity(data, function(res){
        if(res.city=='深圳'){
            // Redirect to page B
            jumpTo('pageB');
        } else {
            // Continue rendering page A
            init();
        }
    });
});

Why This Doesn’t Work Well

The getLocation client API is time‑consuming, typically taking 2–5 seconds even with caching, plus an additional 200 ms overhead.

The backend CGI call adds another 50–150 ms on Wi‑Fi, and more on slower networks.

WebView initialization, loading of JS/CSS/images, and other CGI requests contribute several hundred milliseconds.

Consequently, first‑time users on slower devices or networks face noticeable loading delays.

Further Analysis

Given the latency issues, we asked: do we really need real‑time precision?

Do We Need Real‑Time Accuracy?

Most users stay in the same city for hours or days, and the feature is a gray‑scale rollout, so strict timeliness isn’t critical.

Caching the City Name

Instead of caching the raw location, we can cache the resolved city name.

if (!existCity) {
    // Get location and resolve city
    getLocation(function(data){
        getCity(data, function(res){
            if(res.city=='深圳'){
                jumpTo('pageB');
            } else {
                init();
            }
        });
    });
} else {
    // Use cached city
    init();
}

Handling the First Visit

For first‑time users without a cached city, we still face the delay; we cannot simply ask them to wait.

Pre‑populate the Cache

One approach is to release a version that, after the page loads, silently obtains the location and stores the city in localStorage. Subsequent visits can skip the network call.

“Get the Coupon First, Then Enjoy the Discount”

Pre‑caching requires a new release, which may affect other users, but it can be worthwhile if the performance gain is significant.

A refined solution shows page A immediately, starts fetching the city in the background, stores it, and on the next visit redirects to page B based on the cached city.

Final Solution and Takeaways

The final strategy mirrors offline‑package mechanisms: if no local cache exists, load the online version while a background thread fetches and caches the data; on subsequent visits the cached data enables instant redirection.

If you depend on a time‑consuming operation, consider changing the workflow—e.g., make it asynchronous or cache results—to mask latency and improve user experience.