https://www.peakhour.io/2023-11-02T13:00:00+11:002023-11-02T13:00:00+11:002023-11-02T13:00:00+11:00Dantag:www.peakhour.io,2023-11-02:/blog/magento-2-plugin/

<p>Elevate your e-commerce with our newly released Magento 2 plugin. Experience enterprise-level caching features accessible to all Peakhour customers.</p>

<p>We've released our Magento 2 plugin for e-commerce stores using Magento. It brings Peakhour's caching features into Magento, including capabilities that other providers often reserve for enterprise plans. With Peakhour, 'Enterprise for Everyone' means making those features available to all customers, regardless of plan.</p> <h2>Why Cache Tags Matter</h2> <p><a href="/learning/cache-tags/">Cache tags</a> solve a practical website management problem: keeping your cache current when content changes. In Magento 2, a single change, such as updating a product's price, can affect multiple pages. Cache tags ensure that only the relevant cached content is updated, maintaining cache efficiency and reducing server load. That matters for website speed and user experience, which directly affect sales and SEO rankings.</p> <h2>Enterprise for Everyone</h2> <p>While other providers offer cache tags only in expensive enterprise plans, Peakhour makes this feature available to everyone. Our infrastructure and caching algorithms make that possible. We also offer other enterprise-level features, including DDoS protection, real-time analytics, and custom caching rules, so 'Enterprise for Everyone' is reflected in the product rather than just the plan names.</p> <h2>Peakhour vs. Magento and Varnish Caching</h2> <p>Our plugin goes beyond Magento's built-in caching and Varnish cache in several ways:</p> <ol> <li> <p><strong>Custom Cache Tags</strong>: Unlike Magento's built-in cache, we offer custom cache tags for more granular cache control.</p> </li> <li> <p><strong>Advanced Algorithms</strong>: Our caching algorithms go beyond Varnish, helping improve cache hit rates and lower server load.</p> </li> <li> <p><strong>Additional Features</strong>: With Peakhour, caching sits alongside real-time analytics, DDoS protection, and custom caching rules, features often missing in standard Magento or Varnish setups.</p> </li> </ol> <h2>Expected Performance Improvements</h2> <p>By using Peakhour's Magento 2 plugin, you can expect performance improvements:</p> <ol> <li> <p><strong>Faster Page Loads</strong>: Our caching can reduce page load times by up to 50%, giving users a smoother experience.</p> </li> <li> <p><strong>Reduced Server Load</strong>: Efficient caching means fewer requests to your origin server, reducing server load by as much as 70%.</p> </li> <li> <p><strong>Improved SEO</strong>: Faster websites are favoured by search engines, which can improve SEO rankings.</p> </li> <li> <p><strong>Higher Conversion Rates</strong>: A faster website gives users a better experience, which can lead to higher conversion rates and increased sales.</p> </li> </ol> <h2>Installation Options</h2> <p>You can install the Magento 2 plugin through Magento Connect, Composer, or a ZIP file. For more detail, see our <a href="/docs/how-to-guides/integrations/magento-2/">plugin page</a>.</p>2023-11-01T13:00:00+11:002023-11-01T13:00:00+11:00Dantag:www.peakhour.io,2023-11-01:/blog/accelerate-magento/

<p>There are many things you can do to speed up your Magento store, here are just a few.</p>

<p>Out of the box, Magento is not the fastest ecommerce platform. Magento 2 is built with Full Page Cache in mind, so repeat page requests do not always have to hit the application. A slow Magento store can frustrate customers, increase bounce rates, and cost sales. There are several practical ways to accelerate <a href="/learning/ecommerce-security/securing-magento-shopify/">your Magento</a> store and improve the user experience. These are good places to start.</p> <h2>Caching is King</h2> <p>Caching is usually the biggest performance lever for a Magento store. By storing pre-generated versions of pages, you reduce server response times and avoid asking Magento to rebuild the same page for every request.</p> <ul> <li><strong>Full Page Caching (FPC)</strong>: Magento includes built-in FPC, but it can be extended. Varnish is a common choice for this role. Magento 2 has native support for Varnish, which acts as a web application accelerator.</li> <li><strong>Redis</strong>: Use Redis for session and cache storage. It is an in-memory data structure store that can speed up backend operations by reducing database load.</li> <li><strong>Edge Caching</strong>: Use Peakhour Edge to cache your dynamic pages close to users. This serves content from a nearby delivery path and reduces latency. Peakhour's <a href="/docs/how-to-guides/integrations/magento-1/">Magento 1</a> and <a href="/docs/how-to-guides/integrations/magento-2/">Magento 2</a> plugins make this straightforward to set up.</li> </ul> <h2>Optimise Your Images</h2> <p>Images often make up the bulk of a page's weight. Optimising them is one of the simplest ways to improve load times.</p> <ul> <li><strong>Compression</strong>: Use image compression tools to reduce file sizes without a noticeable loss in quality.</li> <li><strong>Next-Gen Formats</strong>: Serve images in modern formats like WebP or AVIF, which offer better compression. A CDN can often handle this conversion automatically.</li> <li><strong>Lazy Loading</strong>: Implement lazy loading for images that are "below the fold" (not immediately visible). This means they only load when they are about to enter the user's viewport.</li> </ul> <h2>Minify and Merge CSS/JavaScript</h2> <p>Magento has built-in features for merging and minifying CSS and JavaScript files.</p> <ul> <li><strong>Minification</strong>: Removes unnecessary characters (like whitespace and comments) from code to reduce file size.</li> <li><strong>Merging</strong>: Combines multiple CSS or JavaScript files into a single file to reduce the number of HTTP requests.</li> </ul> <p><strong>Note</strong>: Always test thoroughly after enabling merging, as it can sometimes cause issues with certain themes or extensions.</p> <h2>Keep Your Environment Updated</h2> <p>The environment your Magento store runs in has a direct effect on performance.</p> <ul> <li><strong>Latest PHP Version</strong>: Use the latest stable version of PHP supported by your Magento version. Each new release brings performance and security improvements.</li> <li><strong>Server Resources</strong>: Ensure your server has adequate RAM and CPU power to handle your traffic, especially during peak times.</li> <li><strong>Web Server</strong>: Use a high-performance web server like Nginx, which is known for its speed and efficiency.</li> </ul> <h2>Use Edge Caching and Delivery</h2> <p>An edge delivery layer is a practical requirement for many ecommerce stores. It caches your static assets (images, CSS, JavaScript) close to users.</p> <ul> <li><strong>Reduced Latency</strong>: Users receive content from the server geographically closest to them, which speeds up load times.</li> <li><strong>Reduced Origin Load</strong>: By serving cached content, an edge cache reduces the number of requests that hit your origin server, improving its performance and stability.</li> <li><strong>Enhanced Security</strong>: Peakhour also offers security features like a Web Application Firewall (WAF) and DDoS protection.</li> </ul> <h2>Database Optimisation</h2> <p>A slow database can slow the whole store.</p> <ul> <li><strong>Clean Logs</strong>: Regularly clean out Magento's log tables (e.g., <code>log_customer</code>, <code>log_visitor</code>). These can grow very large and slow down database queries.</li> <li><strong>Enable Flat Catalog</strong>: For Magento 1 and older versions of Magento 2, enabling the Flat Catalog for products and categories can improve performance by reducing the complexity of database queries.</li> <li><strong>Re-index Regularly</strong>: Keep your Magento indexes up to date. A cron job should be set up to handle this automatically.</li> </ul> <h2>Audit Third-Party Extensions</h2> <p>Poorly coded or unnecessary third-party extensions are a common cause of Magento performance issues.</p> <ul> <li><strong>Review Extensions</strong>: Audit your installed extensions regularly. If you're not using one, disable or uninstall it.</li> <li><strong>Use a Profiler</strong>: Use Magento's built-in profiler or a tool like New Relic to identify slow-running code, which can often be traced back to a specific extension.</li> </ul> <p>These changes will not fix every Magento performance problem, but they cover the areas that usually matter first: cache behaviour, asset weight, the hosting environment, database maintenance, and extension overhead.</p>2023-03-20T13:00:00+11:002023-03-20T13:00:00+11:00Dantag:www.peakhour.io,2023-03-20:/blog/wordpress-plugin-cache-tags/

