Subtle diagonal pinstripe pattern in light grey and cream, giving an impression of printed editorial paper

How to load WordPress assets from a CDN for better performance

WordPress sites often load stylesheets, scripts, fonts and images from the same origin server. When that server sits hundreds of kilometres from a visitor, every request adds network latency. A content delivery network, or CDN, stores copies of these files in edge locations so they can reach users across Australia and the wider world from a shorter distance.

The largest gains usually come from delivering cacheable assets through the CDN while keeping personalised content on the WordPress origin. A visitor browsing products in Melbourne should receive images and JavaScript quickly, while their cart, login state and checkout information must still come from an authoritative server.

A successful setup involves more than changing a hostname in the WordPress dashboard. Asset URLs, cache headers, HTTPS, plugin behaviour and cache purging all need to work together. Australian sites also face distinct connection conditions, including variable mobile coverage, regional fixed-wireless services and privacy requirements under Australian legislation.

Understand what the CDN should deliver

Static assets are files that do not change for each visitor: CSS, JavaScript, images, icons, downloadable files and most webfonts. These are excellent CDN candidates because one cached copy can serve many requests. By contrast, WordPress pages containing comments, account details, cart contents or personalised recommendations normally need fresh responses from the origin.

HTML caching is a separate decision from asset caching. A full-page caching layer can accelerate anonymous page views, but it introduces complications around cookies, shopping carts and content updates. For a focused CDN implementation, begin with public files and leave dynamic pages under WordPress control. The result is easier to test and less likely to expose customer data.

Plugins and themes may also enqueue files from external providers. Analytics, advertising, payment and support tools each add network requests, and some block rendering while they load. Moving WordPress-owned assets to the CDN will not remove those dependencies. Review every script tag so the CDN improves delivery without creating another source of delay.

Prepare WordPress to rewrite asset URLs

Start by creating a hostname such as assets.example.com.au with your CDN provider. Configure the provider to retrieve the matching files from the WordPress origin, or upload the public asset directory into its storage. DNS settings alone do not copy anything; without an origin rule, a rewritten URL will return a missing-file response.

The following example can live in a small plugin or your child theme’s functions file. It rewrites registered CSS and JavaScript URLs that point to the WordPress content directory while preserving version query strings:

function wpqacdn_asset_url( $url ) {
    if ( is_admin() || 0 !== strpos( $url, content_url() ) ) {
        return $url;
    }

    $parts = wp_parse_url( $url );
    $path  = isset( $parts['path'] ) ? $parts['path'] : '';
    $query = isset( $parts['query'] ) ? '?' . $parts['query'] : '';

    return 'https://assets.example.com.au' . $path . $query;
}

add_filter( 'script_loader_tag', function( $html, $handle, $src ) {
    return str_replace( $src, wpqacdn_asset_url( $src ), $html );
}, 10, 3 );

add_filter( 'style_loader_tag', function( $html, $handle, $href ) {
    return str_replace( $href, wpqacdn_asset_url( $href ), $html );
}, 10, 3 );

These filters retain the ver parameter used by WordPress for cache busting. They leave administrator pages and unrelated external URLs alone, although you should narrow or extend the allowed paths to match your installation. Inline scripts and assets registered directly by a theme may need separate handling.

Some providers can rewrite URLs automatically at the edge. Choose one method rather than combining automatic rewriting with a WordPress filter, since applying both can produce malformed URLs. Also avoid broad string replacements across the entire page: REST API requests, uploads, form actions and plugin endpoints often require the original site domain.

Choose cache headers for each file type

Cache lifetime determines how long a browser or edge server may reuse a file without asking the origin again. Versioned CSS and JavaScript can receive a long lifetime such as Cache-Control: public, max-age=31536000, immutable. Images and fonts may also be cached for months, while files without a reliable version identifier need shorter periods.

WordPress commonly identifies asset versions through a query string rather than a fingerprint in the filename. Confirm that your CDN includes query parameters in its cache key. If it ignores them, a published stylesheet could remain cached after an update. Renaming assets with a content hash provides stronger cache busting, but it requires support from the build or deployment process.

Browser caching and CDN caching are independent. The edge may already hold a current file while a visitor’s browser retains an older copy, and both layers need invalidation when an update ships. Purge affected URLs through the provider’s dashboard or API. If your deployment workflow produces fingerprinted filenames, purging becomes less frequent because each new file has a unique address.

