Yes. Yes it is. I want to browse the web of 2006 with an Internet connection of 2016. I really wish websites wouldn't require me to download hundreds of different JavaScript libraries, fonts, Flash, video files, and who knows what responsive AJAX nonsense. I really like minimalist websites that do what they need to do without tens of megabytes of cruft. Like this one.

Imagine a print designer that didn't know about bleed, DPI or colour showing through paper. They may not personally be in charge of printing things, but they absolutely need to have domain knowledge or work with someone that does.

If I look at the actually ambititous people, those comparable to the HN crowd of programmers, I just see enourmous competence. They no longer do web design with a desktop publishing mindset (that's a clich=e of the 90ies). They've rebranded to User Interface Design, to Interaction Design and to whatever "Service Design" may be. Which means: they usually know better than most programmers that design isn't about something being pretty, but that it's part of an interaction of machines, data & humans.

I seriously don't know any designer who isn't obsessed with usability, load times, discoverability and so on. You also can't get a degree today without at least a few semesters of python.

Do they always hit the right balance between performance and features? I don't know. But it appears as if there's a fundamental principle: Just like some would like to surf the 90ies web with the 2016 connection, others may want to run Windows 2000 on today's computers, or get a car from the 60ies produced in today's effiecient factories.

In all these areas, the creative people as well as (too an overwhelming extend) the consumers have chosen a balance that appears to work ok. And anyone complaining here be better only writing in C & Assembly.

... As performance-minded web developers, our job is to deliver the designer's vision in the most performant way possible."

Design is all about trade-offs. Performance is part of the experience and that's something all designers should care about.

Developers should definitely raise this type of issue when it arises (albeit without the name-calling and in a collaborative manner).

I'm sure a collaborative effort would have resulted in simply removing the 10 unused font variants and leaving the two that are used. That would save 416kb of those 500kb without being tasteless.

This is a good ressource on what designers think of his choices of Arial and Helvetica: http://practicaltypography.com/helvetica-and-arial-alternati.... Quote: "I try to keep the lit­mus tests to a min­i­mum, but this must be one: you can­not cre­ate good ty­pog­ra­phy with Arial."

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

uses security technology that is outdated and vulnerable to attack. An attacker could easily reveal information which you thought to be safe.

If only designers would learn that their job is not to paint a pretty picture, but to provide a good experience...

http://alanhogan.com/slow-it-down-gain-empathy

⁂

And to your point, I do love this Brad Frost quote (which I share in my article above):

> Ultimately, performance is about respect.

Any Browser-testing that only works in a single browser is honestly worthless.

And I would say you're being argumentative. The Chrome extension can only affect Chrome. The OS level conditioner can affect anything running on the computer, e.g. if you're doing your Windows/Linux browser testing through VMs (on a Mac), they can also use the OS X link conditioner.

Apple's network link conditioner is also available on iOS (when setup as a developer device).

The only option more device agnostic than Apple's is a network level device, which is likely much more effort than 90% of developers are going to spend on this problem.

As I explained, a single prefpane on a Mac can potentially allow you to check network performance issues in every browser for OS X, Windows, Linux or any other desktop OS allowing you to thoroughly test how your site/app performs.

Saying "I tested it in Chrome and it was OK" is basically the 2010's version of "Works best in Internet Explorer". That a lot of people saying that, are also calling Safari "the new IE6" just makes their position even more ridiculous and laughable.

Why not use the tool specifically created for this? A tool that you would be using anyway since you, I hope, also test for screen size/resolution issues?

a) update your guest drivers. b) what do you mean "only Cupertino understands" c) does Bangladesh have some kind of specifically different "poor network" conditions that the rest of the rest of the world is not aware of?

> Why not use the tool specifically created for this?

For testing poor network connections? That is specifically what Apple's tool is designed for.

> A tool that you would be using anyway since you, I hope, also test for screen size/resolution issues?

What are you talking about?

Bandwidth throttling is only one of the tools you need for performance testing. You may also need to, say, change the screen size and reported device resolution and user agent at the same time.

Chrome gathers all these tools and tons more under the same page. And they are specifically created for this purpose, hence probably more accurate than some OS specific implementation.

As a developer, I hate saying 'no' to something, because rarely are things just not possible. They just might take a while.