<p>Read about automatic cache tags in the updated Peakhour WordPress plugin.</p>

<p>We have updated the Peakhour WordPress plugin with automatic cache tag generation. The update is designed to help keep cached WordPress content accurate without forcing full cache clears for routine content changes. We have also checked compatibility with the latest versions of WordPress and PHP.</p> <h2>What are Cache Tags?</h2> <p>Cache tags are labels that CDNs such as Peakhour use to manage cached content more precisely. Instead of clearing the whole cache when one page changes, you can purge only the content associated with the relevant tag. Visitors get the updated content, while the rest of the site can continue to be served from cache.</p> <h3>A Cache Tag Example</h3> <p>Suppose you run a site with a home page, product pages, and blog articles. Without cache tags, updating one product page or article may require clearing the entire cache. With cache tags, each part of the site can use its own tag, such as "homepage," "product," and "blog." When you update content, you only need to purge the cache for the affected tag. That means less unnecessary cache invalidation and a faster site for visitors.</p> <h2>Automatic Cache Tags in the Peakhour WordPress Plugin</h2> <p>The updated Peakhour WordPress plugin generates cache tags automatically for your site's content. When you update content in the WordPress admin, the plugin sends the relevant purge requests to Peakhour. The result is more targeted cache clearing without extra manual work.</p> <h2>How to Get Started with Automatic Cache Tags</h2> <ol> <li>Update to the latest version of the Peakhour WordPress plugin.</li> <li>Follow the instructions to configure cache tags in the Peakhour admin.</li> <li>Flush your cache.</li> </ol> <p>After that, the plugin generates cache tags and sends purge requests to Peakhour whenever you update content in the WordPress admin.</p> <h2>Final Thoughts</h2> <p>Automatic <a href="/learning/cache-tags/">cache tags</a> in the Peakhour WordPress plugin make cache purging more precise. They help improve performance, give you more flexibility, and reduce unnecessary cache clears. Try the updated plugin and let us know how it works for you.</p>2022-10-05T13:00:00+11:002022-10-05T13:00:00+11:00Dantag:www.peakhour.io,2022-10-05:/blog/drupal-purge-module/

<p>We're excited to announce our Drupal 8/9 caching module, read on for more details.</p>

<p>Drupal is an open source content management system (CMS) widely used by Australian government websites. For example, GovCMS is a customised version of Drupal. Peakhour now provides a purge module for Drupal 8/9, extending our existing Drupal support.</p> <p>The Peakhour Purge module extends the Drupal Purge module. The Purge module provides a standardised way of integrating third party CDNs, like Peakhour, with Drupal's native full page caching support. Drupal's native support is suitable for small websites, but has a number of drawbacks. These drawbacks include:</p> <ul> <li>Doesn't support the Vary header.</li> <li>Is served by PHP, so it doesn't scale well.</li> <li>Runs on the same server as Drupal, so geographic latency is still an issue.</li> </ul> <p>Peakhour's edge cache and delivery layer <strong>removes these issues before requests reach origin</strong>, and also adds <strong>image/content optimisation and website security.</strong></p> <h2>Default Caching</h2> <p>Since version 8, Drupal has supported cache tags to provide efficient, targeted invalidation of content for anonymous browser sessions. In this context, anonymous means a user that does not have a Drupal Session cookie. Peakhour supports cache tags for all sites, a feature some competitors reserve for 'Enterprise' plans.</p> <p>Cache tags are great, but another default setting is not. That setting is to add a:</p> <div class="highlight"><pre><span></span><code><span class="n">Vary</span><span class="o">:</span><span class="w"> </span><span class="n">Cookie</span> </code></pre></div> <p>Header to the page response to make sure that logged-in users don't get cached pages. The Vary header informs a cache that different content may be served from origin based on the value in the Cookie header sent by the browser.</p> <p>This is fine if you are using Drupal with no third party javascript libraries. If you do use third party libraries, it can render page caching close to useless. For example, drupal.org itself uses perimeterx for bot detection, which results in a unique session cookie being set on the very first request.</p> <div class="text-center" style="padding: 20px 0px"> <img src="/static/images/blog/drupal-org-first-request.jpg" width="100%" alt="The cookie set by perimiterx"/> <em>The first request to drupal.org results in a unique cookie being set by perimiterx</em> </div> <p>If you use Google analytics, Facebook, or any of a wide array of popular third party libraries, the same thing can happen.</p> <p>This means only the <strong>very first</strong> request from the user could be served from a general page cache. Hit rates would be virtually zero.</p> <h2>Fix the Vary issue with Skip Cache on Cookie</h2> <p>Peakhour gives you a way to work around this. The first step is to disable the <strong>Vary: Cookie</strong> header. Then, to make sure any user with a Drupal Session bypasses the cache, use Peakhour's <strong>Skip Cache on Cookie</strong> feature. As soon as Drupal sets a session cookie, eg when someone logs in, Peakhour will pass requests through to the origin. Full instructions on how to do this are provided on our <a href="/docs/how-to-guides/integrations/drupal/">drupal module documentation</a></p> <h2>eCommerce Drupal sites</h2> <p>If you are running an ecommerce store, or some other type of site that might serve customised information on a page, for example a mini cart with cart count/information, then you will have to do custom development to continue caching pages. A workaround for a mini cart would be to make it load via Ajax or to use local browser storage, and <strong>Peakhour assists in making that happen</strong>.</p> <h2>Future features</h2> <p>Hopefully in the future Drupal will support setting its own cookie for varying the cache, in a similar manner to Magento 2. eg X-Drupal-Vary, this would allow Peakhour to store multiple versions of a page to serve to different users. For example, a user in Germany might get a version of a page in German with German currency.</p>2022-08-04T13:00:00+10:002022-08-04T13:00:00+10:00Dantag:www.peakhour.io,2022-08-04:/blog/prestashop-plugin/

<p>Prestashop is the latest shopping cart we've made a plugin for, read on for more details.</p>

