Month: September 2019

Reduce Web Page Load Time

Reduce Web Page Load Time

One of the most measurable aspects of web performance optimization is how your efforts reduce your web page load time.  In this article, I will go over the tasks that you’ll need to complete in order to significantly reduce the load time of your web page.

Is Your Web Page Fast Like Car or Slow Like a Tank?

How fast a web page loads boils down to the number and size of the assets (scripts, stylesheets, images, fonts) and IFrames (inline frames) that are required to render the page.   A web page with no styles, scripts, or images will load much faster than a web page with 50 images each 2MB in size, 40 stylesheets, 20 scripts, and three YouTube videos.  Granted, the web page with no styling will not look as attractive as the one with many resources.  The argument of “content is king” would suggest that less-is-more when it comes to page design, however most modern web pages include many stylesheets and scripts just to make it seem “flashy” to compete with the competition’s website.  The masses have grown to expect a certain level of sophistication when it comes to styling your website.

So is your website light and agile, or slow to load, but blows away the competition?

I’ll show you that you can keep your high end design, and still have your web page load fast.

Reduce The Weight

The heavier something is, the more effort it takes to move that object.  Sir Issac Newton summed that up with Force = Mass x Acceleration.  When it comes to web pages, the formula is something similar, but it comes down to Time = Size / Speed of Throughput.

The time it takes to transfer a file comes down to how large the file is, divided by the speed at which it can be transferred.  A 5MB image will take 5 seconds if the transfer rate is 1MB/second.  Many high speed internet can transfer files at 20-200MB/second.  This means that if your web page has 20 5MB images, it could take anywhere from 0.5 to 5 seconds to load those images.  But on cellular devices, the transfer rates of 3G are more in line with about 1MB/s.  So what may seem acceptable to a desktop user will be infuriating to a mobile user.

Before you handle any other aspect of web performance optimization to reduce web page load time, you first must optimize your images.

And not just optimize the images, but also make sure they are sized correctly.  If the image original image that you have is 5000×3000 pixels in size, that’s easily 10 times larger than it likely needs to be (depending how it is used in your web page).  Ensure that the width and height of the image that you are using fits the space that you are placing it into.  Once you have done that, then optimize it.

Depending upon your platform that you use (be it a static HTML website or WordPress CMS) there are different plugins and services available to optimize your web pages.  If you use WordPress and you do not yet have an image optimization plugin, the Pegasaas Accelerator WP plugin that we developed includes Image Optimization (including auto resizing) as one of it’s many web performance optimization features.

Lazy Load the Inessential

If this is the first time you’ve heard the term “lazy loading”, then know that it means to “load only after the resource would traditionally be loaded”.  The intention of lazy loading is to reduce web page load time.  You can lazy load all sorts of assets, from images and inline frames (most commonly found with YouTube videos) to stylesheets and scripts.

Lazy Loading Images and Inline Frames

Without a doubt, images and inline frames are the most common elements to lazy load.  In fact, Chrome is now supporting the loading=”lazy” attribute for both images and iframes.  While we don’t suggest using this method yet, as it isn’t supported by the other major web browsers.  If you rely only on this method of lazy loading, those users viewing your web page in FireFox, Safari, or Microsoft Edge or Internet Explorer, will experience a heavy page load.

If you have the ability to get a plugin for your website that will allow you to lazy load your below-the-fold resources, it can make a significant impact in reducing your web page load time.  YouTube videos alone inflate the load time of a web page by 2-5 seconds on desktop.

Lazy Loading Scripts and Stylesheets

While lazy loading images and inline frames is prevalent, the ability to lazy load scripts and stylesheets is far from commonplace.  The reason scripts and stylesheets are not typically lazy loaded is that it is complicated to execute and that you do not reduce much in the way of web page load.