I wonder if Google plans to add a paid collection of premium fonts to its library – while I prefer open source fonts, I know a number of designers who use very specific fonts outside of what's currently available for free.

Regardless of the following paragraphs (which give a primary reason of `unicode-range` CSS property), it is that good. Brotli, a compression algorithm used by WOFF2, is a very good fit for regular-looking but non-repetitive data---that includes many binary formats including OpenType. I have seen at most 10--20x improvements over uncompressed TTF.

Of course, the speed estimate could be wrong if the bandwidth bottleneck (on either previous sites or the current one) is further than the last mile, especially for e.g. Chinese users whose Internet speeds are drastically slower with international peers than domestic ones. Or alternately if the user is on a mobile connection and is moving quickly between areas with good and poor reception, going on and off Wi-Fi, etc., although in that case the browser could incorporate signal strength data from the OS. Still, on an Internet whose users have wildly varying connection speeds, I think it makes sense to allow leveraging the difference somehow.

For the server-side, perhaps you could make use of the quality parameter in the content-type headers to play about?

Typekit has a feature they call language subsetting which reduces the file size of a particular typeface family by removing language support based on user selection. This can reduce font sizes quite a bit.

>Google Fonts doesn't use any JavaScript (by default, anyway), which makes it faster than almost any JavaScript-enabled approach

This involves a stylesheet which means the rendering is blocked until it is downloaded and processed and the users will see a page with blank text until that happens. Sometimes it is better to show the content (even in a fallback font) instead of a blank page.

1: https://github.com/typekit/webfontloader

https://github.com/rubygems/rubygems.org/issues/1095

https://github.com/rubygems/rubygems.org/pull/1109

If I absolutely need to visit a site that uses mission-critical webfonts, I'll just open IE, do my business, and get out.

- The OP makes some weird kind of pedantic performance argument about moving script tags around in the head for some possible optimizations. Anyway, it wouldn't make any difference and your page would still be blocked if Typekit failed to load.

- The text parameter to Google web fonts would render any prior cache-ability gains moot and could potentially change the unique ID of the resource as the text of your site changes.

I'm not trying to be too negative, but I don't see what all the fuss is about with this article? Yeah, someone added a big bloated third party font service. You found it, and removed it.

Shouldn't Rubygems be using some unicode or built in serif font anyway? They're going to need all the perf improvements they can get when their time to first byte is 300+ ms. ;-)

How so? I had only good experiences with Google fonts, especially compared to other services or just plain self-hosting of font files.

It seems like a nice middle ground to provide a somewhat unique and nicely styled experience, without forcing the user to download a bunch of extra stuff, and also possibly keeping it a little more "native" looking in whatever browser they're using.

I use web fonts everywhere and can't imagine trying to build any kind of layout relying on system fonts alone. When doing CSS I have to use a giant wishlist like this to try to target a 'nice' font on each system:

    font-family: "Source Sans Pro", "Open Sans", Roboto, "HelveticaNeue-Light", "Helvetica Neue Light", "Helvetica Neue", "Myriad Pro", "Segoe UI", Myriad, Helvetica, "Lucida Grande", "DejaVu Sans Condensed", "Liberation Sans", "Nimbus Sans L", Tahoma, Geneva, Arial, sans-serif;

Your fonts and even colors could change. Webfonts are great and all til the idiot designer picks some "nice" ultra-thin that, while probably looked real sweet on his/her fancy Retina Cinema Display, looks like ass on mine.

> Your fonts and even colors could change. Webfonts are great and all til the idiot designer picks some "nice" ultra-thin that, while probably looked real sweet on his/her fancy Retina Cinema Display, looks like ass on mine.

A colleague made a comment: she's a Chinese speaker with great English. I'm an English speaker with pretty functional Chinese.

"Why are the letters so small. I don't even want to look at it."

This was a default setting. So we increased it to 16px. It was good. It is a pain reading in a script you're familiar with, but not intimately so you've read 1000s-10000s of thousands of words in it per day since childhood. Everyone in the office (in China) appreciated the change.

