TechGirlKB

Performance | Scalability | WordPress | Linux | Insights

Performance

How to Choose the Best CDN for Your Site

What is a CDN?

Before we breach the topic of choosing the best CDN for your site, first we should consider: what is a CDN? The term “CDN” stands for “Content Delivery Network.” It’s a network of servers located all over the world. When used on your site, CDN helps distribute your content across these servers. This means users around the world will receive your content faster!

Full Site vs. Static Assets

There are two main ways CDN is used on websites: full-site CDN, or serving only static assets. The static assets are your site’s images, CSS files, fonts, and javascript. Since most CDN providers charge based on bandwidth, generally full-site CDN will be more expensive. If you choose to use a full-site CDN, the layers of CDN cache will serve as a web server in front of your origin server. And this means your origin server would be used for only uncached requests on your website. While this would help offload a large amount of traffic from your origin server, it also means your site is hosted across many servers worldwide. So if one CDN server goes down, the rest of the world could still see your site.

If full-site CDN isn’t an option or isn’t ideal for your site, you can still use CDN to host the images and other static content of your site. This option still helps your site load faster for users worldwide, and will likely be less expensive than using full-site CDN. With CDN serving static assets, you should still use a proxy cache like Varnish on your origin server. This will help your site’s performance and lighten the load on your server.

choosing the best cdn

CDN Comparison

There are a number of studies released comparing different CDNs, but in my mind there are a few key metrics to focus on: pricing, cacheability, number of web nodes, SSL support, and whether they offer full-site vs. only static resources. Both MaxCDN and Stratusly published similar reports on these factors in 2016. Below are the comparisons from Stratusly, who added more factors to consider:

Who supports full-site CDN?

Akamai, Fastly, Amazon CloudFront, and Verizon (formerly EdgeCast) offer static and dynamic caching options. These setups typically require pointing the nameservers from your DNS provider to them. This is known as a reverse-proxy. Fastly in particular supports “event-driven content” which they consider to be neither dynamic or static. This allows them to cache more effectively.

Cloudflare and MaxCDN (now StackPath) do not offer full-site CDN.

Who has the most web nodes worldwide?

Akamai is the clear leader here by far. They offer 2700 web nodes worldwide, while the closest competitor (CloudFlare) has 76. Akamai also isn’t able to provide a specific range of IPs if requested. The IPs in use are constantly changing. This makes it incredibly difficult for any one source to target them with a DDOS.

Who is the least expensive?

This is a more difficult question to answer directly. Some pricing models vary based on the amount of traffic, and some are flat-rate. MaxCDN made this visual representation of how Amazon’s pricing model compares to theirs:

And, here’s the graphic the Stratusly team made to compare the three whose pricing varies on bandwidth:

The pricing tends to look pretty similar in the beginning, until you look at enterprise volumes of traffic. If you look at high volumes of traffic then MaxCDN looks great, but also consider that they do not offer full-site CDN.

Who has the best support?

Of the six competitors we’re comparing, only two don’t include Free 24/7 Support. CloudFlare offers phone, chat, and email support 24/7 for Enterprise-level accounts, but only email support for the rest of their plans. For Amazon, they offer a wide library of online support guides and forums, but live support is not available unless you choose one of their Business or Premium Support plans.

Who supports SSL?

All the competitors offer “Shared SSL,” which is a way of saying they will secure the CDN URL they provide you. For example, on MaxCDN they use subdomains of the same root: somezone.company.netdna-cdn.com. You’re able to enable the “Shared SSL” to secure this URL. However, many companies will want to use a Dedicated SSL (SNI) based on a Custom CDN URL of their choosing. Amazon, CloudFlare, and MaxCDN offers these options. None of these, however, support HTTP/2 (a faster version of HTTP). MaxCDN is closer since they offer SPDY support.

Who is the fastest?

All the competitors offer differing metrics here, claiming to be the fastest. These metrics may mean nothing to you though, depending on your options, your geographic location, and the location of your users. I’d recommend using CDNPerf to compare usability and speed worldwide. This comparison spans 24 CDN providers and compares worldwide, specific regions, or specific countries to help you make the right decision. You can also use their “compare CDN” tool to view performance graphs.

Conclusion

