When I set out to build Meettrics, I set out to build a 'fast' system. Developers love to talk about fast. Few can back it up. Now, it is fair that it is harder to develop in teams. Some companies target acceptable standards more than fastest. The trouble is many companies struggle to reach acceptable standards. Unencumbered by others, I set off to ensure that I avoided the traps that created slow apps. The best way to fix a problem is avoid it in the first place.
And so, here is what Meettrics.com currently is:
- Dom Content load: 547ms
- Complete Load: 672ms
- Finish: 791ms
- Total download size: 308kb
- Total non gzipped size: 895kb
- Total requests: 10
And page speed:
- Maximum 95th: 1151ms
- Minimum 95th: 1ms
- Median 50th: 25ms
The max 95th is typically a bit lower. This is hosted on plain default Heroku and they seem to have some dyno restarts at time that cause some slower requests. We get complaints that our site is performing slow when this crosses 1 second.
How's that compare?
I don't have easy access to page response times for competitors but we can at least ballpark it ourselves. I'm trying to keep the tests as accurate as possible but note that for speed these are just ballpark and not numbers to calculate on.
The industry incumbent - Google
Top paid developers operating at large scale. They set the standards so hopefully they meet them. Let's find out.
- Dom Content load: 412ms (better)
- Complete Load: 667ms (equal, 5ms less)
- Finish: 1.97s (slower)
- Total download size: 2.1Mb (larger)
- Total non gzipped size: 6.5Mb (larger)
- Total requests: 67 (more)
Requests of course is less important with HTTP2 but it still shows some measure of server load and traffic. Google has good devs that know what they are doing. It's well optimized and even with a larger bundle size competes well. Perception wise, it's not much different. The large JS app takes awhile to load but they do it in a decent way without user impact.
Google has an advantage I don't. They control their entire stack from top to bottom. I can only largely optimize app code. Since we are Heroku hosted, DNS, SSL, load balancing, server config and setup, better hardware and more are off the books right now for optimization areas. We will pull ahead on all stats when we transition to our own managed servers and infrastructure.
The big market whale - Calendly
Calendly is another scheduling platform so it offers a direct apples to apples comparison. They should have the cash to compete with the professionals. Let's see how they stack up.
- Dom Content load: 1.06s (worse)
- Complete Load: 1.08s (worse)
- Finish: 2.73s (slower)
- Total download size: 3.2Mb (larger)
- Total non gzipped size: 11Mb (larger)
- Total requests: 53 (more)
More assets and overall slower. Optimizers Calendly is not. Google has 33% of their time after DOM Content load before it hits complete load. I didn't look too deep but it hints at better bundle delivery and starting the JS app while other assets were still downloading. The bundle sizes are getting bigger.
A quick look at their job posting clarifies some things.
Calendly is built using a service-oriented architecture and an automated continuous delivery system in order to efficiently deliver our product solutions. The successful individual will write well tested software and grow into a full stack specialist. You will learn to be comfortable working in multiple technologies such as Elasticsearch, Google Cloud Platform, Kubernetes, Ruby on Rails, React, PostgreSQL, Redis, and more.
Probably as most apps started Rails and they got fancy. Add in React, throw in some services for speed and the result is a nice pile of fall short of the mark. I thought these things made us fast? 🤔🤔🤔 They got it all!
And one more for fun.
Calendar.com - An upstart competitor but probably not tech founder
- Dom Content load: 943ms (worse)
- Complete Load: 1.15s (worse)
- Finish: 1.91s (slower)
- Total download size: 5.3Mb (larger)
- Total non gzipped size: 7.2Mb (larger)
- Total requests: 33 (more)
Interesting stats. Also a react app but unsure of the backend from a quick look. Bigger download bundle but they seem to get it down faster than Calendlys smaller bundle. Also total size ends up lower. Top line stats above Calendlys but probably not a perceptible difference to end user experience.
Conclusion
Get off React 🤣🤣🤣. The JS apps fall to the back of the pack and don't hit standards. I'm not saying it's not possible to make a fast React app. But it does make it harder. I'm just picking on React, many technologies can make delivering performance harder, particularly if the drawbacks are not understood.
I haven't really spent time on optimizing Meettrics yet. I've just followed best practices and that keeps my numbers low without too much optimizing time required. It's not holding us back. If anything I am annoyed at the slow reports when our site is still responding faster than our competitors. But I suppose that is the thing about being at the cutting edge. Harder standards are applied to you. Once the app grows a bit more I hope to circle back to infrastructure and get that integrated and shared. Stay tuned!