<p>Prestashop is a popular open source eCommerce platform written in PHP. We're releasing a Prestashop module that enables full page caching through Peakhour. Pages can stay cached at the Peakhour edge for longer, and the plugin refreshes them when the underlying content changes in Prestashop.</p> <p><a href="/blog/caching-dynamic-content-with-a-cdn/">Full Page Caching</a> reduces load times by removing the time it takes for a CMS to generate a dynamic page. That is typically around half a second for a quick page, and 3-5 seconds for a slow one. Here is a cache miss and hit from our client fatburnersonly.com.au:</p> <div class="text-center" style="padding: 20px 0px"> <img src="/static/images/blog/prestashop-cache-miss.jpg" width="100%" alt="Prestashop cache miss"/> <em>A typical cache miss on a category page. The origin has to generate the page, taking <strong>2.49 seconds</strong></em> </div> <div class="text-center" style="padding: 20px 0px"> <img src="/static/images/blog/prestashop-cache-hit.jpg" width="100%" alt="Prestashop cache miss"/> <em>A cache hit: <strong>only 35.7 milliseconds</strong> to deliver to the client from our edge</em> </div> <p><strong>Nearly 2.5 seconds removed from Time to First Byte and Largest Contentful Paint.</strong> That's without changing the site itself.</p> <h3>Tag Based Flushing</h3> <p>Like all our recent plugins, the Prestashop plugin adds a header with tag metadata for each cacheable page. This header is called X-Prestashop-Tag and contains the IDs of the relevant entities on the page, eg products, categories, brands, pages, etc. This metadata is stored alongside the cached page. When an entity changes in the Prestashop admin, eg a product price is updated, the plugin issues a flush-by-tag request to Peakhour. Peakhour finds the pages with the associated tag and invalidates them in the cache. The next request for the page passes through to origin and is then re-cached.</p> <div class="text-center" style="padding: 20px 0px"> <img src="/static/images/blog/prestashop-tags.jpg" width="100%" alt="Prestashop full page caching headers"/> <em>Headers returned by the [caching plugin](/blog/opencart/opencart-3-caching-plugin/).</em> </div> <h3>Custom TTL</h3> <p>TTL (Time to live) is the time a resource stays in cache before the cache checks for a new version. You can control this within the plugin. The plugin then sets the peakhour-cdn-cache-control header, part of the new <a href="/blog/cdn-cache-control-header/">cdn-cache-control specification</a>, so only Peakhour responds to the cache directive.</p> <h3>Ajax Mini Cart</h3> <p>Mini carts are dynamic sections of eCommerce websites, and they often stop pages from being cacheable. The Peakhour plugin loads them via Ajax so as many pages as possible remain cacheable.</p> <div class="text-center" style="padding: 20px 0px"> <img src="/static/images/blog/prestashop-mini-cart.jpg" width="100%" alt="Prestashop mini cart"/> <em>The mini cart is in the top right; it is usually returned as part of the generated page.</em> </div> <h3>Cache varying</h3> <p>The same page can show different information depending on factors such as whether a user is logged in, or whether a multicurrency store changes currency. The Peakhour Prestashop plugin handles this by changing a cookie value when those factors change, creating separate cache regions for the different possibilities.</p> <h2>The Results</h2> <p>The Peakhour Prestashop plugin can improve store performance measurably. Our client fatburnersonly.com.au improved their 'good' web vitals scores by 20% in the two months they've been using Peakhour.</p> <div class="text-center" style="padding: 20px 0px"> <img src="/static/images/blog/prestashop-lcp-improvements.jpg" width="100%" alt="Prestashop web vitals improvement"/> <em>Full page caching was enabled halfway through May. Note that a significant number of pages, eg checkout and admin, cannot be cached and are included in these stats</em> </div> <h2>Grabbing the plugin</h2> <p>If you have a slow Prestashop store, see our <a href="/docs/how-to-guides/integrations/prestashop/">plugin page</a> or <a href="/contact-us/">contact us</a> for more information.</p>2022-03-25T13:00:00+11:002022-03-25T13:00:00+11:00Dantag:www.peakhour.io,2022-03-25:/blog/opencart-3-plugin/

<p>Elevate your Opencart 3 store's performance with Peakhour's full page caching plugin. Learn how our features outperform LiteSpeed and Varnish Cache.</p>

<p>Peakhour's Opencart plugin includes features that are usually reserved for enterprise plans with other providers. It follows our 'Enterprise for Everyone' approach in a practical way:</p> <h3>Tag-Based Flushing</h3> <p>Peakhour's plugin records metadata for each Opencart page in the cache. When you update a product or category, only the relevant pages are refreshed. That keeps cache flushing targeted instead of clearing more content than necessary.</p> <div class="text-center" style="padding: 20px 0px"> <img src="/static/images/blog/opencart-3-full-page-caching-headers.jpg" width="100%" alt="Opencart 3 [full page](/blog/drupal/drupal-purge-module/) caching headers"/> <em>Headers returned by caching plugin.</em> </div> <h3>Custom TTL</h3> <p>Control how long a resource stays in the cache before it checks for a new version. This gives you a direct way to manage cache freshness.</p> <h3>Ajax Mini Cart and Wishlist</h3> <p>Dynamic sections like mini carts and wishlists usually prevent caching. The plugin loads these sections via Ajax, which makes more pages cacheable.</p> <h3>Cache Vary</h3> <p>The plugin adapts to different user states, currencies, and languages. It changes a cookie value to create separate cache regions for these variables.</p> <h2>Peakhour vs. LiteSpeed and Varnish Cache</h2> <p>LiteSpeed and Varnish Cache are good options, but Peakhour offers a more flexible and efficient caching solution for Opencart. The plugin makes Opencart as cache-friendly as Magento 2 or Drupal 8, if not more so.</p> <h2>The Results Speak for Themselves</h2> <p>Our client saw a clear improvement in their web vitals scores and website scalability. Full <a href="/blog/prestashop-plugin/">page caching</a> was enabled in October, with the gains shown below.</p> <div class="text-center" style="padding: 20px 0px"> <img src="/static/images/blog/opencart-3-web-vitals-lcp-improvement.jpg" width="100%" alt="Opencart 3 web vitals improvement"/> <em>Full page caching was enabled in October. Note a significant amount of pages, eg checkout, admin etc cannot be cached which affects these stats</em> </div> <p><em>For more information, visit our <a href="/docs/how-to-guides/integrations/opencart-3/">plugin page</a> or <a href="/contact-us/">contact us</a>.</em></p>2021-05-17T13:00:00+10:002021-05-17T13:00:00+10:00Dantag:www.peakhour.io,2021-05-17:/blog/eliminating-blocking-resources/

<p>Even if you have the fastest server in the world, your website might still seem very slow to end users if you have lots of render blocking resources, learn how to deal with them.</p>