Then I got the reverse shock, of a colleague releasing an internal website in all I can describe as thin font, grey, light blue background, and around 10px. Chinese characters at 10px are a pain. A massive pain. And I felt the pain that my colleague experienced. He: "Oh, I see. But it looks cool." Me: "Look at how everyone in the office [native Chinese readers] bends their neck when they read this site."

This was an extreme difference, but also should be considered. If you're creating something for an international audience, accommodate those that may have grown up with a different script, and simply read differently. Not a different language - a different script.

[1] I credit this metaphor to http://idlewords.com/talks/website_obesity.htm

However, the web is more than just text articles, and the precise positioning and display of text is quite important for web applications. It's important for me to know if the text on a button is wrapping or being cut off, and even more important for me know that my application will look the same on every screen.

I set a 13px minimum font size in my browser (the smallest size I can read comfortably on my screen) and I constantly run into web applications that try to go for the level of control you describe and totally fail because they think 10ps fonts are a good idea. Of course my usual response is to close that tab and never use that web application again if I can help it.

Ultimately, web applications (particularly enterprise and other B2B services) are designed to replace a lot of functionality normally relegated to native applications. While it is important to present a nice, clean interface, material design UIs with nice, large fonts and generous margins won't let me show what I need to show without making the user search through menus or scroll across a massive page.

Well, sure. My personal suggestion is to have lower information density if the higher one can't be achieved without going below the 16px default font size of browsers and allowing scrolling as needed. After all, that's what you end up with _anyway_ if people full-page-zoom. Except now they typically need to scroll in two directions, not one, if the page hardcoded some widths in.

> However, the vast majority of people do not set minimum font sizes.

This is through lack of knowledge, not lack of desire. All the people I've showed this feature too were incredibly happy to see it. All of the older relatives I've set up computers for have minimum font sizes set up.

Keep in mind that as of the 2010 census there were about 309 million people in the US, of whom 74 million were under 18. Of the remaining 234 million, 40 million were over 65 years old: that's about one in 6 adults. Another 59 million were 50-64 years old. Another 22 million were 45-50. So over half the adults are over the age of 45. Oh, and another 21 million were 40-45. See http://www.census.gov/prod/cen2010/briefs/c2010br-03.pdf page 4 or so.

Age-related problems with vision start in the early 40s. So unless you yourself are already experiencing them (and hence can evaluate how usable your web app is), or unless you know your web app will only be used by Silicon Valley startups all of whose employees are in their 20s or something, you should probably assume that a large fraction of your users can't read smaller fonts.

I appreciate that this is a hard problem. I'm just saying that browsers allow users to override whatever styling the web page is doing, they will continue to do that, and as the population ages even further I expect it to become more and more common for users to do just that.

Note that generous margins are not as important as not too small fonts (not to be confused with "large fonts"; the default 16px font of browsers is not a "large font" in any reasonable sense, and yet people keep insisting on having text that is _much_ smaller than that) for purposes of readable text.

Why is 'material design' itself important? It's an arbitrary standard cast by Google, and in the opinion of many of us, it's ugly-as-hell. Same with large fonts and generous margins!

That's my whole point. It's a superfluous concern.

I tell my browser what font to use. I want it to render correctly. I know what does. You probably choose something that doesn't.

* website navigation often contains text

* User-Interface controls often contain text

I'm less concerned about trying to have my lines break in the same place or having the perfect kerning, but if giving the browser some good fonts to work with can cut down a whole ton of tricky, ongoing, hard-to-debug, hard-to-test edge cases then it's a no-brainer!

I still give the whole wishlist, so if for some reason there's no access to google it still does the best it can - my argument is that a professional/commercial web design in 2016 can't lack web fonts because it will co$t more not to have them in developer time. I am that guy that gets paid hourly to track down those bugs.

The other bit of CSS that ought to be on every website EVER, is:

    *,
    *:before,
    *:after {
      text-rendering: optimizeLegibility;
      -webkit-font-smoothing: antialiased;
      -moz-osx-font-smoothing: grayscale;
      font-kerning: auto;
    }

I've got a bunch more of my snippets here: https://gist.github.com/tomhodgins/27c29ecb4aceaefe5cdf

> Do you also use a fixed width div holding everything? One no wider than a VGA screen?

Also got a giggle out of this one - I specialize in responsive web layouts, my job is making fixed-width layouts work on phones and tablets, hundreds of devices to make more $$$ :)

