Entity Type: Article

An Article.

WordPress Speed Optimization

WordPress Speed Optimization

If all you had to do was slap a caching plugin into your site to get your site speed up to where it needs to be to be faster than your competition, well, you probably wouldn’t be reading this article.

What It’s All About

You probably realize that in order to rank well in the search engines (search engine, because, really, we all know it’s Google or nothing for search), your website needs to be stinking fast, or at least faster than your competition.

If all other ranking factors were the same, and your competition’s website was faster to load, you’ll encounter the following:

  • your visitors will find your competition first
  • your visitors will stay at your competitions website
  • your bounce rate will be higher than your competition
  • your conversion rate will be lower than your competition

But Why?

Google is all about the role of User Experience when it comes to search engine placement.  If your website keeps your visitors happy, and on site, gives them what they’re looking for and your bounce rate is low for your search engine listing, you’re going to do better than if you have a terrible user experience (bad or irrelevant content, bad design, slow site). Google wants to list sites that are providing value and where the User Experience is excellent.

So, where does website speed play into the “user experience”?

Well, if your website takes to long to load, your visitors may bounce (meaning, they don’t visit more than one web page), not stay long, and likely not convert to paying customers.

How Slow Is Slow?

Consider that for every second of load time, the probability of your visitor bouncing (if they even reach your website) increases by 13%.  That means that by 15 seconds, the probability of the visitor bouncing increases to 105%!!  If they’ve stuck around to actually visit the page, the chances of them visiting a second page are virtually nothing.  It doesn’t matter if you have the best thing since sliced bread, or the widget to save the world, your visitors will bounce from a page that takes 15 seconds to load.

On the flip side, for every second you can make your website faster, studies have found that you can improve your conversion rate by 11%.  So if you’re somehow converting 2% of your visitors with a 10 second load.

So how do you make your WordPress website optimized for speed?

So How Do We Go Faster?

It’s no secret that adding a caching plugin to your WordPress website is one of the first steps you’re told to do when you’re working on your WordPress speed optimization.

But while using a caching plugin may reduce your “time to first byte”, it only affects the time that the page begins to start to load the rest of your resources.

I’ll explain.

How A Page Is Rendered

When your web browser first makes an attempt to view your web page, it has to first load the HTML.  If you’re running a WordPress website, this can take anywhere from 0.5 seconds to 15 seconds or more depending upon the server resources available to you and how many plugins (and what actions those plugins are performing) are installed.  If your website has a slow connection to the database, or you’re on a shared hosting environment with 500 other websites which uses old spindle hard drives (rather than the new solid state drives), the time it takes to generate the HTML that gets served to your visitor can suddenly balloon.

Caching the HTML can reduce the the “time to first byte” from a  painful 15 seconds down to virtually nothing.

However, this is only a small part of entire page load cycle.

Mobile Web Page Load Time

What A Caching Plugin Doesn’t Do

Once the HTML has been received to your browser, the browser then typically requests the CSS stylesheets, JavaScript files, images, and fonts.  Because stylesheets and JavaScript are “render blocking” (meaning, they block the rendering of the page until the final stylesheet and JavaScript file has finished loading), the page doesn’t actually begin rendering for an additional 2-10 seconds.  The time it takes to load those resources depend on how many there are, what type of web server your website is on, how large those resources are, and whether any of those resources are hosted with a third party service.  Often, third party websites resources can take longer to load, as they require an additional DNS lookup.

Once the render-blocking resources are loaded, then the page can begin “painting”.  The terms “first contentful paint” and “first meaningful paint” are used to describe the time it takes to first paint the first bit of content to the page, and then the time it takes to finish the rendering of the most significant part of the page.  The higher these values, the more likely your visitor will bounce.

After the styles are rendered, the JavaScript is parsed and the page re-drawn (if there are any dynamically generated components) then the images are loaded.  When you hear about “fully loaded time” this is when all resources, be they stylesheets, scripts, images or fonts, are all loaded and the page is done it’s load phase.  Additional aspects of the page may be loaded at a later time, however at the “fully loaded time” (which Google PageSpeed Insights refers to as the Speed Index), the CPU typically is done grinding away at getting everything in place.

There is so much going on with just the render phase that plain HTML caching just can’t help with.

This is where we come in.

What We Do

We built Pegasaas Accelerator WP first as a WordPress speed optimization plugin, and  second as a caching plugin.  Yes, it has amazing features as a caching plugin such as auto clearing your cache on a specific schedule globally or on a page by page basis, or manually on a page-by-page basis or globally.   Caching is just one small aspect of making sure the WordPress site is optimized for speed.

But where Pegasaas shines the most is in the optimization of the rendering of the page.