For scripts, you need to know which scripts are not used to either render any component above the fold or control any functionality that is required for an event that can happen before the user has scrolled.  Nearly all scripts that are loaded into a page are used in some fashion to render the page.  The only scripts that typically are not required to be executed in-order are those stand alone scripts with no dependencies (such as an Instagram gallery below the fold, WordPress “comments” script, or Google reCaptcha widget).  You have to be very careful that you do not lazy load any scripts that are dependencies (jQuery) of others (most WordPress themes functionality).

For stylesheets, in order to be able to lazy load, you must have an accurate snapshot of the Critical CSS required to render the page.  If you lazy load your styles, but don’t have an accurate Critical CSS snapshot, when the stylesheets are loaded, you will experience a “repainting” of the page and some items will appear to “jiggle” into place.

Lazy loading of images, iframes, scripts and styles, are all included in the Pegasaas Accelerator WP plugin for WordPress.

Defer The Stylesheets

Stylesheets are, in their default state, “render blocking” resources.  If you have a stylesheet in your page <link rel=”stylesheet” href=”…”> your web page will be blocked from rendering until that stylesheet is loaded and parsed.   When you click on a link, but see your browser doing nothing, part of that “nothing” is the loading of the render blocking resources.   You can imagine, if you have 20 stylesheets all 10-100KB in size, that there would be a delay.  Depending upon the speed of your connection (if you’re on desktop, it will be faster than the connection of a mobile device by about 3x), you can reduce the web page load time by 2-10 seconds by simply deferring the stylesheets.

The Catch

Yes, there’s a catch.  If you defer your stylesheets, you need to also inject “critical CSS” into the “head” region of your web page.  Critical CSS (also known as critical-path CSS) is what it takes to render the above-the-fold region of the web page.  Every page has different critical css, however most pages will have very similar snapshots.  Some third-party plugins that inject critical css into a web page do so on a “page type” basis (page vs post vs custom post type).  It has been our experience that this will result in an incomplete snapshot in many cases, and thus cause your web pages to exhibit a bit of “redrawing” once the stylesheets are loaded in.

Unfortunately, the critical CSS engines that are used by many in web performance optimization (critical, penthouse, criticalCSS) often lack precision when it comes to getting an accurate and complete snapshot of CSS.

Putting It Together

So, if you’re going to defer your stylesheets, you need to have a complete and accurate snapshot of critical css for your pages.  If you have a one or two page website, this won’t be much work, but if you have a website that contains many pages then you’ll need to automate this method.

This was the very first feature we ever built for Pegasaas Accelerator WP.  Through our API, we scan the web page that is being optimized for critical CSS, automatically injecting the snapshot of styles directly into the optimization page.  The result is a web page that looks great and loads much much faster.

Defer The Scripts

Just like stylesheets, scripts are considered “render blocking resources”.  The page will not begin it’s rendering until the render blocking scripts (and render blocking stylesheets) are loaded and parsed.  Deferring scripts is as simple as adding a “defer” attribute to the scripts.  It is important to note that there is more than one way to “defer” scripts, however it is our experience that using the alternate “async” method is prone to scripts executing out of order, which causes web page functionality to break.

There’s one major problem with deferring scripts, however.

The Catch

Yes, even with deferring scripts there is a catch.  The problem arises when there is “inline” code in the page.  For example, you could have “jQuery” deferred until the end of the page, but if you have an inline block of code that controls a slider, menu, or carousel (for example: <script>jQuery.dosomething();</script>), that functionality within the page will be broken because the page will attempt to execute the inline javascript before the “jQuery” library has been loaded.

The Solution

Ah yes, I wouldn’t mention the catch without telling you there is a solution.  The solution is to bundle all of the “inline” javascript up into a single file that is deferred as the very last script in the page.  This means that you have to keep on top of the inline script in all of your pages.  However, the upside of fully deferring your javascript is that the initial First Contentful Paint and First Meaningful Paint times will be much faster.

And, just like the aforementioned features, automatic deferral of scripts (and the building of the combined inline scripts into a single file) is one of the many features that we built into the Pegasaas Accelerator WP plugin for WordPress.

Combining Resources