My websites would fare a lot better unstyled than most websites built on top of frameworks like Bootstrap and their 'classy' HTML, but it's still not going to look good without CSS and no online business is going to make more money without CSS than with it.

I'm a big fan of terse, straightforward HTML, plus nice CSS on top of that. I've made (and get a lot of use out of) a basic.css stylesheet I built that supports a few basic themes: http://staticresource.com/basic-test.html

Let's see some of your HTML J_Darnley :)

I don't see a license mentioned anywhere, though. Can I use that code on my sites?

Those themes (and more) are included under the 'Template Factory' project over on Github: https://github.com/tomhodgins/template-factory

That package contains more than just basic.css, but also includes three additional styles, and a bunch of simply written responsive CSS + JS plugins as well.

Some websites make me glad Palemoon still has the View -> Page Style -> No Style option. I do admit a day may come when I do disable CSS once and for all.

Unfortunately, as people write more and more convoluted html, and are using javascript techniques for laying out web pages and blogs, not just web applications -- it's becoming harder and harder to have the reading experience one wants, rather than the reading experience some designer fop thinks you should want -- for no good reason.

It started with Microsoft Frontpage setting the background to white without overriding the body text colour by default (so those that had a user stylsheet for reading white/light text on a dark background got zero contrast) -- and has been going steadily down hill from there.

http://alanhogan.com/bookmarklets#subpixel

