Technical audit report for UpKeep
UpKeep markets the best mobile experience in CMMS. Its own mobile site is the slowest of the three leading vendors.
On desktop, upkeep.com is in good shape — a performance score of 87, an LCP of 1.1 s, and structured data most SaaS marketing sites never bother with. Nothing here is neglect.
On a mid-tier phone over 4G, the same page scores 38–41. The hero takes 7.7–9.8 s to paint, against Google's 2.5 s threshold for “good.” Limble's homepage does it in 2.6 s.
The cause is not your engineering team's code. Roughly two thirds of the page — 3,247 KB of 5,117 KB — is third-party marketing and analytics tags. That makes this a marketing-owned problem, and it is fixable without touching the product roadmap.
Lighthouse 13.4.1, mobile emulation (Moto G Power class, 4G throttling), 3 runs. Ranges shown wherever runs disagreed.
Findings
Ranked by commercial impactThe mobile site undercuts the mobile-first product claim
UpKeep's differentiator in this category is the mobile experience — technicians on a plant floor, on a phone. A buyer who researches that claim from their phone waits roughly eight seconds for the first meaningful pixel.
Speed Index — how quickly the page visibly fills in — is 12.2 s. For most of that window the visitor looks at an empty screen while the strongest proof point in the pitch goes unmade.
- Largest contentful paint
- 7.7 s
- Speed Index
- 12.2 s
- Total blocking time
- 1,840 ms
- Main-thread work
- 8,413 ms
- JavaScript execution
- 4,627 ms
Your own tag stack is the single largest cause
Six third-party vendors consume 1,944 ms of main-thread time between them. This is the rare performance problem that does not need a product sprint — it needs a decision about which tags load, when, and whether each still earns its place.
Two findings worth a direct answer: two separate Meta pixel configurations load on the same page, and three Google containers initialise alongside them. Both may be deliberate. If either is a leftover from a past campaign, it is pure cost.
This is the one we would start with — biggest lever, least disruption.
- 559 ms
- 218 KB
- Google Tag Manager
- 517 ms
- 877 KB
- Intercom
- 327 ms
- 286 KB
- Microsoft Clarity
- 214 ms
- 33 KB
- HubSpot
- 63 ms
- 106 KB
- CookiePro
- 56 ms
- 247 KB
Meta pixels: 1406756152961377, 1848569805443673
Google containers: GTM-TJL6ZVR, G-4XCTC3D1W0, AW-872384478
157 of 170 images ship without dimensions
Images without explicit width and height force the browser to reflow as each one arrives. Layout shift is currently low at 0.037, so this is not hurting rankings yet — but it is a standing cause of the jumpy feel on slower connections, and one of the cheapest fixes on this list.
Gatsby is in maintenance mode — a slow-burning platform risk
The site runs on Gatsby. Since Netlify's acquisition the framework is maintained but not advanced — React 19 support did land in January 2026, so this is not an emergency. The practical cost is the plugin ecosystem, much of which is now unmaintained, and the dependency breakage that tends to surface at each Node upgrade.
Worth a deliberate decision this year rather than a forced one later. We rebuilt CrowdSec's site from exactly this position onto Next.js with a headless WordPress back end.
Accessibility gaps concentrated on touch
An accessibility score of 86 is respectable. The notable entry for a mobile-first brand: three touch targets fall below the minimum size or spacing. Alongside those, twelve aria-hidden elements contain focusable children (a keyboard trap pattern), eight elements fail contrast, and the page has no main landmark.
Competitive benchmark
Mobile, same conditions, same dayLargest Contentful Paint
Seconds to paint the main content. Lower is better.
Scale 0–10 s. Only Limble clears the threshold Google uses as a ranking signal.
What upkeep.com's 5,117 KB is made of
Mobile homepage, total transferred bytes.
142 of 202 requests go to third parties.
| Metric | UpKeep | MaintainX | Limble |
|---|---|---|---|
| Performance | 38 | 47 | 81 |
| LCP | 7.7 s | 3.7 s | 2.6 s |
| Total blocking time | 1,840 ms | 1,150 ms | 430 ms |
| Speed Index | 12.2 s | 8.2 s | 3.8 s |
| Page weight | 5,117 KB | 12,469 KB | 2,638 KB |
| Accessibility | 86 | 89 | 78 |
| Desktop performance | 87 | 92 | 89 |
Worth noting against our own argument: MaintainX ships more than twice UpKeep's bytes yet paints in half the time. Weight alone does not cause slowness — what matters is how much of it blocks rendering. UpKeep's problem is specifically blocking work on the main thread, which is why the fix is sequencing rather than deletion.
Credit where due
What upkeep.com already does better than most
- Structured data is genuinely strong — 13 schema types including
SoftwareApplication,OfferandFAQPage. This is the markup that wins rich results, and most competitors skip it. - Every one of 170 images has alt text. Rare at this scale.
- Security headers are mostly in place — CSP, X-Content-Type-Options, X-Frame-Options and Referrer-Policy all present. HSTS and Permissions-Policy are the two absent.
- SEO fundamentals are clean — canonical set, robots.txt correct, sitemap properly declared, custom 404 in place. Score of 92.
- Desktop performance is good. This audit is about one platform, not the whole site.
What we would do first
Estimates from the measurements above1.Tag audit and load sequencing
2–3 daysInventory every third-party tag against a named owner and a live use. Retire what no longer earns its place, resolve the duplicate Meta pixel question, and defer the rest behind first paint so tags stop competing with the hero.
Largest single lever — targets the 1,944 ms of third-party main-thread time
2.LCP path
3–4 daysPreload the hero image, serve it at mobile dimensions in a modern format, and clear the render-blocking work sitting in front of it.
Target: LCP under 2.5 s on 4G
3.Image dimensions and delivery
2 daysAdd explicit width and height across the 157 images missing them, and correct the oversized assets flagged in the delivery audit.
Removes a standing layout-shift risk before it becomes a ranking one
4.Framework position — assessment only
Scoped separatelyA written view on staying with Gatsby versus migrating, with real costs on both sides. Not a month-one project, and not something to decide under pressure.
Decision input, not a commitment
Items 1–3 are roughly three weeks of one engineer — the scope we would propose for a first month.
We are the engineering team for marketing teams
Most marketing teams do not have a developer problem. They have a queue problem — the roadmap is full, marketing sits behind product, and the work that would move the number keeps slipping a quarter.
Codalent is a plug-and-play dev team on subscription. We take the backlog your engineers will not get to this quarter, and your engineers stay on the product.
Websites & landing pages
Campaign pages and full rebuilds, shipped in days rather than quarters.
Marketing stack & analytics
Tag hygiene, tracking you can trust, and the dashboards that read it back.
AI development & automations
The repetitive work in your funnel, handed to something that does not sleep.
Experimentation & A/B testing
Tests that actually ship, instrumented properly enough to call a winner.
Mobile app development
When the campaign needs more than a page behind it.
Hosting, DevOps & reliability
The part nobody asks for until the launch morning it fails.
We rebuilt CrowdSec’s site onto Next.js with a headless WordPress back end, and have been Traefik Labs’s web team since 2019.
Walk through the fixes with us
Thirty minutes, no deck. We go through the findings above, you tell us which ones matter to your numbers, and we scope the first month against them.
- Which findings actually move your pipeline, and which are noise
- What we would ship in the first month, and what it would cost
- How we work alongside your existing engineering team
Opens our calendar right here — the report stays put.
Prefer email? Reach us through codalent.com.
Method
Everything here comes from public pages, measured the same way for every site on the same day. No access to UpKeep systems, analytics or internal data was used or needed.
- Tool
- Google Lighthouse 13.4.1, headless Chrome
- Mobile profile
- Moto G Power class emulation, 4G throttling, cold cache
- Runs
- 3 per page; ranges shown wherever runs disagreed
- Variance
- Performance 38 / 41 / 41 · LCP 7.7–9.8 s · TBT 0.9–1.8 s
- Captured
- 15 September 2026
- Scope
- Homepage only, per site
Lighthouse scores move between runs, so single figures are quoted as medians and volatile ones as ranges. The structural numbers — page weight, request counts, third-party share, tag inventory — do not fluctuate, which is why the argument rests on those.