Related pages

• Chrome Devtools ← See this page for ways to profile your web app, to see how it might be made faster.

Misc learnings

• When linking to your website, you should include the "https://" and the "www.".
  • This is based on what I saw in the waterfall view from webpagetest.org. It appears that if you just have "website.com", the browser will need to do one redirect to go from "website.com" to "www.website.com", and another to go from "www.website.com" to "https://www.website.com". In my case the page loaded maybe 2-3 times slower than it otherwise would have.

Test websites

• Google - PageSpeed Insights
• WebPageTest.org
  • YouTube - How To Use WebPageTest.org - For Beginners

Monitoring websites

• https://www.pingdom.com/
  • used by Pieter Levels

Tutorials / Guides / References

• Google - PageSpeed Insights
  • Guides
  • Reference

Tools

• Middleman
  • Static site generator

Misc

• http://www.growingwiththeweb.com/2014/02/async-vs-defer-attributes.html
• 2015.05.08 - Levels.io - How I sped up Nomad List by 31% with SPDY, CloudFront and PageSpeed
• 2017.07.26 - Algolia - Improving Web Performance to Mirror Engine Speed
• 2017.10.17 - elliotec - How to Get 100/100 Google Page Speed Score with Middleman and Nginx

Stress/Load-testing a web app / API

• Tools
  • ab / ApacheBench (by Apache) ← CLI
    
    • 2013.11.25 - Digital Ocean - How To Use ApacheBench To Do Load Testing on an Ubuntu 13.10 VPS
      
      • Obviously, these results do not reflect realistic server performance. HTTP is just one piece of the puzzle. A slow templating engine and/or database will drag these numbers down significantly. Still, it gives you a quick ballpark figure for comparison.
  • The Grinder
  • httpperf ← CLI / Linux(?)
  • httpress
  • http_load
  • JMeter (by Apache)
  • LoadRunner (by HP)
  • OpenSTA ← Looks really old...
  • siege
  • SoapUI ← One of the more-attractive landing pages (shallow, I know)
  • tourbus
  • WebLOAD
  • weighttp
• StackOverflow questions on this topic

CDNs

Cache-hit ratios

• https://www.fastly.com/blog/truth-about-cache-hit-ratios
  • A "hit" is when the CDN serves a resource, and a "miss" is a resource that your server needs to serve.
  • Summary: Most CDNs consider it a "hit" even if they don't serve the resource from an edge-node-server closest to the user, but instead from a parent node somewhere further away.  This makes their CHRs less useful for understanding the performance benefit that the CDN is providing.  Their CHRs are still useful for getting a sense of the server load that the CDN is saving you, though.