3 ms·
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
by 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 agoThat's a really handy little trick, thanks!
- Groxx 14y agoIMO 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 agoAll the more reason to use userContent.css to override site fonts. Size and face are legible.
- Groxx 14y agoAbsolutely 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.