So which is the best CDN for you? It highly depends on your company’s needs for CDN. Be sure to consider all the factors before making your decision. Compare performance, pricing, features, and support before deciding.

Are there other features worth considering when picking a CDN provider? Do you have other thoughts about CDN? Feel free to let me know in the comments or by contacting me.

 

How To: Configure Varnish for Responsive Sites

Scalability vs Responsive Sites

A major part of performance with sites on any platform is ensuring that your website is highly cacheable. By caching pages to serve as static files to repeat users, this offloads a lot of server processing power. Without cache, your web server would have to re-process the code to generate your page. Not only does this make more work for your server, it could slow down the response time for your site.

A challenge developers face is how to cache their sites heavily, while still adapting to mobile devices. With Google PageSpeed’s score hinging on mobile compatibility, many themes in WordPress are adapting to offer responsive options. Chances are you’re wanting a different, mobile-friendly version of your site to show to your smartphone users. With page cache, your user sees whatever version was requested the last time the page was stored in cache. This equates to a poor experience for your users.

X-Device Cache Groups

So how do you handle this scenario? Difference circumstances require two different versions of the site. You can do this by adding an “X-Device Group” header based on the HTTP User Agent the request came from. This allows you to detect devices in Varnish. This way, any device you designate as “mobile” gets cached in a mobile group. At the same time, desktop users are cached in a separate cache group. So this solves our problem! A mobile user receives the mobile site. A desktop user receives the desktop site.

Example Config

So how do you detect devices in Varnish? Here’s an example setup:

 

# Cache different devices in different cache groups so they're served the right version
if ( req.http.User-Agent ~ "(?i)(tablet|ipad|playbook|silk)|(android(?!.*mobile))" ) {
# Cache tablet devices in the same group - it's possible this is different than smartphones for some sites
set req.http.X-Device = "tablet";
}
elsif ( req.http.User-Agent ~ "(?i)
Mobile|iP(hone|od)|Android|BlackBerry|IEMobile|Kindle|NetFront|Silk-Accelerated|(hpw|web)OS|Fennec|Minimo|Opera M(obi|ini)|Blazer|Dolfin|Dolphin|Skyfire|Zune" ) {
# Cache smartphones together. The mobile user-agents receive a mobile version with a responsive theme
set req.http.X-Device = "smartphone";
}
else {
# Cache everything else together. We assume anything that doesn't fit into the above regex is a regular desktop user.
set req.http.X-Device = "regular";
}

 

This snippet says to add a X-Device header to each of these device groups. It allows Varnish to cache the devices separately. You can set the header to whatever you prefer. Some prefer something more like X-Cache-Bucket, or X-Cache-Group (which WP Engine uses). If you’re curious how I came to this setup and these particular user-agents, I grabbed these from a pretty thoughtful list. And, Varnish published a very helpful guide on device detection that I snagged to get started.

When you detect devices in Varnish caching groups like this, it allows you to take full advantage of page caching, while still maintaining responsive behavior. That’s a win you can take to the bank! Using more cached pages equates to faster website load times.

Apache or Nginx: The Web Server Showdown

Whether to use Apache or Nginx in your server stack is a decade-old question. While both web servers are versatile and open-source, both offer some pros and cons worth considering. Below I’ll break down some of the key differences between the two.

Architecture

One of the first aspects to consider is the way each web server handles requests. On Apache, there are several “multi-processing model” options to choose from. The most common is called “prefork” – in this model, there is a parent Apache process, with multiple “child” processes. With each new request that comes to the site, it opens a new “child” process. This allows your server to kill child processes in the form of individual requests, rather than having to kill the entire Apache service.

source: zope.org

With Nginx, the master process exists with any number of “worker” processes. However, the largest difference comes in that each “worker” can handle multiple (read: thousands) of page/resource requests at a time, without having to engage the other worker processes. This frees up the server resources that these worker processes would have used, to allow other services to use the Memory and CPU more dynamically. Nginx’s architecture allows the server to process high amounts of traffic while still leaving Memory unused, compared to Apache’s single-request-per-thread method.

Source: www.thegeekstuff.com

Compatibility