Okay, so I’m going to be controversial with my take on combining resources.  In 90% of sites, you shouldn’t combine CSS or JavaScript.  This opinion goes against the traditional methodology that you should reduce the number of resources loaded in a page.

The reason that I say you should not combine CSS or should not combine JavaScript into a single resources is four-fold.

Combining Resources Isn’t Needed

At current count, a significant number of websites are served the HTTP2 protocol that automatically multiplexes resources (downloads in parallel).  It is our experience that most WordPress websites are served via HTTP2 — this is likely because WordPress websites tend to be hosted on shared hosting websites, and not legacy web servers that have not been upgraded to run HTTP2.

In essence, it takes about the same amount of time to load one CSS file over HTTP2 as it does to load 20.  So, combining 20 CSS files of 100KB in size actually ends up taking longer (because the filesize is larger) than it does to load 20 (all in parallel).

Granted, if you’re running a web server that does not support HTTP2, then you should consider combining CSS and JavaScript resources.  Or, move to a web server that can provide support for HTTP2.

Combining Resources Slows The Interactivity Of The Page

Believe it or not, having a lot of smaller resources is actually easier on the CPU than parsing one very large resource.  This is critically important for mobile browsers which have slower CPUs.  The reason that combining into a single large resources is not as performant is that long tasks monopolize the main thread that is used to render the page.

Combining Resources Prevents Ability To Lazy Load

You cannot lazy load any of your JavaScript files that are combined with others that cannot be lazy loaded due to dependencies.  If you do decide to lazy load one or more of your JavaScript files, you have to be careful that you’re not including that file into the combined resource.

Combining Resources Prevents The Ability To Effectively Cache Resources

When you combine your resources, typically you have a unique combined JavaScript resource for each page (as many pages in your site will have a unique configuration of JavaScript scripts).  By having a unique JavaScript file for each page.  This prevents the web browser from being able to leverage browser-side caching for static resources for the loading of secondary pages in your website.  If you expect that your user will visit more than one page in your site, it makes sense to leverage browser-side caching.

Ultimately, The Choice Is Yours

All those arguments aside, wee do include the ability to enable combining CSS or JavaScript in our Pegasaas Accelerator WP plugin should you run an older web server or are absolutely convinced that combining resources is best for your website.  But by default, this mechanism is disabled for HTTP2 enabled web servers.

Automate It

So there you have it: what it will take to reduce your web page load time.  Every one of those features (plus many more) are included with the Pegasaas Accelerator WP plugin for WordPress.  .  Pegasaas will help you “rise above the cloud” by reducing your web page load time and getting you a much faster website.  Try it today for free.

 

Credits: Photo by NordWood Themes on Unsplash
Improve Your PageSpeed Score

Improve Your PageSpeed Score

In years past, PageSpeed score was calculated on what techniques were applied to a web page. While ultimately the motivation behind the legacy versions of PageSpeed was to improve page load time, it wasn’t until the release of PageSpeed v5 (and Lighthouse v3) that the PageSpeed metric became truly meaningful.

When PageSpeed Metrics Became Meaningful

It was early on Monday November 12th, 2019 that I received a very urgent set of emails from an early adopter of the Pegasaas Accelerator WP WordPress plugin. I had opted to sleep in an extra hour that day — it wasn’t like there was going to be anything pressing that I had to deal with on what was observed as a national day off in lieu of Remembrance Day which fell on the Sunday.

The subject of those emails was something along the lines of “PageSpeed is telling me that my scores of my pages dropped from 95/100 to 45/100 overnight!” and “This is urgent, what is going on!?”

As it turns out, Google had just released their updated PageSpeed Insights tool which was suddenly based off of the Lighthouse v3 tool. In this new version of Google PageSpeed Insights (GPSI), the “PageSpeed Score” was not derived not from arbitrary specific best practices that were applied to a web page, but rather from a calculation based upon the affected result of how your page loaded.