<p>We've previously covered ways to find <a href="https://www.peakhour.io/blog/common-issues-that-impact-site-speed/#blocking">resources that block rendering in a browser</a>. Now we'll cover techniques for loading those resources without letting them block rendering. Before making changes, always run some <a href="/blog/introduction-to-website-performance-testing/">website performance tests</a> using your favourite testing tool to get a baseline so you can measure any improvements. We recommend <a href="/blog/testing-website-speed-webpagetest/">testing with webpagetest.org</a>.</p> <p>Before we get into the techniques, it is worth defining the problem.</p> <h2>What is a Blocking Resource?</h2> <p>When a browser loads a page from a website it reads the HTML markup from top to bottom. If it encounters a CSS or JavaScript file while it&apos;s reading, the browser stops while it downloads and parses that file. While the browser is waiting it can’t process the rest of the HTML or display content to the user. Rendering is blocked.</p> <h2>Why is this a problem?</h2> <p>It would not be a problem if every page included only the information required to display it. Most websites do not work that way. They are typically built using prebuilt themes and third-party libraries that can contain lots of CSS and JavaScript. Only a tiny fraction of this code might be used on the current page, or it might only be needed for ‘below the fold’ content, or on another page of the site. <strong>Note: Below the fold means the content of a page that doesn't initially fit on the screen</strong>. Any unnecessary information keeps the browser blocked for longer than needed, slowing the load experience for the user.</p> <p>CSS and JavaScript files are usually at the very top of the HTML document before any of the content. This means they have to be downloaded and parsed before the browser can display anything. Even a website that has extremely fast server response times can still seem very slow if it has blocking resources.</p> <p>Take a simple example: a website that includes a live chat widget. The JavaScript for the widget is included at the very top of the page in the <head> section. The browser has to stop, download, and parse the CSS and JavaScript for the widget (usually downloaded from a third-party domain) before any content is displayed to the user. The chat widget could appear after the rest of the content without affecting the user experience.</p> <h2>Things you should always be doing</h2> <p>Before targeting CSS- or JavaScript-specific techniques, cover the basics for both.</p> <h3>1. Minify all files</h3> <p>Minification is the removal of all non-essential characters in a file, e.g. irrelevant whitespace and code comments. It can make a substantial difference to the file size.</p> <h3>2. Ensure compression is enabled on your server</h3> <p>Make sure your server is configured to use either gzip or Brotli compression when serving CSS and JavaScript.</p> <h3>3. Self host files</h3> <p>If the CSS or JavaScript is on a third-party domain, i.e. not the domain name your website is on, you should strongly consider uploading the file to your website and serving it from your domain. This might not always be possible, but if it is it eliminates the overhead of the browser opening a connection to another domain, and it removes the possibility that the third party is not compressing, minifying, or using HTTP/2.</p> <p>After the implementation of <a href="https://www.peakhour.io/blog/cache-partitioning-firefox-chrome/">cache partitioning in the major browsers</a>, there is no longer any <em>potential</em> advantage to using third-party CDNs to serve assets like JavaScript, fonts, or CSS. Make a copy on your server and host them on your domain.</p> <h3>4. If you can't self host then preconnect to third party domains</h3> <p>If external assets are on third-party domains, and you absolutely can't self host them, then you can improve loading by telling the browser to <code>preconnect</code> to the third-party domain.</p> <p>Using <code>preconnect</code> tells the browser to establish an early connection to the domain before it has discovered the asset while reading the HTML. Use <code>preconnect</code> in the head of the HTML, e.g.:</p> <p><link rel="preconnect" href="https://example.com"></p> <p>Establishing early connections can shave 100-500ms off third-party load times, which is worth having. You should only use <code>preconnect</code> on critical third-party resources. For all the others you can use <code>dns-prefetch</code>, e.g.:</p> <p><link rel="dns-prefetch" href="http://example.com"></p> <p>This tells the browser to perform DNS resolution of the domain early, which is similar to looking up a phone number in the phone book. Pre-resolving DNS can save 20-120ms. That sounds like small numbers, but remember, <a href="/website-performance/">differences as small as 100ms can have large measurable impacts on conversion rates</a>.</p> <h3>5. Select only what you need from frameworks</h3> <p>It is common for users of frameworks like Bootstrap or jQuery UI to only use a fraction of the functionality provided. If this is you, then the first step is to cut out what you're not using. Bootstrap and jQuery UI are modular, you can either download everything in one bundle, or you can break it up to take just the bits you are using.</p> <p>These points will ensure that blocking resources are downloaded as quickly as possible. Now we can discuss some specific techniques that will help minimise blocking and get your page displaying quickly. Please be aware that this is not an exhaustive overview, but these techniques will probably get you 90% of the benefit with 10% of the work. Getting that last 10% requires deeper technical work. If you want to go there, Google’s web.dev website is a good resource.</p> <h2>Techniques for Optimising Blocking Resources</h2> <h3>Javascript</h3> <p>There are a few different techniques for optimising the loading of JavaScript. First, let's look at the default loading behaviour. <em>Credit for the images goes to Daniel Imms and his website Growing with the web</em>. As stated earlier, the default behaviour is to stop parsing the HTML document when a script is encountered, download the script and execute it.</p> <p><img src="/static/images/blog/javascript-loading-legend.png" alt="Javascript loading legend" width="100%""/> <img src="/static/images/blog/default-javascript-blocking-behaviour.png" alt="Default Javascript loading behaviour" width="100%"/></p> <p>Now let's look at how we can change this behaviour.</p> <h4>1. Moving scripts to the very bottom of the page, right before the closing </body> tag.</h4> <p>This is the original optimisation technique, before defer and async were introduced. It works by moving scripts to the very end of the HTML document, where they are downloaded and parsed after everything else.</p> <p><img src="/static/images/blog/javascript-loading-end-of-html.png" alt="Javascript end of page load" width="100%""/></p> <p>In our example in the previous section, the chat widget would now load and pop up after the rest of the content has been displayed to the user.</p> <h4>2. Defer and Async</h4> <p><code>&lt;script&gt;</code> tags that have a <code>src</code> attribute can be marked as either deferred <code>defer</code>, or asynchronous <code>async</code>, or both. For example:</p> <div class="highlight"><pre><span></span><code>&lt;script src=”https://www.somedomain.com/somescript.js” defer async&gt; </code></pre></div> <p>This tells the browser to change the script loading behaviour.</p> <h4>Defer</h4> <p>Defer was the original browser-based support for improved JavaScript loading. It tells the browser to download the script asynchronously while it keeps reading the HTML, and then execute it once it has finished reading the whole HTML document. Here's the loading behaviour with defer enabled.</p> <p><img src="/static/images/blog/javascript-loading-defer.png" alt="Javascript loading defer" width="100%""/></p> <p>As you can see the script no longer blocks the browser from doing anything else while downloading. Defer preserves script execution order. This can be very important if a script depends on one declared earlier in the page.</p> <p>As noted earlier, you can only mark <code>&lt;script&gt;</code> tags that have a <code>src</code> attribute as deferred. Inline scripts, e.g.:</p> <div class="highlight"><pre><span></span><code><span class="nt">&lt;script</span><span class="w"> </span><span class="na">type=</span><span class="s">&quot;text/javascript&quot;</span><span class="nt">&gt;</span> <span class="w"> </span>console.log(&quot;Hi<span class="w"> </span>I&#39;m<span class="w"> </span>some<span class="w"> </span>inline<span class="w"> </span>script!&quot;); <span class="nt">&lt;/script&gt;</span> </code></pre></div> <p>Any attempt to defer that inline block will simply be ignored. This can cause problems if you have inline script scattered through your code and rely on a deferred third-party library, e.g. jQuery. There are two potential solutions if you can't simply move the code to the bottom of the page:</p> <ol> <li>Move each inline code block into its own file and include it using the <code>src</code> attribute so you can defer it.</li> <li>Or you can try declaring the block as a <code>module</code>. Test this carefully, as browser support may be limited and it also places the script into <code>strict</code> mode, which may break it.</li> </ol> <h4>Async</h4> <p>The <code>async</code> attribute tells the browser to download the script now and execute it as soon as it has finished. Like <code>defer</code>, the downloading is done asynchronously. Unlike <code>defer</code>, the script is executed as soon as it is downloaded. Here is the behaviour:</p> <p><img src="/static/images/blog/javascript-loading-async.png" alt="Javascript loading async" width="100%""/></p> <p>As you can see the browser doesn't stop while downloading, but does pause once downloading is finished so it can execute the script. <strong><code>async</code> doesn't preserve script order</strong>, which can potentially cause issues when there are script dependencies.</p> <p>All three methods have pros and cons. <code>Defer</code> and <code>async</code> result in faster page loads overall as the scripts are downloaded while the browser reads the HTML. Moving the script to the bottom of the page shifts the sequence around.</p> <p>Your first option should be to <code>defer</code> all scripts. Then, if some above the fold content is taking too long because it has a JavaScript dependency, e.g. a carousel in the hero section, you can try making the necessary scripts <code>async</code> instead.</p> <h3>Optimising CSS</h3> <p>The key to fast CSS loading is to prioritise the CSS needed for the immediate above the fold content and then defer the rest. Many articles advocate extracting the precise CSS and then including it inline in the HTML document in a style block, i.e.:</p> <div class="highlight"><pre><span></span><code><span class="nt">&lt;style</span><span class="w"> </span><span class="na">type=</span><span class="s">&quot;text/css&quot;</span><span class="nt">&gt;</span> <span class="w"> </span>.accordion-btn<span class="w"> </span>{background-color:<span class="w"> </span>#ADD8E6;color:<span class="w"> </span>#444;cursor:<span class="w"> </span>pointer;padding:<span class="w"> </span>18px;width:<span class="w"> </span>100%;border:<span class="w"> </span>none;text-align:<span class="w"> </span>left;outline:<span class="w"> </span>none;font-size:<span class="w"> </span>15px;transition:<span class="w"> </span>0.4s;}.container<span class="w"> </span>{padding:<span class="w"> </span>0<span class="w"> </span>18px;display:<span class="w"> </span>none;background-color:<span class="w"> </span>white;overflow:<span class="w"> </span>hidden;}h1<span class="w"> </span>{word-spacing:<span class="w"> </span>5px;color:<span class="w"> </span>blue;font-weight:<span class="w"> </span>bold;text-align:<span class="w"> </span>center;} <span class="nt">&lt;/style&gt;</span> </code></pre></div> <p>However, you have to do this on every possible landing page where the critical CSS might be different per page. Inlining CSS also adds to the download size for each page, and forces the browser to reparse the CSS rules for every load rather than being able to use a cached file for repeat views.</p> <p>We advocate for putting the critical CSS into its own file and loading that normally, and then deferring any other non critical CSS. Identifying the critical CSS is the main task. The first thing to do is to look at the included CSS on your website and see if you can identify any non-core files. You can defer those files using this pattern:</p> <div class="highlight"><pre><span></span><code><span class="nt">&lt;link</span><span class="w"> </span><span class="na">as=</span><span class="s">&quot;style&quot;</span><span class="w"> </span><span class="na">href=</span><span class="s">&quot;/styles.css&quot;</span><span class="w"> </span><span class="na">onload=</span><span class="s">&quot;this.onload=null;this.rel=&#39;stylesheet&#39;&quot;</span><span class="nt">&gt;</span> <span class="nt">&lt;noscript&gt;&lt;link</span><span class="w"> </span><span class="na">rel=</span><span class="s">&quot;stylesheet&quot;</span><span class="w"> </span><span class="na">href=</span><span class="s">&quot;/styles.css&quot;</span><span class="nt">&gt;&lt;/noscript&gt;</span> </code></pre></div> <p>The <code>as="style"</code> lets the browser download the file asynchronously. The onload changes the type to stylesheet, telling the browser to parse the file. Finally, we include a <code>&lt;noscript&gt;</code> to enable the CSS to load normally if JavaScript is turned off.</p> <p>Once you've deferred non-core CSS files you can still check whether your core ones contain lots of unused rules. Google Chrome's coverage tool can show unused rules, but it doesn’t let you easily export used and unused rules. You have to go through it yourself, programmatically, or use a third-party tool to make two files: the critical CSS, and the non-critical CSS which can be deferred.</p> <h2>Conclusion</h2> <p>Eliminating, or at least minimising, blocking resources can be one of the biggest improvements to user experience you can make to your site. With <a href="/blog/web-vitals/">Google Web Vitals</a> being introduced soon as a search signal, it is important to make sure your website loads as fast as possible so your users stay longer and buy more from your site.</p>2021-02-09T13:00:00+11:002021-02-09T13:00:00+11:00Dantag:www.peakhour.io,2021-02-09:/blog/caching-dynamic-content-with-a-cdn/

<p>Comprehensive guide to secure dynamic content caching that improves server performance whilst maintaining security controls. Learn how modern application security platforms integrate caching with threat protection for optimal performance-security balance.</p>

<p>Last time we covered how <a href="/blog/common-issues-that-impact-site-speed/#slow" target="issues">slow server performance</a> can have a negative, sometimes <strong>very</strong> negative, effect on your website load times. The causes of slow server responses are many and varied, and not necessarily tied to the server specification. Diagnosing and dealing with them can be difficult, time-consuming, and costly. One practical way to reduce the impact is to look for opportunities to cache <a href="/learning/dynamic-content-caching/">dynamic content</a>.</p> <h2>What is Dynamic Content?</h2> <p>Content delivered by a web server is categorised as either static or dynamic. Static content is the same for every user and is delivered without being generated or processed by the server. Static content is fast to deliver and does not tax a server's resources.</p> <p>Dynamic content is generated by the server for every request. That can involve querying a database several times and executing a large amount of code. Depending on the work required to generate the result, dynamic content can be resource-heavy.</p> <p>Traditionally CDNs have only cached and served the static content of websites, usually the images, CSS files, Javascript files, etc. They required the webmaster to upload these resources to the CDN's servers and to modify their website source HTML to access the resources from the CDN. For example,</p> <div class="highlight"><pre><span></span><code>https://www.yourdomain.com/image1.jpg </code></pre></div> <p>would be changed to be something like</p> <div class="highlight"><pre><span></span><code>https://cdn.yourdomain.com/image1.jpg </code></pre></div> <p>Modern CDNs, like Peakhour, act as a reverse proxy{:target="learning"}, which means they sit between the end user and the website's origin server. This enables them to <em>transparently</em> cache a copy of <em>anything cacheable</em> being returned by the origin server. By transparently caching, we mean the caching happens without changes to the original website.</p> <h3>Full Page Caching</h3> <p>Full Page Caching (FPC) is where the actual HTML document of a web page is cached.</p> <p>Most websites are built using a Content Management System (CMS). Widely used CMS platforms are Wordpress, Drupal, Magento, etc. By default, every time a page is viewed the CMS has to generate the content from its database. Most of the time this generation is unnecessary. The content is either the same for every user, changes very rarely, or only differs by a small amount of personalisation. In each case it is possible to perform Full Page Caching to improve page load times and to cut server load. Let's have a look at the difference full page caching makes to one of our clients, Magento 2 store <a href="/case-studies/savvysupporter/">savvysupporter.com.au</a>.</p> <div class="text-center" style="padding: 20px 0px"> <img src="/static/images/savvy-before.jpg" width="100%" alt="Savvysupporter before"/> <em>Main document load <strong>before</strong> caching: <strong>2.07s</strong></em> </div> <div class="text-center" style="padding: 20px 0px"> <img src="/static/images/savvy-after.jpg" width="100%" alt="Savvysupporter after"/> <em>Main document load <strong>after</strong> caching: <strong>82ms!!</strong></em> </div> <p>Caching the page has cut nearly <strong>2 whole seconds</strong> from the download time. That matters: load differences as small as 100 milliseconds have measurable impacts on website conversion rates. With a Magento 2 website, it's possible to cache all full pages outside the checkout process and the customer/admin area. This can reduce load on the origin in the order of <strong>60-70%</strong> and make the customer experience much better.</p> <h3>API (Application Programming Interface) Caching</h3> <p>Many API calls used by web applications are for the retrieval of information to be displayed to the end user. Examples include:</p> <ul> <li>Pricing and product information</li> <li>Form auto completion</li> <li>Product catalogue searches</li> </ul> <p>These are all strong candidates for caching, reducing load on your server and making websites faster.</p> <h2>Handling Stale Information</h2> <p>The one potential drawback of caching dynamic content is the possibility of returning out of date information to the end user. There are two strategies to deal with this risk.</p> <ol> <li> <p><strong>Setting a short Time To Live (TTL) with the caching provider</strong>. By only keeping content cached for a short time, e.g. 5 minutes, the cache will never be without up to date information for very long. Cached content will expire and the new version fetched from the origin server. The drawback with this method is that, unless your site is very busy, cache hit rates can be low, users can frequently get slow loading pages, and stale content is still possible. However, for very busy sites this can be an effective, low-overhead strategy.</p> </li> <li> <p><strong>Flushing content when it changes</strong>. This strategy sets very long time to live in the cache, months or even years. When content is updated the cache is informed and the new version fetched. This notification of new content could happen manually or, in the case of some CMSs, automatically. For example, Magento 2 and Drupal 8 have a built in framework for integrating caching providers to handle flushing when content/stock changes. This strategy ensures very high hit rates, but unless the flushing is accurate and fast it can result in stale content.</p> </li> </ol> <h2>Security-Performance Integration</h2> <p>Modern <a href="/learning/application-security/what-is-application-security-platform/">Application Security</a> platforms like Peakhour combine caching with comprehensive security controls so performance optimisation does not weaken application protection:</p> <h3>Edge Security Processing</h3> <ul> <li><strong>WAF/WAAP Integration</strong>: Security rules are processed at the edge before content is cached, ensuring malicious requests never reach your origin</li> <li><strong>Bot Management</strong>: Caching adapts based on traffic classification - legitimate users benefit from cached content whilst malicious bots are filtered out</li> <li><strong>API Protection</strong>: Secure caching of API responses with appropriate security headers and access controls</li> </ul> <h3>Cache Security Controls</h3> <ul> <li><strong>Secure Purging</strong>: Authorised cache invalidation through secure API endpoints with proper authentication</li> <li><strong>Content Classification</strong>: Different caching policies for public, authenticated, and sensitive content</li> <li><strong>Header Security</strong>: Automatic injection of security headers (CSP, HSTS, etc.) into cached responses</li> </ul> <h2>Conclusion</h2> <p>Secure dynamic <a href="/products/advanced-caching/">content caching</a> works best when performance optimisation and application security are handled together. By implementing caching within an Application Security Platform, organisations can achieve:</p> <ul> <li><strong>Superior Performance</strong>: Dramatic improvements in load times and server capacity</li> <li><strong>Enhanced Security</strong>: Protection against threats at the edge before they impact cached content</li> <li><strong>Operational Efficiency</strong>: Reduced origin server load whilst maintaining security posture</li> <li><strong>Cost Optimisation</strong>: Lower infrastructure costs through intelligent caching and edge processing</li> </ul> <p>For modern applications and APIs, secure dynamic caching should form part of the performance and security strategy, improving the user experience whilst maintaining threat protection.</p>2020-11-30T13:00:00+11:002020-11-30T13:00:00+11:00Dantag:www.peakhour.io,2020-11-30:/blog/common-issues-that-impact-site-speed/

<p>After covering testing we're going to get an overview of the common issues that impact website load times and how to check for them.</p>

<p>Our last three website performance articles covered the why and how of <a href="/blog/introduction-to-website-performance-testing/">testing website performance</a>, and introduced our two favourite performance testing tools, <a href="/blog/testing-website-speed-webpagetest/">WebPageTest.org</a>, and <a href="https://www.peakhour.io/blog/testing-sitespeed-lighthouse/">Lighthouse</a>. This article covers the common causes of slow loading times, and how to spot them using the same testing tools.</p> <h2>1. Latency</h2> <p>Latency is the time it takes for a request from a client's browser to traverse the internet to reach the website server. A number of factors affect latency, with physical distance usually the main one. Data on the internet travels at the speed of light, so distance may not sound like a major concern. In practice, small delays compound quickly. Here are some realistic examples of request latency:</p> <ul> <li>Sydney to Melbourne: 5ms</li> <li>Sydney to Perth: 25ms</li> <li>Sydney to San Francisco: 75ms</li> </ul> <p><strong>NOTE</strong>: Common tools used to determine latency between servers are Ping and Traceroute, they will provide you with <strong>Request Round Trip (RTT)</strong> latency, ie the time it takes for a request to get to the server and back. So 2 times the numbers above.</p> <p>Here is an example of latency during a webpage load. We'll ignore internet speed and any potential network congestion, and focus only on latency. We'll request a website hosted in San Francisco from a browser located in Sydney.</p> <ol> <li>Browser establishes a TLS (Secure) connection with server, <em>6 * 75ms</em> = <strong>450ms</strong></li> <li>Browser sends HTTP Request for the main page = <strong>75ms</strong></li> <li>Server sends HTTP Response containing page which specifies 10 assets = <strong>75ms</strong></li> <li>Browser requests the 10 additional assets = <strong>75ms</strong></li> <li>Server responds with 10 assets <em>10 * 75</em> = <strong>750ms</strong></li> </ol> <p>In this example, a website with 10 assets, which is a fairly simple page, has nearly <strong>1.5s</strong> added to the page load time through latency alone. If the same site was hosted in Melbourne, the time due to latency would be just <strong>95ms</strong>. To solve this problem you would either move your website server closer to your customers, or use Peakhour Edge caching.</p> <h3>How do I check for latency problems?</h3> <p>If there is a long distance between your server and your customers, eg your website is hosted in the US and your customers are in Australia, page load times will be significantly affected by latency. A good tool for indicative RTT times between cities is provided by <a href="https://wondernetwork.com/pings">wonder network</a>. Webpagetest.org also provides a Traceroute tool which can give you indicative RTT times between its testing locations and your website.</p> <h2>2. Old version of HTTP</h2> <p>Browsers communicate with websites using a protocol called HTTP. The protocol formalises the steps needed to connect a browser and server so a webpage can be downloaded. Since the introduction of the web, HTTP has gone through a number of revisions. The currently widely adopted version is HTTP/2.</p> <p>Even though HTTP/2 was introduced over 5 years ago, over <a href="https://w3techs.com/technologies/details/ce-http2" target="trends">50% of websites</a> are still only served over HTTP/1.1. Without getting too technical, HTTP/2 has significant advantages over older versions because it reduces the number of connections between a browser and server, and transfers information more efficiently.</p> <p>Serving your website over HTTP/2 can improve page load times by <strong>10-15%</strong>.</p> <h3>How do I identify the version of HTTP my website is served over?</h3> <p><a href="/blog/testing-website-speed-webpagetest/" target="testing">Run a performance test of your website</a> using WebPageTest.org, once complete click on the 'Details' link in the report navigation. You will see the Waterfall View. Click on the first request, circled below in this image:</p> <p><img src="/static/images/blog/http2-waterfall.jpg" alt="Webpagetest waterfall view" style="width: 100%;margin-bottom: 20px"/></p> <p>It will bring up the request details including the Protocol used, circled below:</p> <p><img src="/static/images/blog/request-detail-http2.jpg" alt="HTTP Request Detail" style="width: 100%;margin-top: 20px"/></p> <h2>3. <a name="slow"></a> Slow Server Performance</h2> <p>A slow initial response from the server is a common cause of poor page load performance. The majority of websites are built using some sort of Content Management System (CMS), eg Wordpress, Magento, Drupal, Shopify, to name a few. By default, a CMS has to construct a page each time a browser requests it, even when the content has not changed. That process can involve executing a lot of code and querying a database several times before returning the HTML that forms the page.</p> <p>The specification of your server, the number of CMS plugins, the state of your database, and the number of simultaneous users can all affect the response time. A slow server may take 10s or more to respond, while even a fast server can still take over a second to generate a page. That is enough to pretty much make you fail the new Core Web Vitals guidelines before you even get started.</p> <h3>How do I check for slow server performance?</h3> <p>Server performance can be checked from the waterfall view in WebPageTest.org. The time taken to download the main document indicates whether server performance is affecting your page load. Here's an example:</p> <p><img src="/static/images/blog/server-performance-waterfall.jpg" alt="Server Performance Waterfall" style="width: 100%"/></p> <p>The total time taken to download the main document here is over 1.3s. That is not too bad, but it has already used up over half the 2.5s required to achieve 'Good' for the Largest Contentful Paint (LCP) metric in <a href="/blog/web-vitals/" target="webvitals">web vitals</a></p> <h2>4. Page Weight</h2> <p>Even though internet speeds are getting faster, they are still a limiting factor to how fast a browser can download a page. If the requested page and the associated resources, eg images, javascript, CSS, are large files, it will take longer for the browser to download all the required information to display a page. Unoptimised images are a common culprit for inflating page weight. Unoptimised CMS themes and third party javascript libraries are another.</p> <h3>How do I check my page weight?</h3> <p>WebPageTest.org reports the page weight in the far right of its summary, circled here:</p> <p><img src="/static/images/blog/page-weight.jpg" alt="Page Weight" style="width: 100%"/></p> <p>You should be aiming for 2mb or less. This particular website is more than a little obese, coming in at around 30mb... WebPageTest also has a section called 'Content Breakdown' which shows where the weight is, ie in images, javascript, etc.</p> <p><img src="/static/images/blog/content-breakdown.jpg" alt="Content Breakdown" style="width: 100%"/></p> <p>Over 27mb in images is what's weighing down this page.</p> <p>Peakhour also has a <a href="https://www.peakhour.io/pages/page-weight" target="pageweight:">pageweight tool</a> that you can run for a page on your website and receive a full optimisation report for the images on the page, along with downloadable optimised images.</p> <h2>5. <a name="blocking"></a>Blocking Resources</h2> <p>Resources that can block a page include CSS and javascript. When the main HTML page is downloaded and parsed, the browser will not render anything to the screen until the CSS and javascript files that are referenced are downloaded and parsed. If your website includes a lot of CSS and javascript, which is not uncommon for pre built themes for CMS's like Wordpress and Magento, the downloading and parsing of these files can delay the browser from showing any content for several seconds.</p> <h3>How do I identify blocking resources?</h3> <p>The easiest way to check is to use <a href="/blog/testing-sitespeed-lighthouse/">Google Lighthouse</a>) to identify them for you. After running the report, go to the opportunities section and expand the 'Eliminate render-blocking resources' section to see what it finds.</p> <p><img src="/static/images/blog/lighthouse-opportunities.jpg" alt="Lighthouse Opportunities" style="max-width: 100%"/></p> <h2>6. Third Party Resources</h2> <p>It is very common for websites to include third party resources. These are files that have to be fetched from a domain/url other than the one that the page is being requested on. Eg if you are requesting www.domain.com.au, it might include a resource from a third party, eg www.anotherdomain.com.au. Common third party resources might be analytics scripts (eg Google analytics), marketing tools (eg Mailchimp)</p> <p>This forces the browser to open another connection to the third party. The time taken to do this, combined with the possibility that the third party might be slow to respond (see latency and server performance above), can often ruin load times. If the resource in question is also a blocking resource the problem is compounded.</p> <h3>Spotting a problem with third party resources</h3> <p>WebPageTest has a section 'Domains' which displays all the individual domains that the browser connected to when loading the page:</p> <p><img src="/static/images/blog/third-party.jpg" alt="Lighthouse Opportunities" style="max-width: 100%"/></p> <p>If your website is requesting resources from more than 10 separate domains then you should consider why that is happening and whether they are necessary. If you are using external CDNs to load javascript or CSS then you should probably move them onto your domain.</p> <p>Social sharing plugins are notorious for pulling in a lot of resources from external domains. You should replace any share buttons using external scripts with simple static buttons. It is simple to do, and your website will be much smaller and faster. By using the javascript shares that social sites prescribe, you are slowing down your website and allowing third parties to track your clients across the internet.</p> <h2>Conclusion</h2> <p>There are many factors that can slow down your website, drive away customers, and cost you money. You have to regularly <a href="/blog/introduction-to-website-performance-testing/">test your website</a> to check for issues and address them when you find them. Next we'll cover what you can do to fix the issues we've mentioned here.</p>2019-05-27T13:00:00+10:002019-05-27T13:00:00+10:00Dantag:www.peakhour.io,2019-05-27:/blog/wordpress-performance-optimisation-security-cdn/