(Note: my idiotic web host broke my SSL and this bookmarklet isn't working on HTTPS pages at present. I hope to fix this within the next month.)

http://stackoverflow.com/a/12430050

Some of the problems I listed there are less important now that Windows XP is increasingly just a bad memory but I'd strongly recommend using the standard CSS font-features flags to enable whatever your design depends on.

And using a fixed-width DIV -- or cramming everything into a TABLE cell in the old days -- has been recognized as a remedy to one of the Web's most glaring typographical bugs: the tendency to expand the text flow to the width of the browser, which fucks with a human reader's ability to scan the text.

Graphic designers who don’t get the web need new jobs.

We still live in this world. Chrome isn't even internally consistent, hitting reload in the same browser will sometimes give you different kerning.

HTML+CSS is not pdf, even with webfonts.

If that is what one wants, use PDF. Seriously.

I expect that User Agents will continue to give the user the option of overriding any and all styling the fetched web page wishes to apply until long after I am dead.

Which then get reintroduced when the font doesn't load or it gets replaced by local fontconfig. Even though many people like to pretend otherwise, the web is semantic markup, not a precise layout tool. The client controls the rendering - CSS (and the markup) is only a suggestion.

The truth is, some fonts like Source Sans Pro, Open Sans, Source Code Pro, and PT Serif are actually of better quality than most system fonts as well - so not only are you moving toward a font that is going to show up better, but you get the same font everywhere - making sizing and spacing a LOT more predictable.

> the web is semantic markup, not a precise layout tool

Yes, this is how I introduce it to others: http://codepen.io/tomhodgins/post/an-introduction-to-html

I get paid lot to fix these problems so really it's in my be$t intere$t to tell you NOT to use web fonts, and to hire me over and over again fixing sizing and spacing bugs that pop up like whack-a-mole for $$$/hour … but I'd rather be building new things than duct-taping old solutions. If you don't want to have to hire me, use web fonts from the start. It's how I'm going to come in and $olve the problem for you, so why not $ave your$elf the trouble :)

Which means you're ignoring the people that either block GA specifically or don't run javascript.

> how could you even possibly keep track of what system fonts they all have available?

You don't. That's why you design for em/ex/rem units, or use designs that don't care.

> are actually of better quality than most system fonts as well

That's personal opinion.

> but you get the same font everywhere

No, you don't. For example, I have a long list of entries like this in my ~/.fonts.conf

    <match target="pattern" >
        <test name="family" qual="any">
        <string>Helvetica Neue</string>
        </test>
        <edit name="family" mode="assign_replace">
            <string>Ubuntu</string>
        </edit>
    </match>

CSS declares special pseudo fontnames like serif, sans-serif, monotype that you can set as a backup font. They should work in all browsers.

> I get paid lot to fix these problems so really it's in my be$t intere$t to tell you NOT to use web fonts, and to hire me over and over again fixing sizing and spacing bugs

It only means the person that programmed original CSS code was not qualified enough to do this properly. Why "fix" this by adding multikilobyte download instead of fixing the code?

I think a good layout/design that works with system fonts alone ought to be considered a greater success than a pixel-tight layout that only works with 1 forced-download font that eats up bandwidth, or a questionably "cheaper to support" layout that has a 275-character-long font-family rule.

Simpler, yes. Cheaper, no, not if you're a business that makes money from their website.

> I think a good layout/design that works with system fonts alone ought to be considered a greater success than a pixel-tight layout that only works with 1 forced-download font that eats up bandwidth

Me too from a technical standpoint, however there is no system font in the same quality as the web fonts I use available on most systems. I'm supplying a font that fixes font issues, it would be amazing if I could install better fonts on every system in the world so I didn't need to supply it.

> a questionably "cheaper to support" layout that has a 275-character-long font-family rule.

Oh that font rule still goes in there in case there's any issue with the webfont. That wishlist I posted is right out of my own CSS files, that's what I use. I can guarantee you that using that font stack with Source Sans supplied via fontface _will_ look better on every system than whatever system font would display from that list if Source Sans is missing. It's literally the best produced font I've ever used (in a technological way, I'm not even considering style here) which makes it very versatile.

I design things all the time that don't include webfonts, it's called my non-professional work. In 2016 if you're paying a professional to create a web layout and they aren't supplying you with a professional-level typeface to work with inside layout, they aren't giving you a complete frontend solution.

They are, but they are opinions based on a decade and a half of working with these technologies, and being currently employed as a specialist in responsive CSS. I'm not just giving you my opinions, I've been linking directly to open-source solutions I get paid to provide for clients. No pitch, I've done the opposite—I've given you the jewels. You won't need to hire me to fix these things now if you use my code for free ;)

> Yet you continue to deliver these rationalizations as if they're incontrovertible facts.

Based on hundreds of hours of testing across different browsers and devices, you're going to have to trust me that what I have left is thoroughly tested and proven to work.

I have nothing to gain or lose from what I've said here, but some of the insight and code samples I've provided might help people avoid or fix a whole class of common website bugs - the kind that are hard to reproduce, and hard to test because they usually pop up on exotic hardware or software configurations.

I Hope my opinions, tested code, and experience have helped some professionals in this thread :)

I'm curious how you would approach building a website that isn't broken when viewed on dozens of devices and browsers. Do you have any opinions, code, or suggestions to contribute to the discussion?

By the way I think downloadable fonts should not be used on technical sites and manuals. As a user I would like to get information as fast as possible and custom fonts make page display slower - browser doesn't render text until font is loaded. It would be nice if Chromium allowed to disable loading fonts on a per-site basis as it does with javascript (which I have disabled by default).

German vs Japanese makes a bigger difference than a font with half a pixel more kerning.

In a reasonable world my browser would instantaneously load the content (text fits in a couple of TCP packets) and I'd have an option to choose Shiny Mode (or a bar to toggle it on permanently with).

Instead, half of the 'articles' I come across on the web don't work without animated full page transitions, pop-ups within the page, blah blah. I preferred the MARQUEE tag, quite frankly.

Hyperbolic much?

> Why exactly is Rubygems giving idiots access to it's source code?

It's open source https://github.com/rubygems/rubygems all idiots have access to the source code, even you.

I think the words you're looking for are "Thanks for taking the time to make Rubygems faster, and for doing a write up on it to show the costs and benefits of using a webfont. Now I see that style can come at the cost of performance. I'm curious what the speed differences would have been if they had gotten rid of the 10 unused font variations and kept the current webfonts."

Even better would have been "I ran the benchmarks for my suggested change and found it to be nearly as fast, I don't think we should sacrifice all visuals for the sake of performance, here's a link to my PR to Rubygems to re-instate the webfonts with a script on how to reproduce my findings. Thanks everyone for all your free open source work, and for sharing what you've learned."

I get what you're trying to say, blowing it out of proportion and being highly critical of people doing free work for you in their free time while doing nothing to remedy the situation isn't going to help anyone.