How fast should a site load on 3G?

I hear a lot that a site should load under 3 seconds, I agree with that in general. My client is working with an Adwords person who says a site should load under 3 seconds, even using a 3G network. I know the faster the better, though I wonder if it's realistic for a site to load that fast on a 3G network? If so, I'll make it happen, though there would be a lot of work involved and wanted to get some general feedback first. Thank you for any input.

 

What is the size of your webpage? How many resources does your page load? What is your server delay? (measuring in time to first byte) But without knowing any of this, 4 seconds is about right.

 

For a normal content oriented page, to me 3 seconds might as well be a year and a half... and it depends on what you mean by "3G" which encompasses at least three different communication standards ranging from 256kbps to 384mbps. (little b -- bit -- in both cases). See, the "G" in 3G stands for "third generation" and covers multiple different standards -- CDMA2000, UTMS, GSM Edge (an enhancement to the second gen GSM) -- none of which offer the same speeds. "3G is decidedly vague and could mean almost anything.

Worst case scenario of that "slow" 256kbps with handshaking overhead, parity, error handling, and so forth works out to around 64k in 10 files as your realistic page size upper limit to hit that 3 second mark. This is not unreasonable for ACTUAL content (text), and completely out the window impossible if you have tons of presentational images, tons of content images, or went full Pakled with the halfwitted incompetent idiocy known as "frameworks".

But that's the bottom end absolute crap connection that's still considered 3g, which is barely four times the speed of dialup. A more typical 3g connection can manage anywhere from 16mbps to 22mbps, which is comparable to many home high speed plans.

Site loading speed -- regardless of if it's wired, wireless, or mobile -- is a factor of code size, content size, template size, and the sheer number of separate files. Mobile connections in particular are highly sensitive to excessive file counts since that creates excess handshaking. Every time you request a separate file there's the overhead of that back and forth between client and server -- and whilst yes browsers and servers try to mitigate that by allowing for multiple connections to run in parallel, the sad fact is many towers get choked on connection limits, many servers hit their limits during high load periods, and often the end user is in congested areas or on a wifi that is equally throttled on connections. Same goes for many switches and routers even on home / business connections.

... and it is to that end that I always say that thinking about any one speed connection is just ignorant, stupid, and means most of the time people flapping their yap about "2G, 3G, and 4G speeds' are just flapping their arse-cheeks in the wind. It's about good practices, and that's why when I'm building a site template I generally have this loose-fast rule:

1) no more than 5 separate files for the template itself. That's 1 HTML, 2 CSS, 2JS. No more. Generally I try to deploy only one CSS file.

2) no more than 48k of CSS and 64k of JavaScript for the site's in-built template, not counting social media plugins or advertising scripts. There is ZERO excuse for more than that apart from developer ignorance, incompetence, and ineptitude. (which is why when I see websites with 512k of CSS and megabytes of JavaScript, I wonder just what the F*** these halfwits are even doing! Oh wait, "frameworks" -- because using hundreds of K of scripting and CSS to then have to write hundreds of K of your own code to do the job of dozens of k of code without the "framework" is "easier", of course it is. MORONS!)

3) separation of presentation from content. The more you can move out of the HTML and into a monolithic CSS file, and the more you can pre-cache in that SINGLE CSS file, the faster the load of subpages will be and the less bandwidth you will use overall. Getting presentation the blazes out of the markup where it has ZERO blasted business being gives you smaller markup, for faster loads of subsections (often faster than the bullshit people pull with AJAX/CSR) and less work for the back-end coder since it gives them less markup to have to slice-up into their server-side code!

Hence why I even have a size target calculation for HTML:

2048 bytes (header) +
Plaintext Size * 1.5 +
Number of Anchors * 128 +
Number of Form Elements * 128 +
Number of Media Elements (content images, videos) * 256

If you add all that up, and the HTML for that page exceeds that value by a significant amount, the site is likely horrifically ineptly coded.

So for example, let's take one of bootcrap's examples:

https://getbootstrap.com/docs/4.0/examples/pricing/

No content media, no form elements, 22 anchors, 756 bytes of plaintext... so it should only need 5998 bytes of markup. How much does their idiotic dumbass ignorant mentally enfeebled incompetent dipshit way of doing things use? 6,283 bytes. Not too bad on paper; shame there's no reason for that page to use more than 3k of HTML had it been written properly -- likely with 6k of CSS and not a single line of JavaScript needed.

Which is why they're wasting 320k in 9 files on that page to do the job of 7k in two files. Even if we only look at the markup and custom CSS they use for that page, the developer would have had to write 7k in two files... was it really worth saving that 1k of effort at the cost of 312k of code bloat, seven extra handshakes, and a non-semantic markup that tells users with accessibility needs to go plow themselves?

Now I realize, that's a tiny example of a ridiculously content-light page... but imagine how this scales upwards. By the time you get to around four differently formatted sections, actual columnar layout, four or five content images and two dozen k of actual content text, the average slob tracking their bootcrap all over a website's carpets will vomit up 100 to 200k of HTML to do the job of 48k or less... the custom CSS they'd end up putting atop the bootcrap would equally grow in complexity, size and often file count.

The end result being fat bloated slow ineptly developed websites.

I'm not saying that's what's wrong with your site -- I'd have to see the site in question to advise you properly -- but if it is built with those types of techniques, "Well there's your problem".

Bootcrap? W3.css? jQuery? React? Angular? Vue? Turdpress? You're screwed. Throw it out and start over.

 

Here are my views to get good page speeds(Yes, you need to target 2-3sec):-
- minify everything (html, css, js)
- optimize images(reduce size without loosing jazz, using ImageMagick convert tool)
- use async JS if you can. Basically load page contents first, without blocking, and then do JS thingy
- piggyback into single CSS if you can. If small CSS, inline it
- using CDN to deliver images, if you have considerable(well, do the math of size and response times and page loads) image size
- use better webserver for async + pre gzipped static content delivery(if not using CDN), like nginx. Consider lighttpd.
- take a look at AMP ampproject.org and see if you can implement it. It kills use of JS altogether. Google search caches amp pages for faster delivery. Search result -> actual page takes less than 1sec.