Blazing Fast First Contentful Paint

Pegasaas Accelerator WP automatically defers the loading of your stylesheets at the same time as automatically detecting, generating, and inserting critical above the fold to optimize the critical rendering path.   By doing this, Pegasaas can reduce the First Contentful Paint and First Meaningful Paint down to 1-2 seconds.

Super Low Fully Loaded Time

To keep the Speed Index (fully loaded time) down, Pegasaas automatically applies foreground and background image lazy loading.  It also has the ability to lazy load stylesheets to avoid the “defer unused css” warning in Google PageSpeed Insights.  In addition to deferring unused CSS, Pegasaas can lazy load unnecessary scripts to further improve load time and the time-to-interactive metric.

Automatic Image Optimization

To keep the above-the-fold images loading fast, we also automatically optimize your images for you by first detecting the optimal dimensions, resizing your images, and then compressing them.  Pegasaas can take un-optimized images and resize and compress them down to 2% of their original file size (for example, 3.6MB down to 65KB).

These are just some of the many automatic web performance optimization transformations that are applied to your web page when Pegasaas takes over.

Timeline of a fast Web Page Load

Everything Working In Harmony

Now, there are ways of patching together a few other plugins to do image optimization, lazy loading of foreground images, and deferral of render blocking resources.  However, as I mentioned earlier, Pegasaas was built first as an automated WordPress speed optimization plugin.  It performs hundreds upon hundreds of tiny transformations to your web page, all in harmony, so that your web page ends up loading incredibly fast.

Which is just what Google wants from your web page.

Guaranteed To Work, Support Included

You can try it out for free for 14 days.  You could have your site automatically optimizing in just a few minutes from now.   If you need support (which we don’t think you will, but it’s there nonetheless) we can expertly tune the plugin just for your site as well.  However, for most website, the default plugins settings are all you need to have the plugin getting you an 80, 85, 90+ mobile PageSpeed score.

 

Photo by Fikret tozak on Unsplash

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.

Pegasaas API Upgrade — How (and why) we went from a single-server to a multi-server network.

Pegasaas API Upgrade — How (and why) we went from a single-server to a multi-server network.

Since we switched from the in-plugin method of processing HTML optimizations, to the more powerful and dynamic method of optimizing via a central API in February 2019, the number of monthly page optimizations performed by the Pegasaas API has grown dramatically from about 1500 for the last two weeks of February, to as high as a projected 60,000 per month this month.   Generally, most sites do not re-optimize their entire set of pages monthly, although there are those that rebuild bi-weekly, or even weekly.

Planning for Growth: We’re not in Kansas Anymore, Toto.

It became obvious after April that if growth continued as it had for the previous months, that we were going to need more processing power.  It also became clear that we were seeing failed connections from websites hosted on slow servers that were geographically distant from our API server in Austin, TX, USA — if a website is hosted in the middle of Australia, it will take a little longer for the connection to be made to the API server in the USA.  And because we didn’t want to leave connections open indefinitely, and because we also plan further upgrading our service offerings in the next year, we realized that we needed to develop a system were we had “nodes” deployed across the globe.

It was about that time that we decided to begin planning for the development of a distributed network of API nodes that could accept and process requests.

Building A Network: But wait!  Are those flying monkeys?!

Work began at the beginning of July, and progressed quickly.  Most of the heavy lifting of developing the systems to “spin up” a “node” in any one of 16 AWS data centres across the globe was completed when we received an unexpected communication from our service provider (Hostway) that runs the data centre that our Pegasaas API server exists in.  In this email, Hostway informed us that they were retiring the data centre and would be moving all of our assets to a new  “state-of-the-art” facility on one of two dates.  Sounded pretty good to me until I read how long they planned to have the server offline.

How long?  Six hours.

Yeah, the implications of being offline for more than 10 minutes caused my blood pressure to rise pretty sharp.  Thinking back on it, I realize that to expect no downtime for this type of scenario was impossible, but still… what were we going to do?

Well, the answer came to me shortly thereafter as I realized we would need to employ, in less than a month, our distributed node network — we had planned for a August/September launch anyway, but there was no hard deadline.  Now, there was: August 22nd at 9pm PDT.

Infrastructure Hardening: If I only had a brain, maybe I’d have thought of this scenario.

Please understand, we have nightly backups of our servers (in the event that we had a catastrophic hardware failure), but I had never considered a situation where the server would actually be offline for any extended period of time.  That’s my bad.  I hadn’t been daydreaming about worst case scenarios.  But nevertheless, our infrastructure was not as robust as it probably should have, and could have been.