By that, I mean that your “score” now depended entirely on how the page load and render actually affected the user’s experience. How fast the page first displayed, fully loaded, and how interactive it was, was what the score was based on.

Based on Merit, not on Showing Up

You could have a page that had very little on it, that did not apply much in the way of best practices, but if it loaded and rendered faster than a page that had all the best practices applied, the faster page would score better.

OUTSTANDING!

I was thrilled to learn that Google had finally based its PageSpeed system off of the user experience.

Prior to this release, we were planning on building our own system of analyzing page load time, so that we could truly see what the improvements were that resulted from the Pegasaas Accelerator WP plugin being installed on a site.

So, I was so stoked to learn that the data being returned from the Google API was now including all of the data that I was planning on having to build out myself! It was a late birthday present to me!

Happy Birthday, Now Get To Work

Except, of course, there was that issue of the PageSpeed scores dropping like a stone overnight…

Three weeks later, I had built new capabilities into the Pegasaas system that had pages that were once scoring in the 90’s with GPSI v4, that then plummeted to 25/100, back up to 85/100. By the first week in December, we released Pegasaas Accelerator WP v2.0 which included all of the metrics that I had dreamed of including, and had pages loading even FASTER than they had just one month before.

And let me be clear, these scores that I speak of were the mobile PageSpeed scores. The “desktop” scores were now very easy to attain in the 90’s because desktop browsers were that much faster. But as over 60% of users globally are now using a mobile device to search Google, the “desktop” device has become a fairly insignificant metric to base your PageSpeed scores off of.

New Metrics in a New Interface

Included with the “PageSpeed Score” that is displayed in the interface are six new “metrics”: Time To First Byte, First Contentful Paint, First Meaningful Paint, Speed Index, Time To Interactive, and First CPU Idle.

Time To First Byte

The first, Time To First Byte (TTFB), is the only metric that the PageSpeed score is not directly calculated from. As it is something that the web performance community looks at, we felt we needed to include it.

Pegasaas Accelerator WP improves the Time To First Byte by employing caching of the web page. If your website runs on an Apache web server, we take it a step further by bypassing the WordPress system if a cached web page exists. The result is TTFB times of < 150ms.

First Contentful Paint

I’m not even sure “contentful” is a real word, at least my spell-checker says it isn’t. But essentially, this First Contentful Paint (FCP) is when the content is first painted to the web browser.

This particular metric is weighted as 3/5 for importance when the PageSpeed score is calculated, so pretty important. A fast First Contentful Paint is obtained by deferring all render blocking resources and injecting critical CSS into the page. By not requiring JavaScript or CSS to be loaded before rendering, you can achieve 1-2s render times for a mobile device.

The only thing that keeps the FCP from being low, if you’ve deferred all of your render blocking resources, and you’ve injected critical CSS into your page, is if your page has a lot of HTML elements (DOM nodes) and/or your critical CSS is very large. You need to understand, it takes time to apply all of the CSS rules appropriately to the web browser… even longer on a mobile device.

Of course, Pegasaas Accelerator WP has included deferral of render blocking resources, and automatic detection and injection of critical CSS since version 1.

First Meaningful Paint

Often, this metric is identical to the First Contentful Paint metric. If you have images or fonts that need to load in order to render the page, then this metric can be higher than the First Contentful Paint. Essentially, First Meaningful Paint (FMP) is when the primary content of the page is visible.

Another aspect of a delayed First Meaningful Paint is if the critical CSS is dramatically incomplete which would require the deferred stylesheets to fully load. This would also result in something called the Flash of Unstyled Content (FOUC) which is where you see the page in a jumbled form slowly build and become the page it was designed to be.

Since version Pegasaas Accelerator WP version 2, we have included the stripping of redundant Google Fonts for mobile which helps to reduce the FMP metric on those sites that include a lot of variations of a font. This stripping method uses the “middle of the road” method of removing the non-typical variations for mobile, so the first meaningful paint is as fast as possible.

