4-6 second total page load time. This includes the document, static assets, and JavaScript parsing.
Based on many data points from our monitoring of website performance, this is a very common range.
Based on many data points from our monitoring of website performance, this is a very common range.
Frankly, our entire industry should be ashamed that anyone thinks 4-6 seconds is an acceptable amount of time to render a fucking website.
"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)
4 to 6 seconds for effectively static content is absolutely insane, and only justifiable for exceptionally rarely accessed dynamic data queries.
It shouldn't matter how "common" this response time is, when you can load a huge static HTML/CSS/PNG site in hundreds of milliseconds.
Unless the website is literally loading an entire page of High Res images/video content, 4-6 seconds is atrocious