Table of contents
| Table of Contents |
|---|
Child pages
| Child pages (Children Display) |
|---|
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 / monitoring websites
PageSpeed Insights
WebPagetest
Tutorials / Guides / References
- Google - PageSpeed Insights
- Guides ReferenceYouTube - How To Use WebPageTest.org - For Beginners
- 2014.07.21 - YouTube - Patrick Meenan - Velocity 2014 - WebPagetest Power Users - Part 1
Pingdom
- https://www.pingdom.com/
- used by Pieter Levels
Tools
- Middleman
- Static site generator
PageSpeed
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.
- 2013.11.25 - Digital Ocean - How To Use ApacheBench To Do Load Testing on an Ubuntu 13.10 VPS
- 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
- ab / ApacheBench (by Apache) ← CLI
- StackOverflow questions on this topic
CDNs
Vocabulary
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 (cache-hit ratios) 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.
Cloudflare
- Things to know
- If you're using Putty to SSH to your server and you're connecting to the domain name (e.g. "oorkle.com"), once you start using Cloudflare that may no longer work, and you may get "Network error: Connection refused". The way to fix it is to get the IP address for the server from the web panel (e.g. the Digital Ocean web panel) and have Putty connect directly to that.
- How to cache an html page:
- Note that Cloudflare's default behavior is to not cache html, only assets like JS/CSS/images.
- 2018.08.19 - Cloudflare - How do I cache static HTML?
- Why does the time-to-first-byte look so bad after switching to Cloudflare?
- 2018.01.28 - Cloudflare - Why does my time to first byte appear to be slower with Cloudflare?
- 2011.07.13 - WebPagetest - Forums - Cloudflare and first byte
- From the creator of WebPagetest:
By definition cloudflare will add some first byte time since it needs to go back to your server and process the data but it should be minimal. My algorithm for calculating a first byte time grade doesn't play nicely with something like cloudflare though so look at the before/after first byte times and compare those directly (doesn't explain the one long time you had in a repeat view though).
The algorithm for first byte time looks at the socket connect time to get an estimate of the round trip time to a server and then it uses a multiple of that as the baseline and adds 100ms for each letter.
Since cloudflare has distributed edge nodes, they actually make your socket connect time a LOT faster than if the browser had to go back to the original server directly so the baseline is lowered. The actual request still needs to travel back to your server though so it can't be any faster than it was before (and will usually be slightly slower). The effect that has is that it will lower the grade even if it is actually faster because the round trip time used for the baseline is faster.
- From the creator of WebPagetest:
- https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/
- At CloudFlare we make extensive use of nginx and while investigating TTFB came across a significant difference in TTFB from nginx when compression is or is not used. Gzip compression of web pages greatly reduces the time it takes a web page to download, but the compression itself has a cost. That cost causes TTFB to be greater even though the complete download is quicker.
- Probably the only time TTFB is useful is as a trend. And it's best measured at the server itself so that network latency is eliminated. By examining a trend it's possible to spot whether there's a problem on the web server (such as it becoming overloaded).