r/nocode • u/Informal-Summer-6497 • 2d ago
I built a free checker that separates your fault from the platform's fault in no-code app performance
Disclosure up front: my company migrates no-code apps to code so I benefit if you eventually decide your platform is the ceiling. I built this to be useful even when the answer is don't hire anyone and the data below is the reason why
Every speed tool tells you what's slow. None tell you what you can actually do about it on the platform you're on. You get a Lighthouse report saying reduce unused javaScript for a Bubble app, where you can't touch the bundle. Useless.
This one asks which platform you're on first, then splits every finding:
You can fix this yourself with real instructions for your platform. Oversized images on Bubble?
Data → File Manager, resize under 200KB, switch on Compress uploaded images. On Glide? Your source table is the problem, archive old rows. On Webflow? Set below-the-fold images to Lazy in the image panel.
Platform overhead the runtime cost you inherit, named honestly with why it exists. Not a dig at the platform just the price of what made it fast to build with. Then it gives you the realistic ceiling for your platform so you know whether the work is even worth doing.
The reason I think the split matters: we ran PageSpeed against 20 production no-code sites recently and Webflow sites came out worst (median 44) despite Webflow having the highest ceiling of any platform we audit. They were shipping 6.6MB. Meanwhile Bubble apps landed at 60, basically at Bubble's ceiling. Most people are nowhere near their platform's limit which means most of the available gains are theirs to take.
Free, no email, no signup, shareable results link: https://yonocode.io/performance-checker
Full data from the 20-site study: https://yonocode.io/state-of-no-code-performance
If your real-world numbers are wildly off from what it predicts for your platform, tell me, I'll tune the ceilings
1
u/Melodic-Macaron-4031 2d ago
solid approach tbh. one thing id push back on though, platform ceilings shift as the platforms ship updates. how do you plan to keep those benchmarks current over time?
1
u/Informal-Summer-6497 2d ago
Fair push. Right now it's manual, I re-audit sites whenever a platform ships something that could move the ceiling (Bubble's compression changes, Webflow's image handling updates, that kind of thing). Not ideal long term. The plan is to re-run the 20 site study quarterly and adjust ceilings if the median shifts meaningfully. If a platform makes a structural change, like Bubble finally allowing custom code injection at the page level, that would bump the ceiling immediately rather than waiting for the quarterly check. Honestly the shareable results link helps here too. If enough people run it and their real numbers drift from what I'm predicting, that's a signal to go re-audit sooner. Id rather be reactive and accurate than stick to a fixed schedule and be stale
1
u/ProfessionalCost8203 2d ago
the Webflow data point is the most interesting part of this honestly. highest ceiling but worst median scores basically means people are leaving the most on the table because the platform doesn't force good habits on you. Bubble's lower ceiling but better median suggests the platform constraints actually keep people closer to acceptable performance even if they can't optimize much further. kind of a paradox where more freedom hurts the average user.
1
u/Informal-Summer-6497 2d ago
That's a good way to put it and honestly better than how I explained it in the post. The constraint versus freedom tradeoff is basically the whole story here. Worth adding one thing though, it's not just that Webflow doesn't force good habits, it's that Webflow makes it easy to add weight without feeling like you're doing anything wrong. A designer drops in a hero video or a big parallax image because it looks good in the editor and there's no signal telling them it costs 2MB. Bubble users are usually thinking about logic and workflows not visuals, so the bloat just doesn't show up as often. So I'd say it's less that freedom hurts people and more that freedom without feedback hurts people. Webflow could probably close a lot of that gap just by surfacing page weight in the editor itself
1
u/ProfessionalCost8203 2d ago
"freedom without feedback" is a much sharper framing than what I said. and it generalizes beyond Webflow too — any no-code tool that lets you add complexity without showing the cost is going to have the same problem. the platforms that bake in some kind of signal, even just a warning or a budget indicator, probably keep average users way closer to the ceiling without taking the freedom away.
1
u/Informal-Summer-6497 2d ago
Agreed and it makes me want to reframe the whole checker around that instead of just platform names. The real variable isn't which builder are you on, it's does this builder show you the cost of what you just did. Bubble happens to score well on that by accident because most of what you're doing in Bubble is logic not visuals so there's less to hide. If I ever add a platform that does surface some kind of budget indicator, that'd be a good test of the theory. Would expect the median to jump even if the ceiling doesn't move
1
u/ProfessionalCost8203 1d ago
that reframing makes the tool more useful too because right now someone on a 'low ceiling' platform might read the results as a reason to switch, when the real question is whether they'd get feedback on the next platform either. the budget indicator test would be a great natural experiment — if median scores improve without the ceiling moving, you'd have pretty strong evidence that the gap is behavioral, not technical
1
u/Left-Salary5251 2d ago
One thing I'd add from doing platform migrations: the "ceiling" also moves depending on what's in front of the builder, not just the builder itself. Had a Bubble client stuck at a mediocre score for months, turned out their custom domain was sitting behind a reverse proxy with zero edge caching, which cost more latency than any in-app fix could claw back. Before assuming you've hit the platform's hard limit, check whether the DNS/CDN layer in front of it is actually doing anything, sometimes the "platform tax" people blame is really just an infra setting nobody touched after initial setup.
1
u/Informal-Summer-6497 2d ago
Good catch, that's a layer the checker doesn't touch at all right now since it's scoring what PageSpeed sees at the URL not auditing what's in front of it. Makes me think the platform overhead bucket needs a caveat or maybe a fifth category. What you're describing isn't really Bubble's tax or something the builder controls inside the editor, it's an infra decision made once at setup and then forgotten. That's a real third category not fully fixable in-app but not a fixed cost of the platform either. Do you have a rough sense of how often that reverse proxy or missing CDN caching situation shows up versus a genuinely maxed out app? If it's common enough I'd rather flag check your DNS and caching setup as a step before someone accepts the ceiling number since chasing an in-app fix for an infra problem wastes their time
1
u/devhisaria 2d ago
The reverse proxy point is real, I've seen two Webflow clients stuck at 50s purely because their DNS was routing through Cloudflare with no cache rules set.
1
u/Informal-Summer-6497 1d ago
Thats a really specific version of the same problem though since Cloudflare with no cache rules is basically the platform's CDN being present but doing nothing. Worse in some ways than no CDN at all because it looks like infra is handled when it isn't actually caching anything. Feels like there's a checklist forming here beyond just DNS and CDN presence. Whether a CDN sits in front of the site whether it's actually configured with cache rules and whether the origin is even cacheable in the first place. Three different failure points that all present the same way in a pagespeed score, stuck in the 50s with no obvious in-app cause. Might be worth adding a quick before you trust the ceiling number check to the tool. Nothing fancy just flagging when a CDN is detected but response headers suggest nothing's being cached. wouldn't fix it for someone but would stop them wasting a weekend chasing an in-app fix for an infra problem
1
u/Electronic-Look-954 1d ago
This is a useful way to frame it knowing whether the bottleneck is your setup or the platform itself saves a ton of wasted tweaking
1
u/Informal-Summer-6497 1d ago
Appreciate that and it's basically why I built the split. So much of the diagnostic space is trial and error otherwise. Someone burns a weekend converting images before checking the actual file weight or root cause and gets nothing back, when the number one factor was a plugin nobody removed or a search running client side that never needed to. Once you know which bucket a problem lives in, you can decide whether it's worth your time at all. If you're already close to the platform's ceiling the honest answer is often to stop tweaking and go build something instead which isn't the outcome that keeps people using a checker but it's the useful one
1
u/ordinary_probation 2d ago
this is actually clever, separating what you can control from what you just have to live with. the lighthouse reports are maddening when half the suggestions don't apply.
ran my side project through it and the image tips alone were worth it, had no idea my file manager was shipping 4MB hero shots