<p>How to speed up WordPress by separating public cacheable pages from private, expensive, and abused request paths.</p>

<p>WordPress speed problems are usually request-path problems. A public article, product page, or campaign landing page should not make PHP, plugins, and the database rebuild the same HTML for every visitor. A login attempt, checkout session, admin request, or private API call should not be treated like public content just because the site is under load.</p> <p>The job is to separate those paths clearly. Cache what can be reused, protect the routes that are expensive or abused, and keep enough evidence to prove that the change improved the visitor experience without hiding origin risk.</p> <h2>Start With Public Page Caching</h2> <p>Most WordPress sites have a large set of pages that are dynamic only because WordPress generated them. The content itself is public and often identical for many visitors: posts, pages, category archives, product listings, campaign pages, media assets, CSS, and JavaScript. These are the paths where full-page caching and edge delivery can change the result quickly.</p> <p>When a public page is served from cache, the browser avoids the long trip to origin and the origin avoids running WordPress for a repeat response. That can move Time to First Byte and Largest Contentful Paint in the right direction before anyone touches the theme. Peakhour's older full-page caching examples showed the practical size of this change: a Magento main document fell from 2.07 seconds before caching to 82 ms after caching. WordPress sites have different internals, but the same pattern applies when anonymous pages are safe to reuse.</p> <p>The cache policy should be route-aware, not blanket. A simple operating model looks like this:</p> <table> <thead> <tr> <th>WordPress path</th> <th>Delivery stance</th> <th>What to check</th> </tr> </thead> <tbody> <tr> <td>Posts, pages, category pages, campaign pages</td> <td>Cache publicly with tags and purge controls</td> <td>Confirm logged-out content is shared and fresh after publishing.</td> </tr> <tr> <td>Featured images, media library files, theme assets</td> <td>Cache and optimise variants</td> <td>Track image weight, format, dimensions, and cache hit state.</td> </tr> <tr> <td>WooCommerce product and category pages</td> <td>Cache when no cart/session dependency changes the response</td> <td>Keep stock, price, and promotion purges tied to content changes.</td> </tr> <tr> <td>Cart, checkout, account, previews, admin</td> <td>Bypass shared cache</td> <td>Preserve session privacy and correctness.</td> </tr> <tr> <td><code>wp-login.php</code>, <code>/wp-admin/</code>, <code>xmlrpc.php</code>, sensitive plugin endpoints</td> <td>Protect and rate-limit before origin</td> <td>Keep noisy automation away from PHP workers and admin paths.</td> </tr> </tbody> </table> <h2>Publishing Should Not Clear the Whole Site</h2> <p>Caching WordPress is easy until someone edits content. Clearing the whole cache after every post update is safe in the narrow sense, but it damages hit ratio and pushes avoidable traffic back to origin. During a busy publishing period or campaign, that can make the site slower exactly when fresh content is being promoted.</p> <p>Cache tags are a better fit. Tags label cached responses by the content or template they depend on, so a post update can purge the post, related archives, and affected modules without invalidating unrelated pages. The updated Peakhour WordPress plugin generates cache tags automatically and sends purge requests when content changes in the WordPress admin. That lets teams set longer cache lifetimes for public content while still publishing with confidence.</p> <p>This is where <a href="/products/advanced-caching/">advanced caching</a> becomes operational rather than theoretical. The site team can review which tags were purged, which routes stayed cached, and whether the next request was a hit, miss, or stored response.</p> <h2>Images and Browser Work Still Matter</h2> <p>Page caching improves the start of the request path. It does not fix a 3 MB hero image, missing image dimensions, unused CSS, or a third-party script that blocks rendering. WordPress themes and plugin stacks often ship CSS and JavaScript for features that are not used on the current page. The browser still has to download and parse that code before it can paint useful content.</p> <p>Use Lighthouse to find render-blocking resources and main-thread pressure. Use WebPageTest to see whether the main HTML arrived quickly but the filmstrip still stayed blank while CSS, fonts, scripts, or images loaded. Those are different failures, and they need different fixes.</p> <p>For images, the best results usually come from serving the right variant rather than only compressing the original. <a href="/products/image-optimisation-and-transformation/">Peakhour image optimisation</a> can generate AVIF or WebP outputs, choose responsive sizes, and cache the resulting variants. That helps LCP when the largest visible element is an image, and it helps CLS when dimensions are kept stable.</p> <p>For CSS and JavaScript, remove unused files where possible, defer non-critical scripts, self-host critical third-party assets when practical, and reserve <code>preconnect</code> for third-party domains that genuinely affect the first view. Moving every script later can break dependencies, so test the actual page type rather than applying a generic rule across the whole theme.</p> <h2>Protect Expensive WordPress Paths</h2> <p>Performance and security meet at origin capacity. Login floods, XML-RPC abuse, aggressive crawlers, scraper traffic, and noisy plugin endpoints can consume PHP workers and database connections that should be serving real visitors. If those requests are filtered only after WordPress has loaded, the site can look like it has a speed problem when it really has an unsorted traffic problem.</p> <p>For WordPress, protection should be specific. <code>wp-login.php</code>, <code>/wp-admin/</code>, <code>xmlrpc.php</code>, the REST API, and plugin-specific endpoints should have their own bot, WAAP, and rate-limit policy. WooCommerce needs separate handling again: public catalogue pages can often be cached, but cart, checkout, account, and payment paths must stay dynamic and private.</p> <p>This does not mean putting heavy checks in front of every visitor. It means making edge decisions before origin work: allow clean public page requests, serve cache hits, challenge or rate-limit suspicious login traffic, bypass cache for private sessions, and log what happened.</p> <h2>Measure the Outcome</h2> <p>The evidence should line up across tools. WebPageTest should show a faster main document on cache hits, fewer slow origin fetches, and a waterfall where critical resources are visible early. Lighthouse should show fewer render-blocking opportunities and less main-thread pressure. Core Web Vitals should move where the page had the relevant bottleneck: LCP for slow HTML or heavy hero media, CLS for unstable layout, and INP for JavaScript and interaction work.</p> <p>Peakhour evidence should add the delivery side: cache hit ratio, miss causes, purge state, <code>Cache-Status</code>, image savings, shielded misses, blocked login or XML-RPC abuse, and origin request volume. That combination tells the site team whether WordPress is faster because visitors received lighter pages from the edge, because abusive traffic stopped draining origin, or because browser work was reduced.</p> <p>Fast WordPress is not a plugin list. It is a set of clear route decisions backed by before-and-after measurements.</p>2019-05-10T13:00:00+10:002023-11-02T13:00:00+11:00Dantag:www.peakhour.io,2019-05-10:/blog/magento-1-plugin/