This is the least important of the five metrics that are used to calculate the PageSpeed score for a web page. This means that it isn’t integral to keep the FMP to the same as the FCP time, however if your FMP is higher than 2.0s, it will begin impact the overall PageSpeed score to some small degree.

First CPU Idle

The second least impacting metric of the five, First CPU Idle (FCI) is when the CPU first becomes idle and is minimally interactive. Arguably, this is possibly one of the more difficult metrics to target as it can be affected by resources that are loading (JS/CSS/images/fonts) or JavaScript that is being parsed and executed.

Generally speaking, if you have any sort of JavaScript that animates sections of your page, you’re going to have a higher FCI metric.

Again, this is a fairly low impact metric, so you can get away with times that are around 3.5s. Ultimately, you don’t want to have the user wait more than 3 seconds for their mobile device to become interactive. If a user tries to scroll becomes the CPU is engaged on making a animation occur, that is a negative affect on the User Experience.

Our plugin offers Lazy Loading of JavaScript resources to help bring down the First CPU Idle metrics, since version 2.3 — if you don’t need it loaded until after a user scrolls, it should be lazy loaded (just like images!).

Time To Interactive

The Time To Interactive (TTI) metric measures how long it takes for the page to become fully interactive. This is basically the more fully observed version of First CPU Idle.

TTI can be difficult to keep low if you have a lot JavaScript and CSS. As Time To Interactive is the most important of the metrics that factor in to your PageSpeed score, every effort should be made to make the page interactive as soon as possible.

One of the methods that have often been used in the past to reduce the Time To Interactive is to combine resources such as JavaScript and CSS. This type of strategy is counter productive, however, as it ends up causing a higher First CPU Idle, and contributes to longer loads times for subsequent load times, as the combined CSS cannot be used on secondary pages.

In addition to it being counter productive for the reasons mentioned above, combining resources is not necessary for most modern web servers that support the HTTP2 that allows for multi-plexing. With multi-plexing, much of your CSS and JavaScript can be loaded in parallel. Combining only serves, for new web servers, to delay the page load.

With Pegasaas Accelerator, we provide the ability to Lazy Load CSS (Deferring Unused CSS) and JavaScript, and image files. These features affect not only the Time To Interactive, but also the Speed Index.

Speed Index

The Speed Index (SI) metric is similar to the “page fully loaded time” that is seen when using tools such as GT Metrix — it is essentially how long it takes the contents of a page to be visibly populated.

This metric is what most developers think of when they’re testing for “page load”. It used to be, before we deferred render blocking resources and injected critical CSS, that we targeted the “page load time” under 3 seconds to be considered a fast loading page. In truth, if your Speed Index is under 2.7 seconds, it is considered 100/100 for that particular metric.

In reality, with modern websites using 10, 20, 30, or more JavaScript files to render a page, it can be very difficult to achieve for a mobile visitor. However, if you know which files can be ‘lazy loaded’ until after the initial page load, then you can utilize the Lazy Loading of JavaScript power feature in Pegasaas Accelerator WP.

And, if the critical CSS snapshot is accurate, you can enable the “Defer Unused CSS” option in the plugin to shave even more time off of the page load.

Web Performance Optimization, Simplified

When I set out to develop the Pegasaas Accelerator WP plugin, it was fueled by my frustration that there were no plugins that put all of the pieces together. There were no plugins that “just did it all” that I could “set it and forget it”. Some would do part of the puzzle, but wouldn’t provide the metrics to show how well my pages were doing.

I was frustrated, because I felt I had to have a second job just monitoring the web performance of my site.

Which is why I built Pegasaas Accelerator WP. Personally, I needed my WordPress websites to load fast… and to load faster than my competition. And I needed whatever was going to do that for me to be simple to operate.

So there you are! Pegasaas Accelerator WP — give it a try and if you like it and feel it is worth a small monthly fee to include a global CDN, more monthly API optimizations, more image optimizations, etc etc etc…. then I’ll keep developing it to provide the most comprehensive automated PageSpeed optimization tool available.