Category: Web Performance Optimization

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