Hacker News Reader

Comment by dwightgunning | Hacker News Reader

"As developers, our job isn't to tell the designers "Hey, you're dumb for including over 500KB of WebFonts in your design!"

... 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).

View on HN

Well, in this case he replaced the designer's vision with Arial(!) because "Fonts all look the same below H3". Without ever talking to that designer.

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 litmus tests to a minimum, but this must be one: you cannot create good typography with Arial."

Can't follow that link for some reason. Firefox says:

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.

Redirect Loop Error on Vivaldi Browser for me

Same in Chrome.

I'm glad I'm not the only one that got terribly confused. I'm neither a developer, nor a designer, but I read it thinking - "hang on, I thought the issue with Web fonts is with the initial download speed - is it also true that Web fonts take longer to render?" Because that is the only reason I could see for using a different font for body style.

Because a developer-centered website needs custom webfonts, right? Even at the expense of performance.

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

Yes. In particular, it can be effective to use network conditioning to show and share the "flyover state small-town internet experience" with said designer, who doubtless has insanely fast internet at work (and home).

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.

Worth noting Chrome DevTools makes this super easy now - network throttling is built-in to the tool and can be applied any time DevTools is open.

On OSX there is a system-wide prefpane (part of Xcode extras) called Network Link Conditioner that allows you to quickly simulate different connection speeds, even different levels/quality of wireless signal.

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

Not true. I could make the comeback "any network throttling that only works on a single OS is honestly worthless," since people browse on non-Apple OSes. Though I will agree the prefpane is a cool tool if you can find it on the Apple Dev Downloads site. It can even run on iOS, for any app, not just the web. The Chrome solution will work on Windows too, though, or use Fiddler. More such tools can be found at http://stackoverflow.com/questions/3536249/simulating-slow-i...

> I could make the comeback "any network throttling that only works on a single OS 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.

No you're being argumentative.

Please explain OS level throttling matters here.

After all, we are not talking about general network conditions but performance of a website in a web browser such as Chrome. The Chrome tools were designed specifically with this in mind (simulate slow network and/or server).

> After all, we are not talking about general network conditions but performance of a website in a web browser such as Chrome

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.

How confident are you that the behavior of IE11 on Windows 10 inside a VM on OSX with outdated guest drivers and a prefpane only Cupertino understands is really similar to what a real user in say Bangladesh sees?

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?

> How confident are you that the behavior of IE11 on Windows 10 inside a VM on OSX with outdated guest drivers and a prefpane only Cupertino understands is really similar to what a real user in say Bangladesh sees?

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?

I think you are missing my point.

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.

I'm glad you made this point. I'd go so far as to say that providing feedback to designers and product managers on the tradeoffs of their decisions is the #1 job of a good developer in their role as a member of a product team, on par with writing the code itself.

and 'tradeoffs' doesn't just mean 'webfont & slow' or 'arial & fast' - that's the easy way out. There's also the tradeoff of 'more development time/effort & webfont & fast;

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

Besides, it only optimizes the non recurring user case - 10x improvement is only for the first time visitor, which may or may not be a minority or even then may or may not have the font in cache from other places, which is not unlikely especially if he used a font from the most common cdns.

Reply on news.ycombinator.com