Dynamic Requests is the way in which we measure the amount of visitors that are being handled by your Bolt. Even with high traffic numbers, you’ll want to keep these as low as possible. Simply because that will mean that your pages are being served as fast as possible and your Bolt will be able to scale even further when traffic increases. Lowering the amount of Dynamic Requests might seem like a daunting task. But these three tips should get you in the right direction.
Find a caching solution
Ensure your cache works as intended
Even with a caching solution in place, there still could be reasons for visitors directly hitting your Bolt. If you have a shop for example, you’d want visitors with products in their carts to bypass the cache. Or if you have a blog, you’d want editors to work in real time on articles. In most other cases however, you’d want people to view the site directly from cache. Requests that are served from the cache are faster and will allow you to scale easier to accommodate more visitors than with uncached requests. You can verify that cache is working by checking the cache headers of the HTTP requests being sent to your site. If these requests aren’t being cached, you can investigate this further by following the steps outlined in this article. We often see people hitting their Bolt directly with requests that could have been handled by their cache, and therefore use more Dynamic Requests than needed.
Checking requests to the website itself
Another thing we see happening is that websites can be built in a way where they request content from themselves, for example by requesting the contents of a shopping cart after the page has been loaded. In short: this would cause a single visit to create multiple Dynamic Requests. Even though there are valid use cases for it, it’s best to try and avoid this kind of behaviour, as it will quickly lead to a big number of Dynamic Requests without even having much traffic on the site. The easiest way to spot this is by analysing your access logs while browsing the site. If you see multiple requests on dynamic sources (.php files for example) for a single pageview, this would require attention. The best course of action would of course depend on the kind of requests that are being made. Normally, we’d see either a GET or a POST request going back to the site. If the request is a GET request, we need to see why it wasn’t being served from the cache. We can do so by using the methodology listed above.
POST requests on the other hand cannot be cached. To further investigate these, we’d need to see what part of the site triggered the POST request. To do so we need to open this request in the browser console: right click the page, and select “Inspect”.
Next, go to the network tab and reload the page. This will show you all requests that are made to generate the page in the browser. Selecting the Fetch/XHR option will give you a quick overview of all requests made after the initial page was loaded.
Our POST requests should be listed among these. If you click its name on the left hand side, you will get all information related to that specific request. The tab labelled Payload contains all information sent back to the server.
If this request was made due to a plugin being active, there would be information in this payload telling you what plugin it was.
And as always, should you have any additional questions please don’t hesitate to contact our support chat at servebolt.com!
Give us your feedback on this article
Want to speed up your site, easily?
Set up your site on Servebolt, free of charge for 14 days, and see for yourself how fast it can be on our extremely fast hosting.
A faster site converts better, ranks better on Google, and is better for the climate.