GP is talking about server response time for the base HTML request, saying they see 800ms+. Here are the resource timings I'm seeing for the base HTML (pulled from the HAR of our commercial web monitoring product. Running from Virginia on a 20/5 Mbps connection, latest chrome, desktop user agent and 1080p viewport):
"dns": 158.37,
"connect": 328.503,
"send": 0.148,
"wait": 856.465,
"receive": 91.914,
"ssl": 175.243
"Wait" is the time between when the last byte of request is sent, and the first byte of the response comes back. This is measured all after the DNS+TCP+TLS stuff has happened, and is basically measuring the latency to the server, the backend processing time, and the latency coming back.
800ms+ is... not good because this site is supposed to be behind a CDN (lower latency) and with a supposedly optimized backend. I also am still seeing the "cf-cache-status: DYNAMIC" response header, so whatever optimization was made didn't stick.
(Also, That connect time is oddly high. 300+ms of which 175ms is the TLS handshake. Something to look at as well.)
FWIW I'm in the web performance industry as well, and Todd is correct, a 4-6 seconds for window.onload is common for sites (not just web apps, but sites). Of course modern site development practices (lazy loading images, deferring/asyncing scripts, font fallbacks, etc) have made using the "onload" time essentially useless as a good metric.
(PS: Todd I'm a big fan of your videos on building Request Metrics)