Two different questions, kept apart on purpose. What you
write is a language: JavaScript / TypeScript, Python, Java, Go, PHP, C# / .NET, Ruby, Dart (Flutter), Swift, Kotlin (Android), Rust and Elixir. Where it
runs is a place — phone apps, browser pages, back-end servers, Bun and edge functions — and the same JavaScript
can run in every one of them. That is why fifteen toolkits
cover twelve languages, and why there are
sixteen separate things you can install.
📱 Phone apps
The iOS and Android apps people install — React Native, Flutter, Swift (Apple) and Android (Kotlin). Here Boosthis reads how long the first screen takes to appear, how long until it answers a tap, how long that tap then waits, and how steady the screen stays afterwards.
🌐 Browser pages
Anything a person opens in a browser tab — Web (browser). Here Boosthis reads INP — how long a page takes to respond after someone clicks — and the rest of the Core Web Vitals, page by page.
🖥 Back-end servers
The services your app calls — Node.js / Express, Python, Java, Go, PHP, C# / .NET, Ruby, Rust and Elixir. Here Boosthis reads how long each route takes to answer, and what the runtime was busy doing while it took that long.
🥟 Bun
The same back-end kit, on Bun's own engine instead of Node's. Here Boosthis reads the same per-route timings as a Node.js server, minus the few readings Bun's engine does not expose.
⚡ Edge functions
Code that runs at the edge, close to whoever asked for it. It runs on Cloudflare Workers, Deno Deploy, Deno, Supabase Edge Functions, Vercel Edge Functions and Netlify Edge Functions. Here Boosthis reads how long each request spends inside the isolate — which is as much as something that stops existing between requests can know.
Three things are genuinely identical everywhere: the scoring model and
its shared budgets, the strict PII guard on everything a kit sends, and
the AI tool surface your assistant reads. How much a runtime can measure
is not identical — a browser has no garbage collector to
inspect, Rust has no runtime to ask, an edge isolate is gone between
requests — so the fullest kits take 75 readings and the
newest take 9. The plans page lists
what each runtime can measure, row
by row and generated from the kits themselves; find yours there before you
choose a plan.
RN
React Native performance toolkit
Drop useBoosthis("ScreenName") into any screen for
instant, on-device performance ratings — every screen measured, and
regressions caught early. A built-in dashboard tab shows the full
meter page inside your own app, and your AI assistant can read the
same numbers.
W
Web (browser) performance toolkit
Call startWebVitals() once at page load for real
browser Web Vitals per page — INP for how quickly the page answers a
click, plus the rest of the Core Web Vitals — rated against the same
shared budgets. Catches the browser-specific problems that hurt real
visitors, with a concrete fix for each.
JS
Node.js / Express performance toolkit
Add the boosthis() Express middleware — or
attach() on any other Node server — and optionally
mount(app) for the live /_boosthis/ page.
Catches the runtime-specific problems that actually slow Node services
down, with a concrete fix for each.
🥟
Bun performance toolkit
Bun runs the back-end kit's own files on Bun's engine instead of
Node's — the same boosthis() middleware, the same
/_boosthis/ page, and its own recipe on your Setup page.
It registers under its own name so your dashboard can say plainly
which readings Bun's engine does not expose, rather than showing them
as blanks on a Node project.
Py
Python performance toolkit
Add @track_perf("route") to any function. One extra
line — boosthis.mount(app) — mounts a live dashboard at
/_boosthis/ on your existing Flask or FastAPI port. Run
boosthis serve without a web app for the same dashboard
at localhost:7787. Catches the problems that actually
slow Python services down, with a concrete fix for each.
J
Java performance toolkit
Wrap any com.sun.net.httpserver handler with
BoosthisHandler, or any framework route with the generic
Wrap helper, for per-route ratings against the same
shared budgets. Catches the problems that actually slow JVM services
down — with a concrete fix for each, zero dependencies, JDK stdlib
only.
Go
Go performance toolkit
Wrap any http.Handler with
boosthis.Middleware for per-route ratings against the
same shared budgets. Catches the problems that actually slow Go
services down — with a concrete fix for each, zero dependencies, pure
stdlib.
PHP
PHP performance toolkit
One line — \Boosthis\Boosthis::start() in your front
controller, or the ready-made Laravel / PSR-15 middleware — rates
every route against the same shared budgets. Catches what actually
slows PHP-FPM sites down, from OPcache and memory limits to realpath
cache pressure, with a concrete fix for each and no extensions
required.
C#
C# / .NET performance toolkit
One line — app.UseBoosthis() in your ASP.NET Core
pipeline, or Boosthis.Start() anywhere else — rates every
route against the same shared budgets. Catches what actually slows
.NET services down, from GC pauses and heap headroom to thread-pool
starvation, with a concrete fix for each and not one NuGet package to
install.
💎
Ruby performance toolkit
One line — Boosthis.start, or the ready-made Rails
Railtie / Rack middleware — rates every route against the same shared
budgets. Catches what actually slows Rails and Rack apps down, from GC
pressure and memory headroom to slow outbound calls, with a concrete
fix for each.
🦋
Flutter performance toolkit
Two lines — BoosthisFlutter.start and
BoosthisFlutter.run in main() — rate every
screen against the same shared budgets, straight from the engine's own
frame timings. Catches what actually slows Flutter apps down, from
raster-vs-build jank and frozen frames to image-cache weight and
memory growth.
🍎
Swift (Apple) performance toolkit
One line — BoosthisApple.start at launch — rates every
screen of a native iOS, iPadOS, macOS, tvOS or visionOS app against
the same shared budgets, straight from the app's own run loop and
MetricKit. Catches what actually slows native Apple apps down, from
unresponsive hangs and scroll hitches to memory headroom before
jetsam.
🤖
Android (Kotlin) performance toolkit
One line at launch rates every screen of a native Android app
against the same shared budgets, straight from the app's own frame
timing and the ART runtime. Catches what actually slows Android apps
down, from frozen frames and app hangs to GC pauses, thermal
throttling and cold-start cost.
Rs
Rust performance toolkit
One layer — boosthis::middleware for axum or
actix-web — rates every route against the same shared budgets. Catches
what actually slows tokio services down, from blocking calls on an
async worker to task backlog and connection churn, with a core that
pulls in nothing but std.
Ex
Elixir performance toolkit
One plug — Boosthis.Plug in your Phoenix endpoint —
rates every route against the same shared budgets, and reads what only
the BEAM can tell you: scheduler utilisation, run-queue backlog,
reductions, per-process message queues and ETS growth. Zero
dependencies — it runs on OTP alone.
⚡
Edge functions performance toolkit
Wrap a Cloudflare Worker or a standard request handler to measure
reliability, access pressure, cookie safety and cold starts where the
host allows it. It needs neither Node.js nor a filesystem. It adds no
page and no bubble to the function on purpose — its numbers appear on
your Boosthis dashboard instead.