8 ms·

Agreed that this is a terrible nuisance. Webmasters please: use a CDN, have a download budget, use YSlow, smarten up how you use caching, push your scripts to

Agreed that this is a terrible nuisance. Webmasters please: use a CDN, have a download budget, use YSlow, smarten up how you use caching, push your scripts to end, and so forth. Nobody wants to stare at a blank screen for 30 seconds while you're loading up all of your bells and whistles. If you want to keep reader engagement you've got about 5 seconds from load to text appears, max. Probably a lot less than that. And the same goes for web apps, btw. In fact, web apps are worse because people aren't passively engaged. Your content site takes 20 seconds to load? I bail out. Your web app takes 20 seconds to load? I'm spending the entire time cursing you under my breath. Anybody who delivers anything over the web should be stone cold brutal about doing anything possible to decrease load times.

pbhjpbhj 14y ago
It's not only reader engagement (and of course bounce rate which overlaps somewhat) but page speed is a factor in SEO nowadays too: so it's reader acquisition as well.
joshuacc 14y ago
A lot of this can also be alleviated by being smart about using a web app's login screen to preload resources that will be needed on subsequent screens, as well. It's relatively simple to include a bit of JavaScript on the login page to fetch webfonts for the rest of the app before they are needed. Furthermore, if you use JS to load your webfonts, you can have the site display in "web safe" fonts until your custom fonts are loaded. Example: https://developers.google.com/webfonts/docs/webfont_loader#Styles https://developers.google.com/webfonts/docs/webfont_loader#S...
- TazeTSchnitzel 14y ago
  That's a really handy little trick, thanks!
