Question: Because of certain reasons, I'm sometimes tied to an extremely slow internet connection. What I realized with this, is that certain sites (for example, any subdomain of blog.hu) works in a way that needs a certain part of the site be loaded before comments are loaded too. I assume it's because of an AJAX operation, as the comments themselves are not visible within the HTML file.

In contrast, forum engines, such as vBulletin are often free from AJAX, meaning that when a thread's HTML is loaded, every comment in it are "hardcoded", meaning that even if the "fancy parts" (CSS, images and so on) are not loaded, I can already read the comments.

My needs are very special though, so I'm interested - is there any general UX advantage of any of these?

Answer: 
There are physical limits as to how long a line of text can be before it gets difficult to process. Much like breathing while speaking, the mind needs periodic breaks to process the string of letters and numbers it has just taken in. Line breaks provide an opportunity for this to occur. A general rule that I have heard is to aim for roughly 80 characters per line.

However, this is not the whole story. It seems like we could simply base our font size off of the vw unit to ensure that we always hit this magical 80 character ideal, but no one really does this. Why not? The short answer is peripheral vision. Keep in mind that our eyes and brain also need to keep track of what line we're on, so when we jump after the line break, we know where to continue from. If the text block takes up too much of our field of view, the start of the line will be too far into our peripheral vision by the time we get to the end, and we lose sight of our place. That's no good either.

The best way to solve the demands of both character limit and field of view limit is to just enforce a maximum width that (hopefully) ensures we're fitting 80ish characters to a line while those characters remain large enough to read easily and the entire block remains small enough to stay within readable focus.

A couple of points about outlook and gmail specifically. Outlook uses some of the excess horizontal space to display both navigation and the list of messages in left aligned panes. The remainder of the window *appears* to be used for the message body, but extreme widths (using multiple monitors) reveal that it quietly enforces a max-width for the body contents. Gmail surprisingly does allow body text to grow effectively infinitely. I pulled up a couple of wordy emails to check, and to be honest long paragraphs don't read especially well. Note that the *compose* dialog is width limited, so it's somewhat surprising that they aren't limiting the width for reading. Perhaps they've found in their testing that emails are typically fairly short or (in the case of promotional) have already been laid out by a designer. Or perhaps Google needs to update their desktop layout...
* **Content Display**

Think about this: you make a site with content prepared for full width, no max-width. This will work relatively OK for common sizes, but full screen images for big screens will add a massive load OR they will get pixelated. Just choose your poison. And this is easily fixed by... max-width

* **Legibility**

There are many studies about line length. [NN/G says between 45 to 75 characters](https://www.smashingmagazine.com/2014/09/balancing-line-length-font-size-responsive-web-design/), [Baymard proposes 50 to 75 characters](http://baymard.com/blog/line-length-readability), [Viget says around 100 characters](https://www.viget.com/articles/the-line-length-misconception) and so on. For example, this post has around 100 characters width, and it takes 1/3 of my screen. The whole idea of having a 300 characters line makes me dizzy!

* **Control**

Your screen is a container which holds different elements. When you build a layout, you will place those elements according to different design theories, your project needs, your users, the needed elements to be displayed and so on. Thus, there's a high degree of intentionality. If you leave this to pure luck, all these elements will be randomly scattered and resized with unpredictable results. For example: An *"above the fold"* button may need 2 scrolls after an image is resized to adapt to full width (and proportionally increase height). As you may imagine, this isn't a very good option for anyone

* **Focus**

This is related to the item above. For example, let's say you want your user see a [smiling person right in front of her eyes](http://www.psychologicalscience.org/observer/the-psychological-study-of-smiling#.WEC5RH2S5aQ), and a CTA below that to increase clicks. Works great on mobile, laptops and desktops up to 1200px width. Then you decide to allow full width. Now the smile could be at the middle/bottom of the image and your CTA completely lost. Any simple study will tell you this is extremely wrong, and it's easily measurable

---

**Finally, one thing:** Full width with some amount of control is OK for carefully crafted sites with no dynamically generated content. However, you need to fine tune this in many forms. 

You gave the Google example: well, the **header takes the whole width**, but the content takes only `600px width` (the results themselves) with a maximum width of `1250px` if right sidebar is displayed. **See image below:**

[![enter image description here](https://i.stack.imgur.com/rLKaY.jpg)](https://i.stack.imgur.com/rLKaY.jpg)