<p>Our Magento 1 plugin is now available in the Magento Store. Discover how it improves website performance and capability.</p>

<p><a href="/blog/opencart/opencart-3-caching-plugin/">Full page</a> caching is not a cosmetic optimisation. Users expect quick load times, and search engines reward fast websites with higher rankings. Full page caching supports both by storing fully rendered HTML pages, so the server does not have to rebuild the page from scratch for each visitor.</p> <h2>How Full Page Caching Enhances Performance and Capability</h2> <p>By caching full HTML pages, you create a snapshot of a page at a particular moment. When a user requests that page, the server can deliver the snapshot instead of generating the page again. This saves compute and database resources, allowing your server to handle more users simultaneously. The result is straightforward: faster load times for users and less strain on the server.</p> <h3>Real-World Impact</h3> <p>Our early adopters have reported clear improvements in <a href="/blog/wordpress-plugin/">website speed</a> and server performance. One client saw a 40% reduction in server load and a 20% increase in page load speed. Those results point to a better user experience and potentially higher conversion rates.</p> <h2>Challenges with Magento 1 and How We Solved Them</h2> <p>Magento 1 presents specific challenges for full <a href="/blog/opencart-3-plugin/">page caching</a>, and our plugin handles them directly.</p> <h3>Mini Cart Issue</h3> <p>The mini cart needs to show real-time data, which makes it a barrier to full page caching. Our plugin uses targeted AJAX calls to fetch this data only when required, reducing unnecessary load on the server.</p> <h3>Form Key Problem</h3> <p>Magento 1 uses form keys to prevent CSRF attacks, but those keys make caching difficult. Our plugin replaces form keys with a strict referrer check, which is secure and cache-friendly.</p> <h3>Additional Features</h3> <ol> <li><strong>Automatic Expires Headers</strong>: You do not need to manually set expiration times for your cache; our plugin does it for you.</li> <li><strong>Cache Tagging</strong>: This allows for precise cache management. When you update a product, only the relevant cached pages are flushed, keeping the process efficient.</li> </ol> <p>The plugin is available for download, with the aim of improving performance and increasing server capability on Magento 1 stores.</p>2019-04-02T13:00:00+11:002019-04-02T13:00:00+11:00Dantag:www.peakhour.io,2019-04-02:/blog/wordpress-plugin/

