Author: hawkeye

We Seek Page Load Speed and You Should Also

We do find that utilizing page metrics reports from both GTMetrix and Google PageSpeed Insights (GPSI) is essential to understanding fully how to approach page speed solutions for a given page on a web site. Each reporting tool emphasizes different metrics. To put that another way, the valuation and impact on scores for each metric is slightly different per reporting tool. An example of this would be the apparent high price paid, according to GTMetrix, for not using a CDN.

The current iteration of GPSI, since September, 2021, has changed up it’s testing methods established in November, 2018 – adding Core Web Vitals as important highlight to a good user experience.

The net result of those changes have scores obtained previous to the change dates now reporting significantly less regarding Mobile scores. This for a number of reasons, not all of which will make immediate sense.

The most important aspect, that which should be tackled first in our opinion, is to provide site-wide cache control using header expires, GZip compression, keep-alive connections, and Vary: Accept encoding directives in the server’s htaccess file for all local resources. Then, and only then, do we begin tackling render blocking issues — those items responsible for causing the browser’s render engine to pause it’s activity while waiting for additional resources to be available to it — items such as deferred delivery of Javascript; removing cache-busting query strings from static resources; minifying on-page code (HTML plus inline CSS/inline JS blocks). These aspects are provided for using PHP-based scripted functions added to the active theme’s functions file. We also optimize the order of styles and scripts, and provide inlining of selected CSS to prioritize content for Above-The-Fold content rendering.

Optimizing images is a very big deal, impacting directly the total page size – here we suggest using the utility plugin, EWWW Image Optimizer, to provide lossless compression of JPG/PNG resources. It is also important to note that many contemporary themes do not specify image dimensions in HTML as part of a responsive layout strategy. Therefore, it is imperative to select images no larger (width/height) than the largest size actually used in layout. Optimizing images should also include the use of lazy-loading for inline images, which we recommend using the A3 lazy load plugin for that functionality.

To be sure, you only have control over those resources within the immediate scope of the site. Third-party code can be excessive, particularly when it comes to ad services.

NOTE: The advisory to reduce server response time is triggered for all websites when the server takes longer than 400 milliseconds to respond providing individual page resources. The degree to which the server response time is above that ideal mark can represent a significant hit to scores. You can see the metrics for individual resources using the GTMetrix “Waterfall” tab, an important view regarding individual page resource size and loading time along with Core Web Vitals such as Time to First Byte and First Contentful Paint.

No matter which page speed measuring tool you use, we do recommend both, not every recommendation will apply to your specific page.

As one final note to consider: your database tables should be as lean as possible. To that end we highly recommend utilizing WP-Sweep as a utility plugin to periodically remove stale or unneeded revisions, unused or orphaned term meta and transient options. For mature sites there can be a huge amount of unnecessary revisions and related now useless data within relevant tables.

We have covered everything from the server htaccess file, the active theme-based functionality, image optimization and the MySQL database tables as primary topics. That’s it. That is all that is required as focus to optimize your site, it’s pages and page resources, to be as fast loading as possible. Well, there is one more thing – we make use of the plugin Autoptimize. It’s primary purpose here is to minify, concatenate and aggregate CSS and JS files into one, two or three files, thereby reducing total http-requests significantly. The reason you do not see any flash of unstyled content (FUOC) on page load is because we took the time to provide sufficient, appropriate prioritized CSS delivered by Autoptimize for above-the-fold content rendering.

One final note: the server performance can be a significant variable particularly when a shared server setup. Here, server resources are spread over the number of domains residing there. For this reason you may experience server response times and page load times as highly variable. Additionally, all themes are not created equal when it comes to managing local resources — some themes are structured in such a way as to thwart efficient optimization. Because of this, it is the theme structure that sets effective limits upon what can be accomplished when attempting page speed optimization as theme resources are scattered or delivery of these resources are re-written as proprietry functionality without concern for page load optimization by the theme author.

In many cases, the optimization plugin, Nitropack, is a vital addition for the best speed performance of mobile and handheld devices.

There is absolutely nothing natural about fonts. They can be exhilarating, poetic or very run of the mill and often difficult to distinguish one from another within the same typeface group or type classification.

