On the topic of page load speed within WordPress
For WordPress based sites, attending to code bloat can be mission critical because for all of the honest benefits this platform provides, and there are many, such a content management system (CMS) is rife with numerous additional HTTP requests inherited from plugin-related content and functionality as site-wide HTTP requests that are often not needed to render the content of a specific page. This is a decided fault in the current core WordPress, as well as within the usually vaunted “best practices” thinking for WP plugin developers. These standards are in need of upgrade, promoting requirements such as providing admin-level checkboxes as selectable during the creation of new page content, allowing for NOT including plugin related JS and CSS for specific pages, and/or checkboxes to create defer/async selections for delivery of external or third-party JS elements, including similar options for the otherwise extremely useful wp_enqueue_scripts and _styles.
Note: in the wind currently is conversation regarding an option to include CSS files as a site-wide HTML import (@import) rather than as a link. Wholly dependent on browser support, this is an option-in-waiting with the current versions of Chrome (ver. 47), Android (ver. 46) and Opera (ver. 34) in full support. There are presently various degrees of consideration on the part of the remaining browsers, few of which seem hopeful at this point in time. If this option is not supported 100% in the very near future, it will be considered as dead and a grim reminder of those days when there was a significant performance split between IE browsers and the rest of that universe, a reality then promoting all manner of “hacks”.
Further, Google needs to recognize that it has established a delivery regimen for Google Adsense that is peculiarly at odds with it’s own PageSpeed metrics and recommendations – if you include one google-based javascript file, you get 3, 4, 5 more file requests as a direct result, and there currently is no provision for insuring full-on defer/async options within that file delivery structure.
Here I’m simply noting the common cause of inflated, excessive and often unnecessary HTTP requests to render a given page, along with unfortunate limited ability to help solve render blocking issues in above the fold content, in general.
One final NOTE: Among many other helpful aspects, content delivery networks (CDNs) do help in reducing the total number of HTTP requests per page.