When Apache was built in 1995, it was an early success. Developers chose this web server model because of its flexibility and wide library of dynamically-loaded modules to extend its capabilities. By a year in, Apache dominated the web server markets by far. Because of its wide adoption rate, Apache documentation is vast. Many other software models integrate with and support Apache as a result.

Igor Sysoev originally developed Nginx in 2004 to be a web server to be used in combination with Apache. It was launched as a solution for sites which needed to serve thousands of simultaneous requests, which was a new horizon for the world wide web. As Apache’s adoption grew steadily, more modules extending its capabilities were released. When developers realized how lightweight the architecture ran on their hardware, it was an easy choice to begin using Nginx for static and dynamic requests.

As of today, Apache still holds about 50% market share of web servers, while Nginx holds about 35%.

Performance

When considering performance for Apache or Nginx, two main categories exist: static files, and dynamic content. Static files are files which don’t have to be regenerated when requested: images, css, fonts, and javascript. When your code constructs a page to be served, the content is dynamic. Other factors to consider here are: concurrent users, Memory used, transfer rate, and wait time.

In a base comparison of static files, Nginx is about twice as fast, and uses about 25% less memory:

Source: www.speedemy.com
Source: www.speedemy.com

And the same tester found that with dynamic requests, the web servers returned the responses in the exact same amount of time, when serving 16 concurrent requests:

Source: www.speedemy.com

However, remember the other aspects: what was the transfer rate? Do these results change with the number of concurrent users? Below is a comparison published by The Organic Agency:

Source: theorganicagency.com

You can see as the concurrent dynamic requests increase, so does the Apache response time. Nginx by contrast does show a load time increase as the concurrent users increase, but not nearly as much as Apache. Also consider the “failed requests” column which begins at about 25 concurrent users with Apache. Remember the architecture differences in how the servers handle multiple requests? This test is a clear indication of why Nginx is the model of choice for high-traffic environments.

Why not both?

Having trouble deciding whether you should use Apache or Nginx? Need versatility AND agility? No problem. There’s no reason you can’t use both web servers in your server stack. One common way to use both together is to use Nginx as a front-end server, and Apache as a back-end worker. This setup works because the performance disparity in the services is less noticeable for dynamic requests.

Using both servers allows Nginx to act as a “traffic director,” handling all requests initially. If the request is static, Nginx simply serves the file as-is. If the request is dynamic, Nginx uses a proxy_pass to send the request to the Apache web server. Apache processes the PHP and queries to generate the webpage, and sends it back up to Nginx to serve to your site’s visitor. If you’re looking to set this up on your own, check out Digital Ocean’s documentation on the subject.

 

 

How To: Debug WordPress with Query Monitor

What is Query Monitor?

Query Monitor is a plugin developed by one of the core contributors of WordPress, John Blackbourn. It is branded as a debugging tool for developers, and is widely used in the WordPress community. In short, it watches every WordPress transaction happening on the site when the current page is requested, to provide detailed analytics.

Why use Query Monitor?

There are a few specific scenarios in which Query Monitor is useful:

  • Your site has a high TTFB (Time to First Byte) on uncached views to the page, and you’ve narrowed the issue down to slow queries. Queries are used to construct pages from PHP and WordPress when requested, so if they are unoptimized, they can easily lead to high TTFB.
  • If queries are not being run when they should be, or if queries are returning incorrect results
  • You are experiencing wp-admin area slowness and turning off Object Caching helps the speed. Since Object Caching will cache repeated query results and transients, this helps narrow down the issue to the queries the pages are running.

When using Query Monitor, the most important parts to focus on will be the total execution time of the queries, how many/which ones are served from cache, and which queries are taking the longest amount of time. When Query Monitor is active, it is an option in your WordPress Admin bar. If you click the options from this menu, it will scroll to the bottom of the page. Here you will see the full Query Monitor analysis.

What else can it do?

Query Monitor not only monitors the queries running from your site! It also checks:

  • Which “caller” or function/hook is calling the query
  • Gives a trace of which piece of code is calling it
  • Gives a trace of any dependencies and conditionals being met by queries executed on the page
  • Provides a breakdown of how much time it took for all queries to run
  • How much Memory the page used in being generated
  • The percentage of queries that were served from Object Cache.
  • Which scripts are being run, their position on the page and a trace of which files the scripts are triggered from
  • It also detects any PHP Warnings or Errors generated by the page
  • Gives a report of the server the site is running on:
    • PHP version
    • Max_execution_time
    • Memory allotted to WordPress
    • Database being used
    • query_cache_limit (Object Cache)
    • Debugging information

