Performance

What is Above the Fold Content?

If you use many performance testing tools like Google PageSpeed Insights and GTMetrix, you might run across a recommendation: “Optimize Delivery of Above the Fold Content.” So what is Above the Fold Content anyway? And how can you optimize it?

Defining Above the Fold

“Above the Fold” is an industry term for files and content that has to load before your page can start displaying anything. It means the content above the bottom of your visitor’s browser window. Until your “Above the Fold” items have loaded, the user simply sees a blank page. Prioritizing what items load “Above the Fold” and what items can load later on is one of the important steps in optimizing your site for a faster browser load time.

What goes Above the Fold?

Most importantly, you want your site’s “Critical CSS” to load “Above the Fold” – this CSS is the styling information from your theme (and possibly plugins). There may be other CSS files that aren’t as important to load up front though – for instance, styles for your footer (often “Below the Fold”), or styles for certain features or widgets. You can use a tool like Above the Fold Optimization to extract your site’s CSS, and then use a “Critical CSS” extractor to find what should be prioritized first.

What shouldn’t go Above the Fold?

Most often, JavaScript shouldn’t have to load before your site can begin rendering. Since JavaScript usually controls an action like a popup, autoscroll, or loading more content, those files can needlessly bulk up your Above the Fold content. Whenever possible, these files should be deferred to load in the footer instead. The one primary exception to this rule is with sliders: the jQuery files that control the slider need to be loaded Above the Fold in order to properly rotate the slider images.

How can I see what’s loaded Above the Fold on my site?

Use a testing tool that offers a waterfall view, like WebPageTest or Pingdom. Look at what is being loaded before the “start render” line to see what is critical. If it’s not critical, defer it! If it is critical, be sure to minify it so the browser can read it easily.

Scaling a Forum Site

Help! My Site is Super Dynamic!

One of the most troublesome issues a developer or engineer can face is keeping your hosting cost low for a highly dynamic or inherently uncacheable site. How can a popular site that’s constantly updating scale well with spikes in traffic?

Many times the initial reaction will be: you simply can’t. Most systems that allow WordPress sites to scale well involve full-page caching, which simply isn’t an option for these types of sites. You need users to see the constant changes as they happen on the site, not minutes or hours later. These sites require a high level of dynamic content that is simply hard to accomplish.

Fragment Caching

If the budget simply won’t allow for more hardware, then it’s time to start thinking about what can and can’t be cached on the site. Is the header and footer going to always be the same no matter which user is on the site? Will the front page be the same? WordPress uses an Object Cache class which by default stores items wrapped in the wp_cache() function. By default the Object Cache is non-persistent, but you can couple it with Memcached to store the Object Cache items in Memory, to be served across all users.

By default WordPress will serve repeated query results from Object Cache. But really, anything you wrap in the wp_cache() function can be served from cache, including the HTML output from your header, footer, sidebar, and more. This is commonly known as “fragment caching.” WordPress provides some great examples of how to implement this on their Object Cache codex page.

Microcaching

On top of fragment caching, you may also consider using “Microcaching” at the Nginx level. This is a little-known process wherein Nginx caches your site’s static files like images, css, and javascript for long periods of time, while caching pages for a single second. This can vastly improve your site’s scalability if your site is constantly updating and changing. Check out the benchmarks in Microcaching WordPress in Nginx for a comprehensive example.

TTFB and PHP

What Causes TTFB?

High Time to First Byte, or TTFB, is a commonly misunderstood problem on websites. It’s easy to look at this metric strictly as a server issue. The reality is, high TTFB doesn’t necessarily mean your server is slow or overloaded. So why would a page show over 1 second for TTFB if the server’s load looks just fine? The answer typically comes down to the dynamic page creation process required with PHP sites.

PHP vs HTML

To fully understand this issue, you’ll first want to take a look at PHP’s predecessor: HTML. HTML websites offer a nice simplicity in that when a page is requested, the web server simply has to locate and serve a static file. With WordPress and other PHP-based sites, the web server follows a set of directives to generate the page by executing PHP code and communicating with a database.

The database provides information like what page content exists on each page, post ID, URL, and autoloaded options. Once the page has been generated, it can be served to your site’s visitor. So while HTML has a single file to serve on a page visit, PHP has to create everything as new each time the page is requested. By nature, this takes longer! That’s expected. But PHP offers far more diversity in the level of dynamic content it can serve, which is why so many users still choose this option.

Cause and Effect

So what should you try if you have a high TTFB? What if it’s intermittent? How does it affect your site? For one, high TTFB could cause a high bounce rate if it gets high enough. Users typically will wait 2-3 seconds to start seeing content on your site before they leave, or at least have a degree of frustration. Not to mention, TTFB could affect your search rankings too. Google ranks pages based on popularity, but also on how fast they load, security, and mobile readiness.

Troubleshooting

If your WordPress site is plagued by high TTFB, start troubleshooting by creating an uncached dev environment to factor out any page caching that’s been helping intermittently. Since page cache stores a static copy of your page to be served to repeat visitors, it can often confuse the matter by showing low TTFB intermittently on your tests. Using an uncached environment will give you a clearer view of what’s truly causing the issue.

In your staging environment, start by eliminating factors en masse – try deactivating all plugins, or activating a default theme. After each, test your TTFB using a resource like www.webpagetest.org. If it ends up being the plugins, start enabling them one at a time (or in smaller groups if you have a lot of plugins to get through). After each change, note how fast your site loads and run a test. Once you have narrowed it down, you can also try a diagnostics tool like the Query Monitor plugin to show you if any queries to the database are to blame. This might help you determine if there’s a specific setting in your plugin or theme affecting your TTFB.

What struggles with TTFB have you experienced? Were you able to find the source of your issue? Tell your story in the comments.