Goal

Your app feels slow to start, hangs on a spinner, or sometimes times out before it ever opens. This article helps you find out what’s actually slow before you touch a single setting — then walks you through fixing the usual suspects: a bloated data payload, caching that got switched off, a slow plugin along for the ride, or images that are just too heavy.

One rule matters more than any other here: measure before you change anything. A slow launch can come from several different places, and the fix for one cause is the exact opposite of a setting some apps turn on deliberately. Flip switches before you measure and you can easily make things slower, or bury the real problem under a new one. That’s why Step 1, always, is timing the actual request your app makes on launch.

Background: what happens when the app launches

When the app starts, it reaches out once to your WordPress site for its phone data — a single JSON payload holding everything the app needs to draw itself: buttons, layouts, tab bar, forms, notifications, content sections, and whatever your feature plugins add. The app can’t render until that payload arrives, so your users are staring at a spinner the whole time it’s in transit.

A few facts about that payload explain almost every slow-launch report:

• It can be large. A typical payload runs from the tens of KB up to a couple hundred, and grows further on sites with a lot of forms or content sections. The bigger it gets, the longer it takes the server to build and the longer it takes to travel over a phone’s connection.
• It’s assembled by many contributors. The payload gets built in stages, and every active feature plugin adds its own section along the way. Run a lot of plugins, or just one slow one, and that time shows up on every single launch.
• It’s cached, so repeat launches are cheap. MAM Suite tracks this with a cursor — a single value the server updates whenever anything on the site changes (a post, a user, a setting). The app remembers the cursor it saw last time and hands it back on the next launch. If that cursor still matches — nothing’s changed since — the server skips the rebuild entirely and just says “no new data,” and the app keeps what it already has. If something changed, the cursor no longer matches, and the server rebuilds the full payload and sends it back with a fresh cursor. That’s why a warm launch with nothing new is tiny and fast, while a cold launch — or the first one after any change — means the full build.

Put those together and a slow launch almost always traces back to one of four things: a genuinely large payload, caching that’s been disabled (so every launch turns into a cold rebuild), one slow contributor, or a heavy network transfer — usually images. The steps below check each of these, roughly in that order.

Prerequisites

• Admin access to Mobile App Manager for the affected app.
• The app installed on a device or simulator where you can reproduce the slow launch.
• For the timing step: the ability to load a URL in a browser, or basic comfort with browser developer tools or curl. A developer can do this part if you can’t.
• Ideally, a sense of when it got slow — after adding a plugin, after a content import, after changing a setting — which often points straight at the cause.

Steps

1. Measure the launch request first

Before you touch anything, time the request your app actually makes on launch. It fetches its payload from your site’s admin-ajax.php endpoint using the phone-data action. You’re after two numbers here: how long the request takes and how big the response is.

Watching it happen live is the most reliable way to get those numbers:

• In a browser’s developer tools (Network tab), reproduce a launch — or load the phone-data endpoint directly, if a developer hands you the URL — and read the time and size columns for that request.
• With curl, a developer can hit the same endpoint directly and check the total time and the bytes downloaded.

Write both numbers down — completion time and response size. That’s your baseline, and everything you try from here gets judged against it.

Two reference points help you read what you just measured:

• A cold launch (no cached data yet — first install, or after sign-out) builds the full payload and is the slowest case.
• A warm launch (the app already has the current data cached) should send far less and finish noticeably faster.

If a warm, repeat launch is also slow and large, caching isn’t doing its job — head to Step 2. If only that first launch drags but repeats come back fast, the cache is working fine and you’re dealing with cold-start payload size instead — head to Step 3.

Tip: test the warm case the way a real user would hit it — launch the app once, then fully close it and reopen it (backgrounding it doesn’t count). That second launch is the one that should feel the benefit of the cache.

2. Confirm caching is actually on

If repeat launches stay slow and the response never shrinks, the launch cache is probably getting bypassed. There are two usual reasons the server keeps rebuilding the full payload instead of handing back a cheap cached one:

1. You’re testing as an admin in preview/cloning mode. When an admin previews the app as another role, MAM deliberately rebuilds fresh data on every request, so the preview never goes stale. That’s by design — but it also means your launches as an admin will always look slow. Test with a normal, non-admin user account before you conclude the cache is broken.
2. Caching has been turned off for the app or a user. The Disable Caching setting (in the app’s General settings) does exactly what it says — with it on, every launch becomes a full cold build, which is precisely the “always slow” symptom you’re chasing. Some sites turn this on deliberately, so freshly saved settings reach users instantly, but that convenience comes at the cost of launch speed.

Check whether Disable Caching is switched on for your app. If launch speed matters more to you than instant settings updates, turn it off and re-measure. If you genuinely need settings to apply immediately, that’s a trade-off you’re choosing on purpose — see Related for the article on forcing reloads, and treat the slower launch as the price of that choice.