So, why pick one font face over another?

In most cases it is easy enough to distinguish the difference between the Serf, Sans Serif and Cursive type classifications.

But, within the same type classification, you need a real eye for detail to discern the difference between two font faces. For example — here we have a side-by-side comparison of two “sans-serif” fonts: Europa and Libre Franklin. Europa is externally sourced, delivered via Adobe’s Typekit, and Libre Franklin is delivered internally as part of our theme’s webfontkit.

Comparing fonts using p and h3 tags

1.) Europa — h3: font-size:22px / lineheight:30.8px / font-weight:300, p: font-size: 16px / line-height: 24px

Comparing fonts using p and h3 tags

2.) Libre Franklin — h3: font-size:22px / lineheight:30.8px / font-weight:300, p: font-size: 16px / line-height: 24px

How would you describe the difference? In detail…

Europa seems more compact: not as tall standing within the same line-height, taking up less line space within the same character length, and slightly heavier in weight while using the same weight and color designations for each in this comparison.

Very much like a chosen word, a selection of font can reverbrate because of it’s use. The meaning is the use. The meaning is how it is used. The meaning is conveyed by virtue of the context within which it is used.

WordPress – Enhance your site’s performance and harden its security

This is all about the details of making use of the htaccess file on an Apache server to speed up WordPress as well as enabling a variety of security enhancements. The `.htaccess` file is located in the WordPress root installation directory and is sometimes used in subdirectories as you will discover below. This file is a hidden file, accessible to you through cPanel and/or your FTP file browser tool. In most cases you will have to purposefully select “show hidden files” to make it accessible.

Note: In some few cases, your hosting service places this file out of your reach. The one mistake to avoid here is creating a new htaccess file when one already exists, simply because you will over-write the existing one and you will not be able to step back in time. If you are uncertain, contact your hosting support. In all cases, WordPress will create the htaccess, or write to the existing file when you make a selection under Admin-Dashboard -> Settings -> Permalinks

For the sake of my presentation, I’m going to assume that you have one and you have write access to it.

The Security Enhancements

