We are working on global access for CoreCharge Cloud, including the public website, management dashboard, and H5 rental flow.
By H5, I mean the mobile web flow a renter opens after scanning a station's QR code. A visitor may arrive on an unfamiliar mobile network, with no previous session and no cached assets.
Our delivery work spans DNS, CDN, and edge acceleration. We are now thinking more carefully about the measurements and cache boundaries that should guide that work.
The practical goal is a usable rental session across the regions we serve. We do not yet have a published benchmark showing that the complete flow is fast everywhere.
Break the journey into measurable steps
For a first-time renter, I would separate at least these stages:
- Resolve the hostname and establish the connection.
- Receive the initial HTML.
- Load the assets needed to display the rental screen.
- Resolve the station and fetch the relevant rental terms.
- Let the user interact with the page.
- Complete the provider-dependent payment interaction.
- Show the backend's current rental and release state.
A fast image response tells us little about a slow station lookup. A fast page render tells us little about a delayed payment result.
Give static and private responses different policies
Versioned JavaScript, stylesheets, and public images are natural candidates for long-lived caching when their URLs change with their contents.
Public HTML needs a policy that accounts for deployments and content updates. Rental terms also need careful treatment: showing stale pricing is a different problem from showing an older product image.
Authenticated dashboard responses, user-specific orders, payment state, and refund details need explicit protection from shared caching. Cache keys, bypass rules, response headers, and actual edge behavior all need to agree.
This is why “enable caching for the whole site” is too broad a specification for our application.
Measure the browser and the backend
For browser experience, LCP, INP, and CLS provide useful loading, interaction, and visual-stability signals. I would look at real-user distributions by region and device rather than rely on a single local test.
For the application, I would also measure station lookup time, API latency, payment initiation errors, and the time spent waiting for a confirmed rental state.
Cold-cache and warm-cache visits deserve separate test runs. So do mobile connections and desktop connections.
The diagnostic question is: which stage is slow for which users?
Reduce avoidable work before adding infrastructure
Our next-pass checklist includes smaller images, fewer initial requests, less JavaScript before the rental form becomes usable, and a review of third-party scripts.
If static delivery is already fast but dynamic requests remain slow in a region, the next investigation moves toward connection reuse, origin processing, database access, routing, and the distance to the authoritative service.
Moving more computation to the edge can help selected workloads. It also introduces decisions about state, consistency, deployment, and debugging. We want measurements to show where that complexity would help.
The question for other teams
Our broader aim with CoreCharge Cloud is to make shared-device services easier to operate and access. For the H5 flow, that means users should be able to understand the rental terms and reach a usable session under ordinary mobile conditions.
If you were improving a mobile rental or checkout flow used across regions, what would you measure first? And what told you that CDN and frontend work were no longer enough to address your slowest paths?
I would be especially interested in experiences with regional real-user monitoring, safe cache policies, and dynamic API latency.
Disclosure: I work on CoreCharge Cloud. This post describes our own optimization work and open engineering questions. It was prepared with AI assistance. No global latency reduction, availability level, or completed performance result is claimed here.
Top comments (0)