Sefism is free for learners. We are here to help you grow, one step at a time.Join for free
Sefism.
Web

Real-User Performance Monitoring for Low-End Android Phones and Slow Mobile Networks

Build a small, privacy-friendly script and dashboard that measures how fast a site really is for people on budget Android phones and congested mobile data, then explains which scripts, images and long tasks cause the slowness. Lab tests on a developer's laptop hide what most users in Pakistan and South Asia experience. The project ends with a measured case study on a real site.

Topics
Difficulty

Intermediate

A small team, or one strong student willing to learn something new.
Effort

1 to 2 semesters · 2 students

Deliverables

8 to ship

3 optional extras

Suggested stack

TypeScriptweb-vitals libraryLong Animation Frames APINode.js or Go collectorClickHouse or PostgreSQLReact dashboard
A suggestion, not a requirement. Swap anything for what you already know.

What you should ship

  • A collector script under 5 KB that records Core Web Vitals and attribution data without cookies
  • Device and network classing from Client Hints, memory, CPU cores and connection type
  • Attribution of slow interactions to the scripts and long animation frames that caused them
  • An ingestion service with sampling, bot filtering and no storage of IP addresses
  • A dashboard with percentiles split by device class, network and page template
  • A third-party script cost view showing time spent in each external script
  • A before-and-after case study on one real site with at least two fixes measured
  • A short methods note comparing your field data with Lighthouse lab results

If you have time left

  • Automatic alerts when the 75th percentile of a metric regresses after a deploy
  • A Next.js and WordPress plugin for one-line installation
  • A public dataset of anonymised results from consenting sites

The problem: fast on the developer's laptop, slow in the user's hand

Most web developers test on a recent laptop with fibre broadband. Many of their users browse on entry-level Android phones with little memory, slow CPUs and mobile data that drops to a crawl in the evening. A page that scores well in a lab test can take several seconds to respond to a tap on these phones, because heavy JavaScript, chat widgets and ad scripts block the main thread.

Shops, news sites, banks and government portals lose people at exactly this point, but their analytics only show a bounce, not the cause. The owner sees a good score in a lab report, the user sees a frozen screen, and neither knows the other's view exists.

What already exists and the gap

  • Lighthouse and PageSpeed Insights run lab tests with simulated throttling. Useful, but simulated.
  • The Chrome UX Report (CrUX) publishes real-user data for popular origins, aggregated and without a breakdown by device class or by the script that caused a delay. Smaller sites often have no data at all.
  • Commercial real-user monitoring products from observability vendors are powerful, but they are priced and designed for large companies, and they often collect more personal data than a small site wants.
  • Open source analytics such as Plausible and Umami count visits, not performance.

The gap is a light, self-hosted monitor built for the low-end case: tiny script, no cookies, results split by device class, and attribution that names the guilty script.

Inspiration

WProf (Wang et al., "Demystifying Page Load Performance with WProf", NSDI 2013) built a dependency graph of every activity during a page load and found that computation, not just network, made up as much as 35% of the critical path. Your project carries that insight to real users: on low-end phones, script execution and long tasks often matter more than download size, and you will measure that in the field rather than the lab.

What you build

  • Site owners add one script tag and see where their real users wait, split by phone class and network.
  • Developers open a slow interaction and see which script and which long animation frame caused it.
  • Product teams see the cost of each third-party script in milliseconds, which makes removal decisions easy.

The technically interesting part

  • Measuring without harming. The monitor itself must not slow the page. Defer everything, batch beacons, and send them with sendBeacon when the page is hidden.
  • Attribution. Use the Long Animation Frames API and web-vitals attribution builds to link a slow Interaction to Next Paint to the script URLs that ran during it.
  • Device classing. Combine device memory, hardware concurrency, Client Hints and connection type into a small number of honest classes. Document the limits, because some signals are only available in Chromium browsers.
  • Noise and bots. Crawlers, prerendered pages and tabs left open for hours all distort the data. Filter known bots, handle back-forward cache restores separately, and drop sessions that never became visible.
  • Statistics. Report percentiles, not averages, and show sample sizes so nobody makes decisions on twenty sessions.

How to evaluate it

  • Overhead: the monitor's own cost on a low-end phone, measured with and without it.
  • Accuracy: compare your field numbers with CrUX for a site that has CrUX data.
  • Usefulness: on the case study site, did the attributed scripts really cause the slowness? Remove or defer them and measure again.
  • Coverage: what share of sessions report each metric, by browser, so readers know which numbers rest on Chromium users only.
  • Privacy: list every field you store and show that none of it identifies a person.

Suggested plan

  • Weeks 1 to 3: read about Core Web Vitals and WProf, test on two real low-end phones.
  • Weeks 4 to 7: collector script, ingestion service and storage.
  • Weeks 8 to 10: dashboard, device classing and attribution views.
  • Weeks 11 to 13: install on a real site (a university, NGO or small shop) and collect data.
  • Weeks 14 to 15: apply fixes, measure again, write the case study.

Path to a product

Agencies building sites for South Asian audiences need proof that their work is fast for real users, not just in a lab. A free self-hosted version with a paid hosted plan is a common model for developer tools. The case study alone is a strong portfolio piece for frontend and performance roles.

Scope warning

Do not build a general analytics product. Stay focused on performance, keep the script tiny, and resist adding session replay or user tracking. One real site with honest before and after numbers is worth more than a polished dashboard with demo data.

Learn what you need on Sefism

Get help with this idea

The risk is a monitor that collects numbers nobody acts on, or a case study without a real site. Tauseef can help you find a partner site, pick the right metrics and plan the before-and-after measurement. If you are new here, create a free account first.

Ideas and guidance, not finished projects

These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.

Not sure this one fits you?

I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.

Discuss this idea
Work with me

Stuck on something specific?

Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.

Book a free sessionSee all services

Follow along

New writing, resources and project ideas land here first.