As an aside, we had also recently learned of some client websites that were running WordPress websites on multiple AWS EC2 servers at once — this actually was a situation that we saw with what we would have considered Enterprise level installations that required redundant servers in the event that one or more servers experienced a failure.  We learned that Pegasaas Accelerator WP v2.x, and the corresponding API, is not capable of deploying optimized assets to multiple servers.  We’ve formulated a plan for this, and it will be a part of the 3rd generation product and API coming later this year.

Having been exposed to the reality that some websites were using multiple redundant servers that could handle a disruption such as a server going offline, we knew that we could handle our own scheduled downtime of our primary server.

I’m happy to say, that August 22nd (yesterday, at the time of this post) has come and gone, and our new multi-server network has performed exceptionally well. In fact, there was no disruption in service at all for the Pegasaas API while our primary server (which actually hosts a number of other websites that we run) was offline.

What We Did: Servers and Databases and DNS, oh my!

What we ended up doing was deploying two identical t2.medium AWS EC2 servers that accessed an Amazon RDS (database).  In fact, we also connected our primary API server to the same database.  While there is a little latency for the primary server to process large amounts of data when accessing the Amazon RDS server, the two Pegasaas API “nodes” had a quick connection as the database was hosted in the same US-West-1 Data Centre.

We used the ns1.com DNS provider that allows for geo-targeted DNS data — while we’re not using this feature at this moment, we will use it when we spin up “nodes” in different geographic regions to cut down on the connection timeouts between the Plugin installed on servers geographically distant from our primary network.  NS1.com allows for multiple IP addresses for a DNS zone record — something we didn’t have with our previous plain vanilla DNS provider.  This means you can have multiple IP addresses listed so that when a connection is requested to “api.pegasaas.io”, that if any of the connections fail, the requesting client (web browser, or plugin installed to a website) will automatically try to connect with the second… or third, IP address.  Automatically.

How It Was Done: Just Follow The Yellow Brick Road, One Step at A Time.

In the days leading up to August 22nd, we tested the system rigorously, first by connecting the prime server to the Amazon RDS, and then adding the first node into the network.  We then briefly shut down the primary server (by way of a reboot) to see if the DNS failover system would work.  It did.

After the first node was working without any issues, we incorporated a second node.  We didn’t know how much traffic a t2.medium node could handle, and we wanted to ensure that there was double redundancy.

And In The End: Behind the Curtain

It was a major lesson in service hardening that I had not, in 17+ years of being responsible for websites and web severs, had to deal with.  I’m happy to say, we have a suuuuuuuper solid API now.

And, with all of these lessons, and the exposure to Amazon Web Services, we’re going to be further developing our data management of optimized resources by employing the use of Amazon S3 Buckets… but that’s a topic for a different day and a different blog post.

Where can you find your Cloudflare API key?

Where can you find your Cloudflare API key?

To ensure the optimized resources are effectively cleared from your site, when your website is leveraging the Cloudflare content delivery network, Pegasaas needs to be able to speak to the Cloudflare system.  To do that, you will need to specify your Cloudflare “Account Email”, as well as your Cloudflare API key.  The API key is like a password, and is used by Pegasaas to instruct the Cloudflare system to perform tasks related to management of the cached resources.

To find your Cloudflare API key, take these steps:

  1. Log in to your Cloudflare account
  2. Choose your site that Pegasaas Accelerator WP is installed to from those listed in your “Home” panel (you may have more than one)
  3. Scroll down and select from the API panel, on the right of the Cloudflare page, “Get your API Key”
    Cloudflare API Key
  4. Scroll down, and VIEW your “Global API Key”.
    Cloudflare Get API Key
  5. Copy the API key that is provided, into the API Key field provided in the Pegasaas Accelerator WP interface.

 

Analytics and Tag Managers and their impact on Web Performance

Analytics and Tag Managers and their impact on Web Performance

In the pursuit of online dominance of your niche market, you may choose to add any number of tracking scripts to your website.  You may even manage these scripts with a tag manager such as Google Tag Manager.   The use of such scripts have the possibility of both great benefits and detriments.

The Benefits of Using Tracking Scripts

Tracking scripts, such as Google Analytics, Yandex, Hotjar, Bing Ads, Facebook Pixel, or Kiss Metrics — just to name a few — can help a business operator or marketing agency determine where customers are coming from, where they are going to, what they are clicking on, and where their attention is or is not focused on.  Such information can be invaluable to determine viability of business initiatives such as money spent on pay-per-click or other advertisement, or whether visitors are flowing through your sales funnels or dropping off at a particular point.

