B-C-9UJQVB

Caching recommendations for Wordpress integration on Akamai

Blog Post created by B-C-9UJQVB Employee on Feb 4, 2016

wordpress-logo-stacked-rgb.png

Wordpress is most widely used PHP based CMS and it is very widely used because of the many reasons. It is open source. It can be customized very easily and as per the need with the help of themes and plugins available readily.

 

Its very important to understand how the files at WordPress is structured.

Screen Shot 2016-02-04 at 6.21.52 PM.png

So there are few files and directories under the document root. This structure is fixed to have pre-defined type of files. wp-content is the directory where all the static files resides and thus are good candidate for caching. There are 2 directory under it, plugins and themes. As the name suggests, plugin directory contains all the plugin files and themese directory contains all the themes files under corresponding subdirectories and thus these should be cached. Do not cache /xmlrpc.php because this handles the xml-rpc calls.

 

Now, coming to URL structure, one can set various predefined URL patters or can create custom URL pattern as well.

WordPress-Permalink-Settings2.png

Based on the option selected by the webmaster, you will see different kinds of URL patterns and thus can set the caching rules. The admins log into the WordPress with the URL /wp-admin/ or /wp-login.php and thus these should not be cached. All the uploads go to /wp-contents/uploads directory. it can reside in one directory or can reside in multiple directories with grouped as year and months under it. To log into the admin panel, a login form is used which is POST the data to the server and thus POST should be enabled. Also, if comments are enabled then again it will be POST requests.

 

Now that we understood the skeleton of WordPress, we can integrate it easily with Akamai. You can set 2 kind of caching rules for WordPress

  1. Caching static assets
  2. Caching entire website aggressively.

 

If the web traffic for a site is not coming in spike then customer prefer caching only static assets. If they expect flash traffic then they would want to cache aggressively. This is because every time a request comes to WordPress, it initiates a background database call to fetch the content from there. Even though the page might be same for all the users, still it will initiate a fresh backend call.

 

Case 1: Caching static assets

 

  • Cache /wp-content/*. Can set high ttl value
  • If there are any image based plugins used, like timthumb, then set caching rule accordingly. eg set TTL on /*/timthumb.php
  • Enable POST
  • Cache /favicon.ico
  • Cache the standard static extensions
  • Put the SEO assets on netstorage
  • Set no-store rule for /wp-admin/*, /wp-login.php

Case 2: Caching entire website aggressively [This requires Dynamic Page Caching]

  • Cache /wp-content/*. Can set high ttl value
  • If there are any image based plugins used, like timthumb, then set caching rule accordingly. eg set TTL on /*/timthumb.php
  • Enable POST
  • Cache /favicon.ico
  • Cache the standard static extensions
  • Put the SEO assets on netstorage and cache it for 1 day.
  • Cache Search results for shorter period
    • path match =/
    • Query match=s
    • Include all query parameters in cachekey
  • Cache /* for 1d
    • Its not advisable to cache /* when comments are flowing in because then the new comment will not show up.
  • Do a cache-bypass when the following cookie is present [This cookie is set when admin/user log into the admin panel]
    • wordpress_logged_in_<somestring>=some value; path=/; httponly
  • Set no-store rule for /wp-admin/*, /wp-login.php

Its advised that customer use "W3 Total Cache" or "WP Super Cache" plugin at their end. This creates static snapshots of their dynamic pages and reduces load on their database server.

 

Hope this helps in understanding WP better and getting the WordPress integration process smooth.

Outcomes