Your website’s performance is a critical element for increasing traffic, generating leads and closing potential sales. Let’s answer a few questions about your website’s performance.

What is Website Performance?

When we talk about a website’s performance, what we’re really asking is … “How good is the code that is running the site?” or “How well is this website built?”

  • Are the pages fast loading?
  • Have the images and content been optimized?
  • Have you enabled browser caching?
  • Have you optimized the HTML, JS and CSS?

These technical issues are designed for the sole purpose of improving the delivery of your website.

Why is Speed Important?

Speed matters to EVERYONE.

Remember, we have two different audiences for our website: web site visitors (prospects) AND search engines.

Search Engines, like Google, use page load speeds as an indicator for ranking search results (especially on mobile). Why?

Faster pages = better user experience = more ad revenue for the Search Engine

A 1-second delay in page response can result in a 7% reduction in conversions, according to Kissmetrics.

In terms of website visitors, research has shown for years that even slight increases in page load times can have catastrophic effects on your conversion rates.

Here’s a great infographic* from the people @ Kissmetrics. (* the data is already a few years old so think of this as a BEST CASE SCENARIO. Attention spans are even shorter now)

How to Improve Your Website Speed

During our Page Performance tests we actually look at 13 different tests. Here is how to identify and improve each of the issues our Page Performance tests uncovered:

Page Size: Page size refers to the actual size of the files that must be downloaded in order to fully render your website. Large page size is common with sites that are redesigned from an old site, using a poorly designed template or with users who added multiple plugins.

  • Keep page size under 3 MB for best results.
  • Identify the elements being loaded by the page. Chances are good that many of the resources being loaded may not be necessary for your site to function.

Page Requests: These are the number of requests that are made to grab the resources necessary to build your website. This includes images, CSS, Javascript, etc. This one is pretty self-explanatory: More Requests = Increased Page Load Time

  • Reduce excessive requests by combining processes or eliminating them where possible.
  • Completely remove unused plugins

Note: We see this a LOT with WordPress site because most WordPress plugins will have their own stylesheets, etc. So if you’ve got many plugins ( particularly if there are more than 10), you have to trim these down. Don’t just deactivate unused plugins, completely remove them from your site.

Page Speed: The actual time it takes to load your web page. It makes sense here with our ever-shrinking attention spans – faster page load times are better. Professional websites should load in under 5 seconds, anything longer and it will begin to impact your conversions.

  • Reduce excessive requests by combining processes or eliminating them where possible.
  • Completely remove unused plugins.

Avoided Landing Page Redirects: This rule is triggered when there is more than one redirect present on your landing page.

Let me give you an example:
Many people have an automatic redirect on their website that will take all non-www traffic and redirect it to a url with a www in it.

If we don’t do this the search engines may ding us because they will see the same content from two different pages and thinking that we are trying to scam them.

  • http://yourwebsite.com
  • http://www.yourwebsite.com

The search engines see these as two separate URL’s

Now, if we want to make sure everybody ALSO goes to the secure pages on our site we would need one more redirect that would do the following:

  • http://yourwebsite.com
  • http://www.yourwebsite.com
  • https://www.yourwebsite.com

So here we have two redirects

  • Redirect #1 from “non-www” to “www”
  • Redirect #2 from “www” to “https://www”

That’s bad. Because the individual redirects each take processing time.