Turning Disable Caching off restores the launch cache for everyone on that app — re-measure a normal user’s warm launch afterward to confirm it’s actually helping.

3. Reduce the cold-start payload size

If cold launches are slow because the payload is genuinely large, the fix is simply sending less. Larger payloads usually come down to how much stuff the app is asked to load up front. Look for:

• A very large number of buttons, tabs, or content sections configured to load on launch. Everything on your home screen and in the main navigation gets built into that payload. Trim the items nobody uses, or move heavy content behind a tap instead of loading it up front, and the payload shrinks with it.
• Many forms. Every form the app knows about adds its definition to the payload, so an app with dozens of forms is carrying a heavier launch by default. (Forms get their own cache, which helps on repeat launches — see Step 5 — but a large form count still adds weight the first time around.)
• Large blocks of content embedded directly in the payload, rather than loaded on demand.

You don’t have to guess at this: the size number from Step 1 already tells you whether it’s worth pursuing. If your payload came back small but launches are still slow, the weight is sitting somewhere else — likely a slow contributor (Step 4) or images (Step 6) — and trimming content here won’t move the needle.

4. Look for a slow contributor (feature plugin)

Every active feature plugin gets a hand in building the launch payload, each contributing its own section. Most of the time that’s fast. But one misbehaving or heavy plugin can slow down every launch, because the server has to wait on all of them before it can send the response.

To find a slow contributor:

• Correlate with when it got slow. If launches started dragging right after you activated a feature plugin, or imported a large content set tied to one, that plugin is your prime suspect.
• Bisect by deactivating. On a staging or test copy of the site — never experiment on the live app’s site — deactivate feature plugins one at a time and re-measure the launch (Step 1) after each. When the time drops sharply, you’ve found the plugin responsible.
• Watch for a plugin that invalidates the cache on every launch. The launch cache runs on a single site-wide cursor that changes whenever site data changes — a post, user meta, post meta, a term. A plugin that writes something on every phone-data request (saving a post, updating user or post meta on each launch) bumps that cursor every single time, which forces a full cold rebuild on every launch and quietly defeats the cache for everyone. If repeat launches stay heavy even with caching switched on (Step 2), this is worth suspecting. It’s a developer-level fix from here — capture which plugin is responsible and hand it to support or your developer.

Don’t test this by deactivating plugins on the production site. Deactivating a feature plugin pulls its content from the live app for every user while it’s off — use a staging copy instead.

5. Check whether form caching is the bottleneck

Forms get their own cache. MAM stores each form’s transformed definition so the launch doesn’t need to rebuild every form from scratch each time. When that cache is cold, or has just been cleared, the very next launch has to rebuild every form at once — which can make that one launch noticeably slower until the cache warms back up.

In practice, that looks like: launches are fine, then one is suddenly slow — right after a form gets edited, or after a bulk change — then they’re fine again. That’s just the cache re-warming, and it usually corrects itself. If launches are persistently slow on a form-heavy app, the form count itself is the real weight (back to Step 3). If they’re only occasionally slow, right after form edits, that’s the expected re-warm — nothing to fix there.

6. Rule out heavy images

Even with a small, fast payload, the app can still feel slow if the first screen is loaded with large images. The payload only carries image URLs, not the images themselves — the app downloads each one separately as it draws the screen. A home screen with several multi-megabyte images will look slow to finish, even though the data payload arrived quickly.

Check the images used on the launch screen and main navigation:

• Are any of them very large (several MB, or huge pixel dimensions for what’s a small thumbnail on screen)?
• Could they be resized or compressed to web-appropriate sizes before upload?

Cutting image weight won’t change the data-payload numbers from Step 1, but it will make the first screen feel like it finishes faster, because that’s exactly what it’s fixing. If images on the website itself are slow or broken, that’s a different problem — see Related.

7. Re-measure and compare

After any change — re-enabling caching, trimming the payload, disabling a slow plugin, shrinking images — repeat Step 1 and compare the result to your baseline. Confirm the launch time actually dropped before you move on. That’s how you know you fixed the real cause, rather than just changing something that felt productive.

Quick reference: which cause is it?

Related

• Settings change not showing up in the app — covers the “force reload on open” trade-off that disables launch caching
• Images won’t load in the app — for images that are broken, not just heavy
• Cursor cache mechanism — how the launch cache decides whether to re-send the payload (developer reference)
• Form cache and invalidation — why a form edit can make one launch slower (developer reference)
• Phone data pipeline overview — how the launch payload is assembled (developer reference)

What’s next

If you’ve measured the launch, confirmed caching is on for a normal user, trimmed the payload, ruled out a slow plugin, and it’s still slow or still timing out, the problem needs a server-side trace. Capture your baseline numbers from Step 1 — time and response size, for both a cold and a warm launch — note anything that changed on the site recently, and open a support ticket so the phone-data build can be profiled directly.