Web performance myths busted
Paris.rb - September 02, 2025
The plan for today
- Scale fatigue
- Orders of magnitude
- The performance that really matters
- The performance rabbit hole
Open source contributor
A little bit of context
A little bit of context
Scale fatigue
- "Does it scale?™"
- "Maybe we should switch to NoSQL"
- "What if we rewrite everything in Go?"
- "We're fundraising, so we must prepare for massive scale!!"
- "Auto-scaling is essential for our traffic"
- "The world's fastest and most scalable cloud databases"
- "Build in a weekend, Scale to millions"
Orders of magnitude
One million of seconds is 11 days,
One billion of seconds is 31 years
Orders of magnitude
- How many (active) users? 100, 1k, 100k?
- What kind of visitors do you have?
- How many RPS?
- I/O bound or CPU bound?
- You are not Shopify nor TikTok
- What is your market size?
- What is your current growth rate?
Orders of magnitude
Scalability is linear and predictable
Orders of magnitude
Your growth is directly correlated to your actions
What is the performance that really matters?
- What is your business strategy?
VC or bootstrapped? - What is your EBITDA?
-
What do your users actually need?
- 🏎️ vs 🚎?
- More features or faster page loads?
- Reliability? Resilience?
- Get your workflows to scale before your stack
This isn't a technical problem
- "If it really takes millions of visitors to make a go of it, you may simply be in the wrong business"
- "Make sure you get the right visitors rather than just any visitors" - Jacques Mattheij
- Servers scale, support and delivery don't
-
Successful apps are much slower than yours, nobody cares
👉 Why You (really) Don't Need SPA
Spoiler alert!!
Your company is going to fail
This isn't a technical problem
- Solve your users' real issues
- Focus on their feedback
- Focus on your business
The performance rabbit hole
- Use cache, aggressively
- Rails is easy to scale, your database is not
- Fix your n+1 and indexes
- Use primary/replica
- Check your I/O bounds
- Rely on background tasks
-
Scale vertically, we're not in 2012 anymore
👉 Rails 8: Multi-db with Solid Queue, Solid Cache and Kamal
Conclusion
- Don't fight the wrong battles
- Choose boring technologies
- Scalability just won't be a problem for you
- Honestly, it'd be a good problem to have