3 ms·

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 pe

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.

enriquto 6y ago
It's atrociously slow. It makes no sense at all for a blog post.
- falcolas 6y ago
  100% this. 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.
AnIdiotOnTheNet 6y ago
Just because it is common does not mean it is acceptable. Do you have any idea how ludicrously fast computers are nowadays? Multiple cores, each running at several billion cycles per second and several instructions per cycle. If each cycle were 1 processor-subjective second long, your average desktop processor would experience upwards of 248 years per real-time second. Frankly, our entire industry should be ashamed that anyone thinks 4-6 seconds is an acceptable amount of time to render a fucking website.
NikolaeVarius 6y ago
My internet connection can stream up to 1 GBPS. Unless the website is literally loading an entire page of High Res images/video content, 4-6 seconds is atrocious
billyhoffman 6y ago
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)
- toddgardner 6y ago
  :D Thanks Billy!!

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.

enriquto 6y ago

It's atrociously slow. It makes no sense at all for a blog post.

falcolas 6y ago
100% this. 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.

AnIdiotOnTheNet 6y ago

Just because it is common does not mean it is acceptable. Do you have any idea how ludicrously fast computers are nowadays? Multiple cores, each running at several billion cycles per second and several instructions per cycle. If each cycle were 1 processor-subjective second long, your average desktop processor would experience upwards of 248 years per real-time second. Frankly, our entire industry should be ashamed that anyone thinks 4-6 seconds is an acceptable amount of time to render a fucking website.

NikolaeVarius 6y ago

My internet connection can stream up to 1 GBPS. Unless the website is literally loading an entire page of High Res images/video content, 4-6 seconds is atrocious

billyhoffman 6y ago

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)

toddgardner 6y ago
:D Thanks Billy!!