It's not your exact words, but I don't think it's an unfair characterization, if the excuse is simply that they'll be reading it on a desktop machine anyway.

I took that image from a non-laptop desktop machine, by the way.

> It's not your exact words, but I don't think it's an unfair characterization

You ignored the half of the sentence following the 'or'. To me, that's unfair.

> if the excuse is [...]

It's not an excuse, it's context.

The performance is a low priority compared to the content, when the site is a developer resource.

And for me it speaks to credibility.

As another random anecdote from another random developer, I find the site's content far outshines any purported credibility loss - which just seems like a very silly argument to make.

Perf is not important for a dev resource. If a dev had spent a ton of time optimising that they'd have wasted their time. Why does wasting their time make them more credible?

I disagree.

In many places, perf is still important, and one of the reasons, I believe, that GNU offers its manuals in various formats: [0]

I know of a few devs that work for web, but due to their nations economics, work:

* On a smartphone

* Via a satellite connection

Despite being in a first world country, I've had to do both at various times whilst working from remote areas.

The GNU manuals have a huge wealth of information, but they load fast by following simple-first policies.

caniuse.com is a SPA, but they load damn fast.

I'm not saying that this page is insanely slow, but that it is slow at all is still a surprise.

And not every dev in the world gets to have broadband.

[0] http://www.gnu.org/software/libc/manual/

> The GNU manuals have a huge wealth of information, but they load fast by following simple-first policies.

Do all GNU projects keep there documentation i one big file? I wanted to contribute some recently but got lost in a complex help file.

Most GNU manuals I've seen come as:

* HTML - entirely on one web page.

* HTML - one web page per node.

* HTML compressed (gzipped tar file) - with one web page per node.

* Info document (gzipped tar file).

* ASCII text compressed (gzipped).

* TeX dvi file (gzipped).

* PDF file.

* Texinfo source (gzipped tar file).

If the one big file (great for grepping) was too confusing, you probably want to opt for HTML, with one file per node. For example, the Sockets/Local Namespace page for glibc: [0]

[0] http://www.gnu.org/software/libc/manual/html_node/Local-Name...

Edit:

And it appears the help files are seperate inside the source code as well. [1]

[1] https://sourceware.org/git/?p=glibc.git;a=tree;f=manual;h=71...

> And it appears the help files are seperate inside the source code as well.

Thanks. It appears that this wasn't the case for make.

Ow. Make's manual is a 10,000 line texi file.

That really sucks.