- Groxx 14y ago
  IMO the websafe -> webfont transition generally looks crappy. You get a brief window where you see the plain font, you start reading, then all the text changes size ever-so-slightly, which moves the entire page around. Jarring. At least as bad as having a bunch of images that aren't fixed size that reorganize the page as they load.
  - dredmorbius 14y ago
    All the more reason to use userContent.css to override site fonts. Size and face are legible.
    - Groxx 14y ago
      Absolutely agree :) Add in a social-plugin blocker (if you're not a disable-js person), and the internet moves like 3 times faster. Just preventing e.g. someone's twitter feed from loading often makes the page respond a couple seconds sooner, which is really unforgivably bad.
- mncolinlee 14y ago
  > Furthermore, if you use JS to load your webfonts, you can have the site display in "web safe" fonts until your custom fonts are loaded. Google "FOUT." Some web designers consider this to be worse than the original problem because it is unsettling to the viewer to see the fonts shift and morph every time you reload the page or hit Back. There are downsides to both methods and that is why each browser treats the problem differently.
doublec 14y ago
Webapps can look at using some of the newer HTML features for offline capability and caching. There's the HTML App Cache [1] and IndexedDB [2] for example. [1] https://developer.mozilla.org/en-US/docs/HTML/Using_the_application_cache https://developer.mozilla.org/en-US/docs/HTML/Using_the_appl... [2] https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/ https://hacks.mozilla.org/2012/02/storing-images-and-files-i...
- MatthewPhillips 14y ago
  That only happens the second time you load a page.
gbog 14y ago
Other answers are trying to trick the machine, while the obvious and safe fix is to serve plain html. Just like HN by the way, which is the only bearable site from China on a 3g connection.
- ZeroGravitas 14y ago
  Though the last time I checked it didn't use gzip, which would improve things radically in that case I'd imagine.
  - dbaupp 14y ago
    It still doesn't (but should): https://developers.google.com/speed/pagespeed/insights#url=https_3A_2F_2Fnews.ycombinator.com_2Fitem_3Fid_3D5181073&mobile=false https://developers.google.com/speed/pagespeed/insights#url=h...
- joshuacc 14y ago
  For this particular problem, it doesn't matter whether the site is serving "plain HTML" if the CSS specifies a webfont that the user doesn't already have. So you have two alternatives for a good experience: 1. Use only fonts users have preinstalled. 2. Make sure that you handle downloading webfonts in an intelligent way. For many sites, 1 is fine. But for others which try to set themselves apart with distinctive design, 2 is necessary.
  - papsosouid 14y ago
    No, 2 is never necessary. You can set yourself apart with design just fine. The text, actual information people are trying to retrieve, is not part of the design. Specifying a font for the ordinary text is a perfect example of designers prioritizing self-obsessed wankery over the user.
    - kamjam 14y ago
      So all of a sudden we have become a design Nazi and telling people what their website can or can't include for design. The alternative to not allowing custom fonts is that people go back to using text in images to display their custom fonts which sucks when you are dealing with multiple languages or just want to change the text for something else. Or something like Cufon [http://cufon.shoqolate.com http://cufon.shoqolate.com]. Or use flash. I think I prefer webfonts, the developers just need to be smarter about how they are used and the implementation for including them.
snowwrestler 14y ago
No one needs a CDN to serve text quickly; that is massive overkill. CDNs in general are massive overkill for most sites. What a CDN does is reduce latency due to lightspeed. Is lightspeed really why it takes a site 10 seconds to show text? No. As you point out, caching and proper javascript management is the key to a site that shows text quickly. CDNs do provide caching, but are a complicated and expensive way to do so.
- Groxx 14y ago
  CDNs do a whole lot more than that. They allow common resources to be shared between sites. If 10 sites self-host jQuery, you download it 10 times. If they all pointed to the same CDN, you'd download it once, reducing your latency to below lightspeed - the time it takes to check caches on your device.
  - snowwrestler 14y ago
    This is not a feature unique to a CDN; the same result could be achieved by simply hosting jQuery on a single server and pointing all your websites to that copy. My point is that when people talk about using "a CDN", usually what they are really talking about is caching. Whether that caching happens at the origin or the edge makes a very very tiny difference (the lightspeed difference).

pbhjpbhj 14y ago

It's not only reader engagement (and of course bounce rate which overlaps somewhat) but page speed is a factor in SEO nowadays too: so it's reader acquisition as well.

joshuacc 14y ago

A lot of this can also be alleviated by being smart about using a web app's login screen to preload resources that will be needed on subsequent screens, as well. It's relatively simple to include a bit of JavaScript on the login page to fetch webfonts for the rest of the app before they are needed. Furthermore, if you use JS to load your webfonts, you can have the site display in "web safe" fonts until your custom fonts are loaded. Example: https://developers.google.com/webfonts/docs/webfont_loader#Styles https://developers.google.com/webfonts/docs/webfont_loader#S...

TazeTSchnitzel 14y ago
That's a really handy little trick, thanks!
Groxx 14y ago
IMO the websafe -> webfont transition generally looks crappy. You get a brief window where you see the plain font, you start reading, then all the text changes size ever-so-slightly, which moves the entire page around. Jarring. At least as bad as having a bunch of images that aren't fixed size that reorganize the page as they load.
- dredmorbius 14y ago
  All the more reason to use userContent.css to override site fonts. Size and face are legible.
  - Groxx 14y ago
    Absolutely agree :) Add in a social-plugin blocker (if you're not a disable-js person), and the internet moves like 3 times faster. Just preventing e.g. someone's twitter feed from loading often makes the page respond a couple seconds sooner, which is really unforgivably bad.
mncolinlee 14y ago
> Furthermore, if you use JS to load your webfonts, you can have the site display in "web safe" fonts until your custom fonts are loaded. Google "FOUT." Some web designers consider this to be worse than the original problem because it is unsettling to the viewer to see the fonts shift and morph every time you reload the page or hit Back. There are downsides to both methods and that is why each browser treats the problem differently.

doublec 14y ago

Webapps can look at using some of the newer HTML features for offline capability and caching. There's the HTML App Cache [1] and IndexedDB [2] for example. [1] https://developer.mozilla.org/en-US/docs/HTML/Using_the_application_cache https://developer.mozilla.org/en-US/docs/HTML/Using_the_appl... [2] https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/ https://hacks.mozilla.org/2012/02/storing-images-and-files-i...

MatthewPhillips 14y ago
That only happens the second time you load a page.

gbog 14y ago

Other answers are trying to trick the machine, while the obvious and safe fix is to serve plain html. Just like HN by the way, which is the only bearable site from China on a 3g connection.

ZeroGravitas 14y ago
Though the last time I checked it didn't use gzip, which would improve things radically in that case I'd imagine.
- dbaupp 14y ago
  It still doesn't (but should): https://developers.google.com/speed/pagespeed/insights#url=https_3A_2F_2Fnews.ycombinator.com_2Fitem_3Fid_3D5181073&mobile=false https://developers.google.com/speed/pagespeed/insights#url=h...
joshuacc 14y ago
For this particular problem, it doesn't matter whether the site is serving "plain HTML" if the CSS specifies a webfont that the user doesn't already have. So you have two alternatives for a good experience: 1. Use only fonts users have preinstalled. 2. Make sure that you handle downloading webfonts in an intelligent way. For many sites, 1 is fine. But for others which try to set themselves apart with distinctive design, 2 is necessary.
- papsosouid 14y ago
  No, 2 is never necessary. You can set yourself apart with design just fine. The text, actual information people are trying to retrieve, is not part of the design. Specifying a font for the ordinary text is a perfect example of designers prioritizing self-obsessed wankery over the user.
  - kamjam 14y ago
    So all of a sudden we have become a design Nazi and telling people what their website can or can't include for design. The alternative to not allowing custom fonts is that people go back to using text in images to display their custom fonts which sucks when you are dealing with multiple languages or just want to change the text for something else. Or something like Cufon [http://cufon.shoqolate.com http://cufon.shoqolate.com]. Or use flash. I think I prefer webfonts, the developers just need to be smarter about how they are used and the implementation for including them.

snowwrestler 14y ago

No one needs a CDN to serve text quickly; that is massive overkill. CDNs in general are massive overkill for most sites. What a CDN does is reduce latency due to lightspeed. Is lightspeed really why it takes a site 10 seconds to show text? No. As you point out, caching and proper javascript management is the key to a site that shows text quickly. CDNs do provide caching, but are a complicated and expensive way to do so.

Groxx 14y ago
CDNs do a whole lot more than that. They allow common resources to be shared between sites. If 10 sites self-host jQuery, you download it 10 times. If they all pointed to the same CDN, you'd download it once, reducing your latency to below lightspeed - the time it takes to check caches on your device.
- snowwrestler 14y ago
  This is not a feature unique to a CDN; the same result could be achieved by simply hosting jQuery on a single server and pointing all your websites to that copy. My point is that when people talk about using "a CDN", usually what they are really talking about is caching. Whether that caching happens at the origin or the edge makes a very very tiny difference (the lightspeed difference).