All this data can be extremely helpful to developers looking to optimize their sites!

On top of the extra data it generates, it can be run on the front end without being logged in by setting a specific cookie (this setting is available at the bottom of the report when logged in initially). So in addition to debugging, this information can also help developers understand what conditionals and hooks their own code should hook into, to function properly.

Caveats

There are also some caveats to understand when using Query Monitor on some hosts and environments. These are some common errors to look out for:

  • Query cache: Query Monitor is checking to see if “mysql_query_cache” is being used. WP Engine and some other hosts use a separate service for query caching, called Object Cache. As a result, some of the information may lead you to believe that queries are not being cached, when in fact they are (as long as Object Cache is enabled). The cached percentage at the top of the report will still report this accurately.
  • Query Monitor was unable to symlink its db.php file into place: This error means that the Query Monitor is trying to symlink its own db.php file within its plugin directory to wp-content/db.php. Many webhosts will already have the db.php file in the wp-content directory, so often times this is a red herring.
  • Query Monitor on clustered environments: On clusters and redundant environments with multiple web servers, the requests that Query Monitor is tracking are run from the web servers of the cluster. However, in these environments MySQL is usually only run in READ only mode there. MySQL passes all write operations to the database master server. This conflicts with the code of Query Monitor, so it doesn’t work properly on these environments. In these cases, making a copy of your site to a single-server environment to test is best practice.

Making Sense of Google PageSpeed Scores

What is Google PageSpeed Insights?

If you’ve invested some time into making sure your site is performing well with your users, you’ve likely used the Google PageSpeed Insights tester to see how your site stacks up. This tool measures your site against a series of metrics and standards that it uses to help rank sites internet-wide. And, if you’re one of the many users of Google’s Adsense ads, this score directly affects the quality of the ads your site gets.

Unfortunately, Google PageSpeed Insights doesn’t get very verbose about why it ranked your site the way it did. And the suggestions can be hard to interpret if you’re not used to SEO and optimization terms. Not to worry, I’m here to break it down for you!

Avoid landing page redirects

This recommendation is pretty simple. It just means don’t redirect your home page to another page, either for desktop or mobile users. So for example, using a separate domain like “m.mysite.com” for mobile requests is actually less beneficial for SEO and less satisfying for users. Keep in mind with WordPress, most themes are automatically “responsive.” This means they already have built-in mobile support, without having to have an entirely separate site or domain for these users.

Also remember to check your site’s home page when testing with Google PageSpeed Insights. If your domain in the URL bar is “https://mysite.com/” then be sure to test that exact URL. Be sure you use the proper http:// or https:// version, and the correct “www” or “non-www” version.

Leverage browser caching

If Google PageSpeed Insights recommends this to you, be sure you check the resource it’s referencing. Is this resource called from your domain? Or is the resource called from another site? Some common examples are Google fonts, Google analytics tracking, or external API calls. If the resource is called from your own site, this means the request did not contain a header that said the web browser should cache that file or page. This means visitors to your site are having to request a new version from the server every time they visit the page. It’s best practice to include a “Cache-Control” header on the site that looks like this:

If you host with WP Engine, their platform configures page and static file caching for you automatically, so you don’t have to worry about adding these headers. Using a page caching plugin like W3 Total Cache or WP Super Cache will help you configure these headers if you don’t have a web host that configures this automatically.

When the resources showing in the details are not loading from your site’s URL, this score can be trickier to improve. However, the plugin Above the Fold Optimization has a setting that might help, called “External resource proxy” which will proxy those external resources to load from your own domain, and add the “Cache-Control” header.

Enable compression

Enabling compression is generally referring to gzip compression, which is a method of HTTP compression. For a comprehensive look at what gzip is and how it works, check out Torque’s handy guide. On WP Engine they configure this for you already at the server level. However, for other hosts you may have to either manually configure this in the .htaccess file, or use a plugin.W3 Total Cache offers “HTTP compression” which helps configure this for you in the .htaccess file. You can also use a plugin more specifically made for this task, like Check and Enable GZIP Compression.