By using Tag Managers, you can add, remove, or modify scripts that are being served for an entire site, through a web interface.  Using a tag manager can save, the person responsible for managing the website, a considerable amount of time.  In the age of GDPR (General Data Protection Regulations), you may be required to notify your visitors of your methods of collecting data, and this may also be done through logic embedded with a tag manager.

In short, you can learn an incredible amount of invaluable information from analytics and tracking services, and you can save a lot of time managing those scripts by using a tag manager.

What Happens In the Page

When you add any script to a web page that must run as soon as possible in order to do what it was designed to do, the script must be loaded, parsed, and then executed quickly.  Analytic services are often very processor intensive as they are monitoring clicks, mouse moves, time on page, and a host of other actions.

However, every script that runs in your web page will cause the “First CPU Idle” time to be drawn out.  This in turn will cause the “Time To Interactive” metric to be extended as well.  If there is a tag manager involved, it may take additional time to inject the scripts into the page, which increases the “Speed Index” metric.  All of these metrics contribute to your PageSpeed score.  The higher the First CPU Idle, Time to Interactive, and Speed Index, the lower your PageSpeed score will be.

When It Affects Web Performance

Desktop devices, compared to mobile devices, have fast CPU processing, and fast connections to the internet.  The impact by using one, two, or even five analytics scripts, for desktop browsers is, almost undetectable.

On mobile devices, however, each of these tracking or tag manager scripts can cost you anywhere from one to four PageSpeed points depending upon what else you have going on in your web page.   If you are using Hotjar, Analytics, Facebook Pixel, and Bing Ads tracking, you could be experiencing a mobile web performance hit of up to 15 PageSpeed points.

But What If Your Visitors Are Mostly Using Desktop Devices

While you may not experience increased bounce rates (overall) if your visitors are predominantly desktop, we now live in a world of the Google mobile-first search index.  According to reports from 2016, roughly 60% of Google’s global searches were performed on mobile devices.   This is why in July of 2019, Google rolled out their mobile-first search index.

The mobile-first search index will grade your content and your speed based upon how mobile devices load and render your web pages.  Tests show that there is a direct correlation to your PageSpeed score and your ranking.  This means that if your website is slow on a mobile device, or that only shows thin content to a mobile visitor, the likelihood of you ranking better than a competitors site, which is fast and has rich content visible to mobile devices, is diminished.

As far as ranking in Google is concerned, you need to be focused first and foremost on how your site renders and loads for a mobile device.

In addition, a low PageSpeed score contributes to a low “quality” score when you are setting up pay-per-click in Google Ads.  When you have a low quality score, your cost-per-click will go up.

If your site is one of those that was poorly constructed with a lot of bloat, you may already be struggling to attain a high mobile PageSpeed score.  If you include heavy CPU intensive analytics scripts into your web pages, you could drag that score down even further.  Remember, while a desktop PC may have a fast CPU, mobile CPUs are, relatively speaking, much slower.

Putting It Into Perspective And Making An Informed Decision

So, as a website operator, you have to make a choice.  How much tracking information do you need?  Do you need to have heat-maps?  Do you need to have conversion tracking?  Do you need to know when someone is leaving your sales funnels?  Or can you get away with fewer tracking scripts?

You may answer that you need all of your analytic scripts.  And that’s ok!  Just understand that they will provide a performance hit, which may impact your probability to be found above your competitors in organic search and your quality score for your pay-per-click campaign.

Do I need another caching plugin when using Pegasaas Accelerator WP?

Do I need another caching plugin when using Pegasaas Accelerator WP?

No, you do not need another caching plugin when you have Pegasaas Accelerator WP installed.

In fact, we recommend disabling any existing optimization plugins such as those responsible for:

  • Caching
  • Minification
  • Deferral of CSS / JavasScript
  • Image Optimization
  • Lazy Loading

Pegasaas Accelerator WP fully optimizes your WordPress website with over 20+ web performance methods and and mechanisms, all in harmony.  If you choose to leave other optimization plugins installed in parallel to Pegasaas Accelerator WP, it may cause a conflict with our functionality that was designed to work together.

Are optimizations performed on the page when logged in to WordPress as a user/administrator?

Are optimizations performed on the page when logged in to WordPress as a user/administrator?

Optimizations are not applied to the page when you are logged in to WordPress.  As optimizations are performed through the Pegasaas API and stored in the plugin cache, on-the-fly optimizations are not performed as the result would be a much longer load time.

Examples of when optimizations are currently not performed:

  • when logged in to WordPress
  • when an e-commerce cookie is present (you have items in your cart)
  • when a query string is appended to the URL (https://www.yourwebsite.com/?argument=value)

There are plans to include Edge Side Includes which would allow for the use of non-cached regions with previously optimized pages in a future version.