<p>Experience a significant boost in website speed and performance with Peakhour's Full Page Caching feature, now easily accessible through our Wordpress plugin.</p>

<h2>Why Full Page Caching Matters</h2> <p>Site speed affects user experience, conversion, and server load. Slow pages can increase bounce rates and cost revenue. <a href="/blog/opencart/opencart-3-caching-plugin/">Full Page</a> Caching improves response times by storing and serving static versions of dynamic pages. This reduces load on your server and gives visitors quicker page loads.</p> <h2>How Peakhour Optimises Your Site</h2> <p>Peakhour helps speed up and secure your website with a DNS change. Unlike basic caching solutions, Peakhour serves these static pages from its global ANYCast network. Your site's visitors download content from a server close to them, reducing latency and speeding up downloads.</p> <h2>Peakhour's Transparent Caching and Delivery</h2> <p>In addition to Full Page Caching, Peakhour can act as a transparent delivery and cache layer. It caches and optimises static assets like CSS, JavaScript, and images. You don't need to make any other changes to your site; a DNS change is all it takes.</p> <h2>Wordpress Plugin for Easy Integration</h2> <p>During our beta phase, many clients used early versions of our WordPress plugin. The plugin integrates with Peakhour's API to automate content flushing when you make edits in the WordPress admin panel. This simplifies publishing and allows you to set longer lifetimes for your dynamic content in our global cache.</p> <h2>Improved Performance Metrics</h2> <p>With Peakhour, sites can see faster download times, a higher cache hit rate, and reduced load on the origin server. Site owners get lower origin demand; visitors get faster pages.</p>