Place the following code into your htaccess file, uncommenting lines as appropriate. The pound sign (#) is the commenting marker in this context, when in place, a line of code that follows it is not executable. This is the common method for actually providing code comments defining the expected functionality.


# begin WP security enhancements

# to protect the htaccess file itself - uncomment - remove the pound sign from lines other than this line
# <Files .htaccess>
#order allow,deny
#deny from all
# </Files>

# to protect the wordpress config file - uncomment - remove the pound sign from lines other than this line
# <Files wp-config.php>
#order allow,deny
#deny from all
# </Files>

# if you use one - protect your php.ini file - uncomment - remove the pound sign from lines other than this line
# <Files php.ini>
#order allow,deny
#deny from all
# </Files>

# protect directory content from getting displayed - uncomment - remove the pound sign from lines other than this line
#Options All -Indexes

# end security enhancements


– The Definitive Approach

This is a big topic these days since Google has announced that page speed will be part of their ranking algorithm.

I use GT Metrix and Google PageSpeed Insights together to gauge the performance of your primary landing page. These tools provide a baseline reference giving me a clear view regarding a list of top priority issues, those most important items needing to be addressed to provide the required improved page load speed. The major issues fall into four distinct groups as render blocking, total page size, the number of http-requests a page must make to completely render itself and, finally, how quickly the page is fully rendered on screen. To no one’s surprise, after eliminating render blocking, there is a direct correlation between http-requests, total page size and that final page load speed.

The list is often quite typical regarding WordPress installations which, owing to the extensive use of plugins, is a CMS platform often plagued by code bloat…. For example, If you activate a plugin thinking your going to use it but do not, that active plugin is likely delivering Javascript and CSS files to your page, increasing http-requests and total page size for no good purpose. In fact, many plugins do deliver resources to pages that do not need them. This is a tactical flaw in the way some plugins have been written. I would note that a form-related plugin such as Cforms provides option for including resources only on pages that have a related form deployed via short-code or quick-tags. One wonders why all plugins do not get constructed that way.

NOTE: there are many plugin-related resources that are not part of your domain. Google Ads, Google Analytics and Google Fonts are a prime example. You will not have any capability to affect those external resources delivered. Including your Google Analytics code will get you two or three more Javascript resources in return. Such example facts make it imperative that you maximize your optimization efforts on those resources you can affect. And where you can, such as with Google Fonts, opt to bring them on-board.

The list::::

• Leveraging browser caching through headers expires and the compression of page elements through the use of GZIP. This is first on my list but should be tackled last, for doing so first creates a caching problem in tackling other items.
• Image optimization as a reduction of image file size, including the creation of sprites where appropriate to help reduce http requests, along with serving appropriately scaled images rather than using HTML or CSS to accomplish different image sizes in layout.
• Above The Fold Content: solving render blocking issues often requires inlining a subset of your CSS related to page elements displayed within the first-third of your page content, including header, main navigation and common sidebar elements. This can be overdone, so try to keep it simple.
• Providing minified versions of Javascript and CSS static resources along with deferred delivery of most of those same Javascript resources. The wp_enqueue_scripts functionality seems fairly cut and dry, but there are some not-well-documented approaches to making that work well for deferred delivery of scripts. See this recent article Defer/Async Delivery Options for WordPress for more information.
• Providing minification of the generated page HTML and inline CSS
• Disabling the WP Emoji functionality since (WP) ver 4.2 as appropriate to your individual use of such, eliminating two http-requests
• Identifying and deactivating unneeded plugins, as well as unused fonts

FYI::::

For the most part, an active theme’s functions.php file is where much of this attention is focused, but also includes your site’s htaccess file and your MySQL database tables as well, particularly when numerous plugins have been activated then deactivated, and when pages and posts have undergone many revisions.

The optimization process is lengthy and even a bit tedious, but well worth the effort. Indeed, it may well be a periodic process, certainly once a year. I should also note that not all contemporary server platforms are equal in this respect. There is a difference in what can be achieved on Engine-X (NGINX) and Apache platforms with Apache lending itself fully to the process. Also note that some hosting companies will not provide customer access to anything server-related.

Noting these possible limitations, I urge you to do what you can to increase page performance.

At some point you may also want to consider using a content delivery network as that final push to gain the absolute maximum of page load speed. Doing so will definitely be beneficial but will not replace the steps outlined above.

There are a few indispensable plugins aiding in this optimization process:::: Each of which are admin-level or back-end plugins adding nothing to page size or http-requests on front-end page load.

EWWW Image Optimizer is one such plugin optimizing images as found within the wp-content folder, also providing an option to define a path to images that may be outside of the wp-content folder; in other words, it optimizes all images within your domain, including theme image files, and does an exemplary job at it using the default settings for JPEG, PNG and non-animated GIF. It does not create a separate set of files, rewriting image paths as some image optimizers do. That last is a true NO, NO, NO!

Autoptimize uses the PHP page output buffer (where WP constructs the page before sending it to the browser). This ensures that the original asset order, as determined by WP, for all CSS and JS files is observed when Autoptimize assembles then concatenates the related files for link and script delivery.

Above The Fold Optimization is a complex plugin and not really for the inexperienced coder. It has many options, somewhat in the manner of W3 Total Cache, and thus, can be confusing, leading to great uncertainty. For you Saturday coder’s I recommend starting with Autoptimize. One major advantage when using Above-The-Fold is that it deals most effectively with gathering all CSS for a page, no matter it’s original source, concatenating assets in proper source order. It then delivers a CSS file to a folder in your theme. Here, you can use that single file on your visit to the Critical Path CSS Generator. Otherwise you will have to gather all of the page-pertinent CSS on your own. For complex themes such as Avada, that thorough gathering can be a cumbersome task.

BWP Minify is another handy addition to the toolkit, providing minification and concatenation of CSS and Javascript files, successfully maintaining source order.

Of these three plugins, you will use only one. Which one will depend on the code structure of your theme.

WP Sweep is yet one more helpful addition, allowing you to clean up unused, orphaned and duplicated data in your WordPress. It cleans up revisions, auto drafts, unapproved comments, spam comments, trashed comments, orphaned post meta, orphaned comment meta, orphaned user meta, orphaned term relationships, unused terms, duplicated post meta, duplicated comment meta, duplicated user meta and transient options. It also optimizes your database tables as a final step. A lean set of database tables is the outcome. Works only with WordPress 4.4+ because of new term meta structure.

Defer Async Delivery Options for WordPress

The following are notes on the provision of async/defer delivery options of scripts delivered via wp_enqueue_scripts. This was first introduced in WordPress (WP) ver 4.1, with the current WP codex documentation woefully thin.

Here is a full example of using the code as required:


add_filter('script_loader_tag', 'add_defer_attribute_lazy', 10, 2);
function add_defer_attribute_lazy($tag, $handle) {

if ( 'jquerylazyload' !== $handle ) {
return $tag; } else {
return str_replace( ' src', ' async="async" src', $tag ); }
}

This code should follow outside of the enqueued scripts routine. It is wrapped as a conditional, targeting the handle of each script individually as included in wp_enqueue_scripts. The string replace function will accept async or defer, adding such ahead of the src attribute. As noted a version of this code will need to be used for each script. If not using this method, the enqueued scripts are delivered in the standard manner. Currently, this only works for scripts, not styles.

Please consider these notes as a modest modification to the previous post entitled “Page Load Speed and Code Bloat”.

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.

Why use a Content Delivery Network – CDN?

What is a CDN?

A CDN or Content Delivery Network is essentially a network of geographically dispersed servers. Each CDN node (also called “Edge Servers”) caches the static content of a site like the images, CSS/JS files and other page-related structural components. The majority of an end-user’s page load time is spent on retrieving this content as HTTP requests, and so it makes sense to provide these “building blocks” of a site’s content in as many server nodes as possible, distributed throughout the world.

When a user requests your site, the node closest in proximity to the user will deliver the static content, ensuring the shortest distance for the data to travel (aka: reduced latency), therefore providing the fastest website experience for your users.

While CDNs are an appropriate solution for many websites looking for speed improvements, not every site necessarily needs one. It is important to understand how CDNs work, and if the benefits are worth the cost of adding one.

Why do I need a CDN?

The number one reason for using a CDN is to improve your user’s experience in terms of page load speed. As we all know, speed does matter — in the extreme, long page load times do lose visitors and can have a negative impact on conversions, bounce rate and general page SEO!

Ensuring a consistent experience for all of your users is vitally important.

A website may be hosted in a particular region but have the majority of its users coming from an entirely different region – for example, if your site is hosted in North America, checking your page load speed via PageSpeed, YSLOW or GTmetrix might report fast speeds based on their default test server location, but if a good chunk of your users come from Europe, their page load speed will not be as fast as you may have experienced it to be.

A global CDN would allow users from a European point of origin to download static content from a closer source. Instead of spanning the Atlantic ocean to retrieve data, they can connect to a server in London, UK, to get the same data. This reduces latency, providing a faster loading of your website.

CDNs not only ensure a faster experience to your users, but they also help to prevent site crashes in the event of traffic surges — CDNs help to distribute bandwidth across multiple servers, instead of allowing one server to handle all traffic.

Are CDN’s Absolutely Necessary?

Most users who analyze their site through GTmetrix, for example, will have YSlow’s “Use a Content Delivery Network (CDN)” recommendation triggered. This leads many to believe that it is a recommendation on the same level as “Minify CSS/HTML” or “Specify image dimensions”.

A CDN is a “next-level” optimization. It is not a self-contained fix like a server configuration change or a small code modification. CDNs are paid, third-party services and so implementation of one depends on your goals, priorities and budget.

Will a CDN help improve the performance of your website? Yes. Is it absolutely required for all websites? No. You can still provide a decently fast website experience without a CDN, but your site would probably be faster with one.

For those of you with heavy traffic, mission critical websites that are serious about providing the best possible experience for all of your users, a CDN should probably be a crucial part of your optimization strategy.

Cost

CloudFlare and MaxCDN are workable options, with CloudFlare offering a free basic account including ample parameters, and MaxCDN as a relatively inexpensive option for small to medium websites at roughly $9.00 per month. I would also note as a highlighted recommendation for WordPress based sites, the use of FlyWheel as a viable hosting option that does include a full-on CDN as part of that energetic package.