The better solution would be to perform both redirects in one step (from non-www all the way to https://www) OR you could just use the domain itself (no www) and a nice responsive design and no redirects will be necessary.

Eliminated Render Blocking Code: The code on your page loads in a web browser in a particular order. This error means that you have elements on your page that are slowing down the page from being rendered (displayed) – think about it like a code “traffic jam”.

The solution here is easy – you just have to move the elements that are slow to load further down in the page code. Ideally you would want the slow loading code to be called AFTER the last “above-the-fold” content on your page is rendered. This works for Javascript (Js) as well as Cascading Style Sheets (CSS)

  • Enabled Gzip Compression: All modern browsers support gzip compression for all HTTP requests. By enabling gzip compression you can reduce the size of the files that are transferred by 90% or more which cuts your page load time for those particular resources by 90%.

If your site isn’t gzip compression enabled – you have a few options.

  1. WordPress Plugin – If you are running WordPress, almost any caching plugin will have that functionality built in. Click a few buttons and you’re done. Some options include: WP Fastest Cache (https://wordpress.org/plugins/wp-fastest-cache/) or Check and Enable GZIP Compression (https://wordpress.org/plugins/check-and-enable-gzip-compression/).
  2. .htaccess File – You can enable compression on Apache web servers by adding the following code to your .htaccess file.

# Compress HTML, CSS, JavaScript, Text, XML and fonts
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml

# Remove browser bugs (only needed for really old browsers)
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent

Leverage Browser Caching: When a web browser “caches” an image – it means that the web browser actually copies that image to your local hard drive on your computer. Then, the next time you need to see that image (maybe on the next page), the browser is smart enough to pull the image from your local computer INSTEAD of downloading a new copy from the website. They do this because it’s MUCH faster to pull an image from your local computer than downloading fresh images all the time. We want to use caching as much as possible.

This rule is triggered in two ways:

  1. When the response from your web servers DOES NOT include caching headers.
  2. If the resources specified are only

If you are not currently using browser caching, or if your cache only keeps images for a longer period of time, look into one of the browser caching plugins previously mentioned. They will usually cover many different areas of this report with one plugin.

Minified Resources (CSS, HTML, JS): When we write code, we use formatting and comments to help keep the code straight and to let other developers know what is happening in the page. All of these comments, extra spaces and tab characters take up space. Extra space results in larger page sizes and longer page load times. This is why we want to minify as much as possible.

Minification is the process of removing extra formatting, characters, and comments so that the code still operates as originally intended, but is as small and efficient as possible.

  • If you are running WordPress, there are plugins that will do this for you.
  • You may need to make the changes by hand.

If you aren’t comfortable making site edits – please consult a professional.

Optimized Images: Images account for the vast majority of bytes downloaded on a page. As such, optimizing images can be one of the quickest way to get massive shifts in your page load times.

When we optimize an image, we’re trying to get the best acceptable image quality with the smallest file size.

Generally speaking, as the file size shrinks, so does the quality. Image optimization helps us balance between file size, resolution and image quality. These are some ways you can optimize your images:

  • Try to use PNG or GIF images – they are lossless so the quality of the image won’t be affected as it is optimized. JPEG, on the other hand, is a lossy format so try to keep image quality around 85.
  • Use a tool like http://Kraken.io to optimize.

Prioritized Visible Content: This rule is triggered when your website has to “wait” to load content that is to be displayed above the fold. This “wait” time requires extra trips between your server and the user’s browser and on mobile networks – these delays can be even larger.

  • Optimize the “above the fold” content as mentioned in the section on “Eliminate Render Blocking Code”.

Reduced Server Response Time: The server response time is the time between when your web server gets a request to display a page and when that page is actually beginning to be displayed. Ultimately we’d like to see that number under 200 ms (that’s 0.2 seconds).

If you are having performance issues with your website we have a three step process that we need to use to fix it.

  1. Gather and review data: there are a lot of places where the site can be slowing down so the first thing we need to do is gather some performance data and review it to see where the largest performance bottlenecks are happening
  2. Identify and fix – identify the largest bottlenecks and repair those first working your way down the list.
    • Think about the 80/20 rule. The 80/20 rule states that 80% of your website value comes from 20% of the content. Choose to repair the 20% that matters. Some data “bottlenecks” are so minor that they aren’t worth the time needed to implement the fix.
  • Monitor – Keep an eye on the site, especially after updates, to make sure your site performance is staying in that < 200ms range.

Slow server response times can be due to: slow application logic, slow database queries, slow routing, frameworks, libraries, etc.

If this seems daunting, please reach out to a professional web developer to help you.

Other factors to consider

The other issue we need to consider is whether your site load time is due to a slow or poorly performing web hosting server. If your website has been optimized, but you are sitting on an old shared server with many other websites, your site performance will take the hit – especially if you run a site that is resource heavy (lots of images, pages and downloads).

When it comes to web hosting, you really do get what you pay for. Hosting packages can run from $1.95/mo and up. My suggestion is to avoid “lower end” shared hosting sites (Bluehost, Hostgator, etc).

Instead spend a few extra bucks on some mid-tier, managed hosting. Black Dog Studios (our development partner) provides hosting that includes backups, monitoring AND security updates. WP Engine is a great source as well (starting @ $35/mo.).


Petsitter 365
3243 Ridgeview Drive
El Dorado Hills, CA 95762
Phone: (916) 608-2151