Entity Type: Article

An Article.

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.


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.

If my mobile PageSpeed score is less than 90, what should I do?

If my mobile PageSpeed score is less than 90, what should I do?

The Big Picture

While everything should be done to make a website load as fast as possible, if you have a PageSpeed score of 90/100, you are roughly in the 93rd percentile (93% of websites are slower than yours, and only 7% are faster) based on the information from Google where they state that a score of 100/100 represents the 98th percentile, and 50/100 represents the 75th percentile.

While you may not be considered in the “fast” category, a score of 80/100 still represents the 88th percentile — where you are faster than 88% of other websites.

One Page at a Time

If getting a score of 90/100 or higher is critical to you, and you have already had Pegasaas Accelerator WP optimize your pages, you should consider either targeting the specific pages that are drawing your average score down, or consider deactivating global plugins which may be causing a long load time.

Common Issue

One common element that can cause mobile load times to be higher and subsequent PageSpeed scores to be lower, is the use of third party “analytics” scripts such as “Google Analytics”, “Yandex”, or “Facebook Pixel”.  Also, the use of “tag managers” (such as “Google Tag Manager”) can cause even further load time, as the tag manager must be loaded first, parsed, and then executed.  Once the tag manager has been executed, subsequent analytics scripts are then injected, loaded, parsed and executed accordingly.  When these analytic and tag manager scripts are used in a web page, they can cause the page load time to be increase by 1-5 (or more) seconds.  If load time is important, you should consider reducing the amount of analytics scripts that are used with your site.

Additional Analysis

Beyond that, the Pegasaas Accelerator WP web performance analysis team can be hired to specifically advise on how getting a faster load time can be accomplished.  If you’re interested in hiring the web performance analysis team, please contact them via the Pegasaas.com contact page.

JavaScript Execution Time: what if I am still getting this warning?

JavaScript Execution Time: what if I am still getting this warning?

What is JavaScript execution time?

The Google Developers website covers this topic in great detail, but in short, if you’re still getting this warning, it means you have too much JavaScript being loaded, parsed, and executed in your pages.

Can Pegasaas Accelerator WP handle this?

If you have Pegasaas Accelerator WP installed, minification and deferral of JavaScript, as is recommended by Google, is already implemented.

Resolve the Root Problem

If you already have Pegasaas Accelerator WP installed, you can try to address the root problem of excessive JavaScript execution time by disabling necessary plugins, as many plugins add multiple JavaScript files which all contribute to the load, parse and execution time of your web page.

A Possible Manual Solution Advanced

You could also attempt to identify any JavaScript files that may not be needed for initial page load.  For example, if there are plugins in your page which handle a click action for a component that is below-the-fold, then you could lazy load these script files.  To lazy load a script, you can add the file name of the JavaScript resource to the Settings > Lazy Loading > Lazy Load Scripts panel.  Any .js file that you add in this panel will not be loaded, parsed, or executed in the page until the user has begun to scroll down through the page.

Minimize Main-Thread Work: what if I am still getting this warning?

Minimize Main-Thread Work: what if I am still getting this warning?

What is going on here?

This warning indicates that either your DOM (web page) is very large and you have:

  • lots of styles being applied to your page
  • lots of JavaScript that being parsed and executed
  • lots of web fonts — many of which could be web font icon sets

Each of those reasons individually or combined can contributed to the length of the main-thread work.

How to Address

If you are still getting this warning after Pegasaas Accelerator WP has optimized your pages, then it means that there are intrinsic features of your page that cannot be optimized further but are still more than a fast page would contain.

The only solution to this would be to remove plugins or components from your pages that may be contributing to either:

  • excessive style rendering
  • excessive javascript parsing
  • excessive font loading