Minify HTML, CSS, and/or Javascript

These warnings will show up if your CSS, Javascript, or HTML files referenced by your home page are not “minified.” Minification is the process of compressing and combining these files by taking out extra whitespace, comments, and formatting that might be adding to the time it takes your web browser to parse the response. The Autoptimize and BWP Minify plugins are both well-known plugins that specialize in minifying these assets on your site.

Eliminate render-blocking JavaScript and CSS in above-the-fold content

This can be one of the most confusing messages to receive when testing your site. To understand this message, you first have to understand what Above the Fold content is, and what would be considered “render blocking” JavaScript. In short, “Above the Fold” refers to what your user can see on their visible browser window (without scrolling down). It’s a legacy term that stems from the days of newspapers, where companies would have to strategically plan what would show above the literal fold of the newspaper.

As for “render blocking,” this is referring to JavaScript and CSS files that are being required to load before the site can start showing content. Until these assets are downloaded and processed by your web browser, you’ll see a blank white page. These assets are literally blocking your users from seeing your site’s content faster! If you use a tool like WebPageTest you can get a more clear view of this in action:

So how do you fix “render blocking” assets? You can use Above the Fold Optimization for this as well. The plugin has an option to “extract full CSS,” which you can then enter into a Critical CSS extractor to find what really needs to load before the page can render. The remaining assets can be deferred to the footer using the plugin’s settings!

Prioritize visible content

This warning goes hand-in-hand with the “Above the Fold” and “Render Blocking” warnings above. It just means you should only load Above the Fold content before the page render, and nothing more. You can use a Lazy Loading plugin to help with this, or Above the Fold Optimization has a setting for this as well.

Optimize images

You’ll see this warning if your site’s images have the potential to be “losslessly” compressed. This means eliminating extra metadata associated with those images, and compressing the image size without sacrificing image quality. Two of the most popular plugins for this are WP Smush, and EWWW Image Optimizer Cloud. Usually image compression plugins will have at least a small cost to perform the optimization. If you’re not wild on the idea of optimizing your images, you can alternatively compress the images locally and re-upload them.

Reduce server response time

Google PageSpeed insights will register this warning if your “Time to First Byte” is registering at .3 seconds or higher. Time to First Byte can be a confusing metric to understand! But most often, this comes down to optimizing your site’s PHP code and queries. Check out TTFB and PHP for more information about troubleshooting TTFB.

 

There you have it! Some quick and easy ways to increase your Google PageSpeed scores. And along the way, we’ve covered some background on what they mean in the context of WordPress. Using these insights you can take your site’s browser performance and SEO to the next level!

Cookies, Sessions, and Persistent Caching

The Conflict

A common issue when developing a website comes when your site has a need for page cache, but also a need for user sessions using cookies. PHP Sessions conflict with page caching, and here’s why:

When a user visits your site, they request a page. The page request is sent to the server, where your PHP code is executed to generate the page. The PHP code is where you’d set any specific PHP Session variables, and also any actions to take place based on the presence of these cookies and sessions. For the first user to your site, this is no problem. The PHP code is requested and executed as normal! But on the way to serve the request to your user, the server stores a copy of the generated HTML in page cache.

Enter the conflict: with page caching, the second user to come to your site within your caching timeframe gets served the cached version of the page. The request never makes it back to WordPress/PHP to process the code again. So your cookies and sessions aren’t set, and your actions based on cookies present aren’t executed.

Decision Time

In this situation, you have to make a decision: Is a cookie or a PHP Session really the right course of action for what you’re trying to accomplish? If the answer is yes, you’ll need to make Page Cache exemptions on your site in order to get things working. This means extra traffic going to this page could cause high server load, and could take longer to process.

If the answer is no, consider other options: Can you perform the action you want with Javascript? Admin-ajax requests? Whenever possible, dynamic content should load with Javascript so that it can still run lightweight on your server, and take advantage of page cache. If this simply isn’t possible, go ahead and uncache the page. But, rest assured that if you use Object Cache to cache repeated query results, at least this caching layer will still be present to cache the results of the queries run on these pages.