Avoid caching personalised HTML as a simple extension of the asset setup. Logged-in editors, WooCommerce customers and customers with non-empty carts need origin responses. Configure the provider to bypass shared caching for these routes, then verify that static files remain cacheable even when the page itself is not.

Connect the CDN hostname securely

The CDN hostname needs a valid TLS certificate, and every asset request should use HTTPS. Check that the certificate covers the new hostname rather than only example.com.au. Redirect insecure requests at the edge, and restrict direct origin access where your provider supports it, so visitors cannot bypass the CDN by discovering the origin address.

Cross-origin rules matter when fonts, stylesheets or scripts are served from a different hostname. Configure CORS for assets that require it, and add the appropriate crossorigin attribute when WordPress enqueues them. A Content Security Policy can also restrict executable content to approved domains, but introducing it alongside a CDN requires careful testing to avoid blocking legitimate plugin scripts.

Do not add subresource integrity hashes to scripts that change without a corresponding hash update. A fixed external script with a correct integrity value can benefit from this protection, while dynamically generated code is a poor candidate. Keep third-party script domains in the policy and ensure your provider does not inject unexpected cookies or advertising content into asset responses.

Australian site owners should also consider the Australian Privacy Principles under the Privacy Act 1988. CDN logs may contain visitor IP addresses, request times and device information, so check what the provider records, where it stores that data and whether your agreement limits its use. A CDN improves performance without requiring the collection of additional identifying data.

Measure performance on Australian connections

Use a synthetic testing service with locations in Sydney, Melbourne, Brisbane, Perth or Adelaide, depending on where your audience is concentrated. Tools such as WebPageTest and Lighthouse can reveal the time spent waiting for the origin, downloading assets and executing JavaScript. Compare the results before and after the CDN configuration instead of relying on a general website speed score.

Measure the browser’s Core Web Vitals: Largest Contentful Paint for visible loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability. These metrics connect more closely to visitor experience than raw transfer volume. A CDN may improve the first request considerably while leaving later requests unchanged if the browser already holds the file.

Australian connection quality varies considerably. Fibre-to-the-premises services perform well in many metropolitan areas, while regional users may depend on fixed wireless, ADSL or a mobile network. On 4G and 5G, signal strength and congestion can affect performance. Serving static files from a nearby edge reduces network distance, but it cannot remove the processing time of an uncached WooCommerce request.

Mobile performance also involves battery consumption. Commuters checking a store on the way to work in Melbourne or Brisbane often have several applications competing for network access and background processing. Guidance on reducing mobile battery usage reinforces the need to control unnecessary scripts as well as transfer size. Deferred JavaScript and reduced image weight benefit both battery life and page responsiveness.

Test dynamic features and third-party scripts

A URL rewrite can affect more than an image request. Check the block editor, media library, customizer and administrator tools, since their scripts may contain relative paths or references to WordPress endpoints. The same applies to REST API requests, AJAX actions and authenticated nonce checks. A broken asset can produce an error even when the rest of the page appears to load.

Function testing is therefore as important as timing tests. A successful response from a CDN does not prove that a payment form, cart calculation or interactive widget still works. Broader third-party script testing offers a useful reminder that network checks should be paired with real user interactions and browser console inspection.

Run the site through Chrome, Safari, Firefox and Edge, including a mobile viewport. Confirm that no blocked resources appear, no mixed-content warnings are generated and no JavaScript exceptions point to a rewritten URL. Test the WordPress login and logout cycles, then exercise search, filtering, contact forms and any externally hosted checkout component.

Australian WooCommerce stores commonly display prices in AUD with GST-inclusive totals and may integrate Australia Post shipping calculations. Keep these personalised and frequently changing responses on the origin. Payment scripts can remain on approved external domains, provided they load consistently and their privacy and consent handling match the site’s configuration.

A practical CDN delivery checklist

Use a staging copy before changing production DNS. Record the existing asset URLs, response headers and origin traffic so you can identify a regression and roll back the WordPress filters without guessing.

Asset delivery checks

Then validate the site’s behaviour and operational visibility after deployment.

Functional and operational checks

Document how cache purging works before publishing updates, and include it in your deployment procedure. Keep the original WordPress assets available at the origin as a fallback, and record which filters, provider rules or plugin settings make up the configuration. This sequence moves repetitive file delivery away from the origin while keeping site behaviour, cache control and recovery firmly under the site owner’s control.