> Page weight is by far the most important factor in page-load performance.
This is terrible advice, often how much the page weighs (whether it's 10kB or 500kB) has little to no effect on load time, the number of requests is often way more impactful.
I generally agree but the number of requests is also too simple a rule. You really need to look at the number of blocking requests and what they block – e.g. loading a large image might seem low-impact since browsers have progressive decoding but you often see cases where the load order goes like this:
1. HTML starts trickling in
2. Browser scans for resources and starts opening connections for stylesheets (great, since they block rendering) and other inline resources
3. Since you followed everyone's advice and put your scripts at the bottom of the page, you now have 2MB of images saturating all of the available server connections so the JavaScript is waiting for a connection to complete and, of course, there's no way to progressively render a script
4. The relatively small JS loader / jQuery / etc. eventually loading triggers a whole new set of requests which are now at the end of the queue behind all of the CSS and content references for images, fonts, etc.
HTTP/2.0 will help significantly with all of this but in the meantime various bundling hacks used to lower requests counts and the lack of dependencies as a first class concept mean that you tend to see a lot of unintended load delays unless someone has carefully profiled their page loading behaviour.
This is terrible advice, often how much the page weighs (whether it's 10kB or 500kB) has little to no effect on load time, the number of requests is often way more impactful.