SpeedCurve Blog
speedcurve.com · Company blog · on HN since 2013
The blog of SpeedCurve, a web performance monitoring company, covering page weight, JavaScript growth, performance metrics, and how speed affects users.
What HN saysHN commenters cite it for data on web page bloat and growing JavaScript, and its founder uses it to discuss web performance monitoring.
19HN people shared it
9linked it in comments
16stories submitted
99story points
2 years agolast shared
2013people per year2026
Most-shared posts
- 1The average web page is 3MB. How much should we care?8 people · 4 points · first shared 2017 · 3 comments on HN
- 2User Timing and Custom Metrics2 people · 15 points · first shared 2015 · 2 comments on HN
- 3Show HN: SpeedCurve - monitor front-end performance and benchmark against others2 people · 1 points · first shared 2013 · discussion on HN
- 4JavaScript growth and third parties1 people · 57 points · first shared 2018 · 76 comments on HN
- 5Ten years of web page bloat: What have we learned?1 people · 3 points · first shared 2022 · discussion on HN
- 6Visual diffs on every deploy1 people · 3 points · first shared 2015 · discussion on HN
- 7You need to know your site's performance plateau (and how to find it)1 people · 3 points · first shared 2025 · discussion on HN
- 8PWA Performance1 people · 2 points · first shared 2016 · discussion on HN
- 9Monitor your front-end: synthetic testing vs real user monitoring1 people · 2 points · first shared 2013 · discussion on HN
- 10JavaScript Dominates Browser CPU1 people · 2 points · first shared 2019 · discussion on HN
- 11In depth comparison of web perf rendering metrics1 people · 2 points · first shared 2017 · discussion on HN
- 12Square's new responsive website - breakdown of build and front-end performance1 people · 2 points · first shared 2013 · discussion on HN
- 13The psychology of site speed and human happiness1 people · 2 points · first shared 2024 · discussion on HN
- 14Web Performance for Product Managers1 people · 1 points · first shared 2021 · discussion on HN
- 15Velocity a better waterfall chart1 people · first shared 2014
What HN people wrote when they linked it
zeman · 2014-03-02
SpeedCurve is proving to be very profitable for a side project. Paid back initial $3k investment in server costs and now growing at 32% month on month. Can't live on it yet, but it will cover a couple of conferences and a two week holiday in New York this year. Also just won $10k in a startup competition, does that count as profit? ;)
http://speedcurve.com/
For bootstrapped SaaS projects it's worth remembering how long it can take to grow the flywheel and see growth. It took Rob from HitTail a year after launch to connect with the right audience and Freckle took 5 years to get to $57k/month. It's a multiyear investment to grow something substantial.
http://unicornfree.com/2013/5-years-of-saas-growth-every-month-exact-n…
SpeedCurve has been in development for a year and available commercially for only 5 months. Haven't even started doing any marketing yet with all current growth via word of mouth.
wldlyinaccurate · 2020-09-09
I've been working in the web performance monitoring space (https://speedcurve.com/) for 3 years now, and the 3 years prior to that I was doing a lot of performance work at the BBC. I can't share the data for obvious reasons but I can confidently say that the web is getting measurably slower every year, despite connection speeds increasing drastically over the last few years.
We like to over-simplify and try to attribute it to things like JS frameworks, advertising, media-heavy pages, etc. The truth is that it is all of these things, and so much more. Yes, devices are more powerful, but we are also asking our devices to do more. Yes, connections are faster, but bandwidth doesn't help with things like TCP slow start or browser concurrency limits. On top of all of this, our perception of speed is changing, so things can _feel_ slower than they really are.
maigret · 2022-10-24
Unfortunately too much JS has made the web slower, check this https://www.speedcurve.com/blog/web-performance-page-bloat/ for a quick view or infrequently.org for longer explanations. React starts to be dated now and there are leaner alternatives offering most of the functional advantages, like Svelte or Lit.
The tooling evolves indeed and I hope it gets again nearer to the browsers, thanks to web components, better CSS (hello variables), WASM and much more.
__alias · 2021-01-28
I think it's more of a resource prioritisation thing.
I THINK If the resource is async, it will still scan the document to find all resources before the downloads begin. Adding preload basically just tells the browser that the resource is important and should begin the download immediately.
Found this, kind of explains it
https://speedcurve.com/blog/preload-scripts/
wayneftw · 2020-06-24
> ...a frequently-larger web app
Got any stats for that? I was quickly able to find [0] and [1] which state that web page sizes are 1.5mb (median), 2mb (mean) and the average is about 3mb.
[0] https://royal.pingdom.com/webpages-are-getting-larger-every-year-and-h…
[1] https://speedcurve.com/blog/web-performance-page-bloat/
executesorder66 · 2018-09-21
In 2010 the average size was 626KB [0]. Now it's like 3MB. [1]
[0] http://www.webperformancetoday.com/2013/06/05/web-page-growth-2010-201…
[1] https://speedcurve.com/blog/web-performance-page-bloat/
prepend · 2018-05-23
“This insanely unnecessary bandwidth usage penalizes sites that have long (>10) feeds with complete posts.”
Since rss is text only the sizes are very small and compress well. Considering the average web page is 3M[0], pulling down 10-100k of every post ever doesn’t matter. And http takes care of not pulling the same file over and over.
It’s certainly a downside, but completely useable as is, and better than any viable alternative.
As far as standards go, I prefer simple, static file, over something requiring dynamic response.
There’s also nothing stopping the site from limiting the RSS feed to only 5 posts with a link for full.
[0] https://speedcurve.com/blog/web-performance-page-bloat/
ryantownsend · 2018-08-09
One technique I've seen work well for getting bosses to care is showing them how much slower their sites are than their competitors - nobody wants to be worse than their competition.
In SpeedCurve, for just around $8/mo per page/site you can set up daily synthetic checks for the business and its competitors, covering multiple profiles: mobile/3g, tablet/4g, desktop/fibre.
You can use both the metrics (Start Render, SpeedIndex, Hero Paint) [1] and the filmstrip videos to literally show them how they compare side-by-side [2] – this is super-powerful as it's so visual.
Disclaimer: I don't work for SpeedCurve, just a fan of the tool.
[1]: https://speedcurve.com/features/synthetic/#benchmark
[2]: https://speedcurve.com/demo/video/?tests=180102_1T_d12fa882f96f9d47f41…
Joeri · 2017-08-17
Pages are now over 3 MB in size on average [1]. Just 5 years ago (already post-iphone) they were 800 KB. This mirrors my experience, where the mobile web feels slower despite my phone and connection being much faster. It seems web developers have stopped caring at all about performance.
If you look at where the bloat went, it's mostly three things:
- Images ballooned in size by a megabyte (without adding much extra requests)
Most likely culprits are retina class graphics and "hero graphic" designs.
- Javascript sizes and number of requests doubled
Corresponds to a shift from jquery + some manually added plugins to npm / webpack pipelines and using a massive amount of (indirect) dependencies.
- video
Now that flash has disappeared, it got replaced by auto-playing video, which is even worse as far as page bloat is concerned.
[1] https://speedcurve.com/blog/web-performance-page-bloat/