4 ms·

That's a bit presumptuous. Not everyone is on fast internet. Even supposedly "fast" internet benefits, as I've been very surprised about connection latency issu

That's a bit presumptuous. Not everyone is on fast internet. Even supposedly "fast" internet benefits, as I've been very surprised about connection latency issues in the US. Also it's more secure to have a static site. Also it's simpler to manage in the long term. win win win

LeanderK 10y ago
it wasn't meant to be presumptuous. I have an older smartphone that's limited to 3g (and way to often Edge). What i wanted to say: instead of manually selecting and limiting yourself we should invest in simple, transparent tools that help you get reasonable fast. I would choose a static site, preferably github pages because of its simplicity and easy update-process. We use elaborate compilers every day to optimize our code, so why is there no "global" optimiser for static pages that exclude a few common libraries that one assumes are already cached (if you really need js)? Maybe it's because i don't know that much about "real" web development besides some dashboard-frontend for a way more complicated backend. But this was more composing bootstraps than developing. I usually am more interested in the backend. But to me these seem to be client-problems. Some quick inlined js for selecting the correct image and whether to load the font should not waste much time. Or is this possible via CSS? In my mind this should not be an impossible task. I have always wondered why some website display nothing until loading of font finished.
oogali 10y ago
Depends on your goals. If you're a company like Facebook or Google, you're looking to eke growth out of every corner of the Earth, including those with really slow Internet. So after you've conquered the 1st and 2nd world countries, you start optimizing for additional tiers. (And optionally launch balloons that shower Internet upon untapped markets) However, if you're not one of those two behemoths, then your target audience is probably located within ~3,500 miles of you/your servers (which would translate roughly into a RTT latency figure of ~100 milliseconds, and add 40ms for those folks on low-grade ADSL or cellular connections). Your barebones site is competing with other fully-featured sites that are taking advantage of the high bandwidth delay product that's available to them. Unless, competing for eyeballs is not one of your goals. But regardless, optimizing for reach beyond that mileage range by slicing bits here and there, rather than bolting on a CDN, is probably a premature optimization. To throw out a new presumption, I'd say that if you measured user's rage, they're more angry with packet loss than with consistent latency. One is predictable and can be planned for ("open 5 tabs, go do some chores, come back in 15 minutes when they're loaded"). The other is absolutely infuriating ("open 1 tab, get teased by some amount of partially loaded objects, spend the next 5 minutes refreshing due to socket timeouts, cross fingers that not too many refreshes evicts items out of the local cache, give up")

LeanderK 10y ago

it wasn't meant to be presumptuous. I have an older smartphone that's limited to 3g (and way to often Edge). What i wanted to say: instead of manually selecting and limiting yourself we should invest in simple, transparent tools that help you get reasonable fast. I would choose a static site, preferably github pages because of its simplicity and easy update-process. We use elaborate compilers every day to optimize our code, so why is there no "global" optimiser for static pages that exclude a few common libraries that one assumes are already cached (if you really need js)? Maybe it's because i don't know that much about "real" web development besides some dashboard-frontend for a way more complicated backend. But this was more composing bootstraps than developing. I usually am more interested in the backend. But to me these seem to be client-problems. Some quick inlined js for selecting the correct image and whether to load the font should not waste much time. Or is this possible via CSS? In my mind this should not be an impossible task. I have always wondered why some website display nothing until loading of font finished.

oogali 10y ago

Depends on your goals. If you're a company like Facebook or Google, you're looking to eke growth out of every corner of the Earth, including those with really slow Internet. So after you've conquered the 1st and 2nd world countries, you start optimizing for additional tiers. (And optionally launch balloons that shower Internet upon untapped markets) However, if you're not one of those two behemoths, then your target audience is probably located within ~3,500 miles of you/your servers (which would translate roughly into a RTT latency figure of ~100 milliseconds, and add 40ms for those folks on low-grade ADSL or cellular connections). Your barebones site is competing with other fully-featured sites that are taking advantage of the high bandwidth delay product that's available to them. Unless, competing for eyeballs is not one of your goals. But regardless, optimizing for reach beyond that mileage range by slicing bits here and there, rather than bolting on a CDN, is probably a premature optimization. To throw out a new presumption, I'd say that if you measured user's rage, they're more angry with packet loss than with consistent latency. One is predictable and can be planned for ("open 5 tabs, go do some chores, come back in 15 minutes when they're loaded"). The other is absolutely infuriating ("open 1 tab, get teased by some amount of partially loaded objects, spend the next 5 minutes refreshing due to socket timeouts, cross fingers that not too many refreshes evicts items out of the local cache, give up")