Sign Up Now and Get FREE CTO-level Consultation.
Browser caching is useful for improving website performance because it allows browsers to store previously downloaded resources and reuse them when users revisit a page. However, caching can sometimes create problems for CodeIgniter applications where users need to see fresh and updated information immediately.
Developers may encounter situations where a particular page, function, or controller should not be cached while the rest of the application can continue using normal browser caching.
So, how can you disable browser cache for a particular function or controller in CodeIgniter?
The simplest approach is to send appropriate HTTP cache-control headers from the specific controller or function where caching needs to be disabled. This allows developers to control caching at a granular level instead of disabling browser caching across the entire application.
In this guide, we explain how to disable browser cache for individual functions, controllers, and pages in CodeIgniter, with practical examples for CodeIgniter 3 and CodeIgniter 4.
Browser cache is a mechanism that allows browsers such as Chrome, Firefox, Safari, and Edge to store resources from a website locally.
These resources may include:
When a visitor requests the same resource again, the browser may use its locally stored version instead of downloading it from the server.
This can significantly improve page loading speed.
However, browser caching can be problematic for pages containing frequently changing information, such as:
For these situations, developers may want to disable browser caching selectively.
Disabling browser caching globally is usually unnecessary.
For example, suppose an application contains 100 pages and only two pages display sensitive or frequently changing information. Disabling caching across the entire application could reduce performance unnecessarily.
A better approach is to disable browser caching only where required.
This provides two advantages:
Static resources and cacheable pages can continue using browser caching.
Specific dynamic pages can instruct the browser to request the latest content from the server.
This selective approach provides a better balance between application performance and data freshness.
The most common method is to send HTTP response headers that tell the browser not to store or reuse the response.
A typical no-cache configuration includes:
$this->output
->set_header('Cache-Control: no-store, no-cache, must-revalidate, max-age=0')
->set_header('Cache-Control: post-check=0, pre-check=0')
->set_header('Pragma: no-cache')
->set_header('Expires: 0');
The exact implementation depends on whether you are using CodeIgniter 3 or CodeIgniter 4.
In CodeIgniter 3, you can set cache-control headers directly inside the controller function that should not be cached.
For example:
public function dashboard()
{
$this->output
->set_header('Cache-Control: no-store, no-cache, must-revalidate, max-age=0')
->set_header('Cache-Control: post-check=0, pre-check=0')
->set_header('Pragma: no-cache')
->set_header('Expires: 0');
$this->load->view('dashboard');
}
Here, the headers are applied only when the dashboard() function is executed.
Other controller functions are not automatically affected.
This is useful when the dashboard contains information that should always be retrieved from the server.
If several functions within one controller require the same no-cache behavior, you can apply the headers in the controller constructor.
For example:
class Admin extends CI_Controller
{
public function __construct()
{
parent::__construct();
$this->output
->set_header('Cache-Control: no-store, no-cache, must-revalidate, max-age=0')
->set_header('Cache-Control: post-check=0, pre-check=0')
->set_header('Pragma: no-cache')
->set_header('Expires: 0');
}
public function dashboard()
{
$this->load->view('dashboard');
}
public function reports()
{
$this->load->view('reports');
}
}
In this example, the cache-control headers apply to responses generated by the Admin controller.
This is a useful approach when an entire controller contains dynamic or sensitive information.
Sometimes you do not want to disable caching for the entire controller.
In that case, put the headers directly inside the individual function.
For example:
public function live_orders()
{
$this->output
->set_header('Cache-Control: no-store, no-cache, must-revalidate, max-age=0')
->set_header('Pragma: no-cache')
->set_header('Expires: 0');
$data['orders'] = $this->order_model->get_latest_orders();
$this->load->view('orders', $data);
}
Other functions in the same controller can continue using their normal caching behavior.
This is one of the easiest ways to implement function-level browser cache control in CodeIgniter.
CodeIgniter 4 uses a different response object and provides response methods for setting HTTP headers.
A controller method can use:
public function dashboard()
{
$this->response
->setHeader('Cache-Control', 'no-store, no-cache, must-revalidate, max-age=0')
->setHeader('Pragma', 'no-cache')
->setHeader('Expires', '0');
return view('dashboard');
}
This applies the cache-control instructions to the response generated by that particular method.
Another approach is to use the response object's cache-control functionality where appropriate.
For example:
public function dashboard()
{
$this->response->setHeader(
'Cache-Control',
'no-store, no-cache, must-revalidate, max-age=0'
);
$this->response->setHeader('Pragma', 'no-cache');
$this->response->setHeader('Expires', '0');
return view('dashboard');
}
The important principle is the same: set the response headers only for the pages or functions that require them.
The Cache-Control header provides instructions to browsers and intermediary caches.
The no-store directive tells caches not to store the response.
For pages containing sensitive information, no-store is particularly important because the objective may be to prevent the response from being stored.
For example:
Cache-Control: no-store
can be used when a response should not be stored.
Additional directives can be used depending on the application's requirements.
Despite its name, no-cache does not necessarily mean "do not store this response."
Instead, it generally indicates that a cached response should be revalidated before reuse.
This distinction is important.
If your requirement is that a response should not be stored, no-store is generally the more appropriate directive.
For sensitive or highly dynamic pages, developers should carefully choose the cache policy rather than relying on the term "no-cache" alone.
If only one page needs fresh content, place the cache-control headers in the controller method responsible for that page.
For example:
public function profile()
{
$this->output
->set_header('Cache-Control: no-store, no-cache, must-revalidate, max-age=0')
->set_header('Pragma: no-cache')
->set_header('Expires: 0');
$data['user'] = $this->user_model->get_user();
$this->load->view('profile', $data);
}
This allows the rest of the website to continue using its normal caching configuration.
In most cases, no.
Global cache disabling can negatively affect performance because browsers will repeatedly download resources that could otherwise be reused.
For example, CSS, JavaScript, images, and fonts may need to be downloaded repeatedly.
Instead, consider applying cache-control rules selectively to:
Static assets should generally have an appropriate caching strategy rather than being globally disabled.
It is important to understand that browser caching and server-side caching are different.
Browser cache stores resources on the user's device.
Server-side cache stores generated data or resources on the server or another infrastructure layer.
Disabling browser cache does not necessarily disable:
If users continue seeing old information after browser caching has been disabled, the problem may exist at another caching layer.
If old content continues appearing, check whether a CDN, reverse proxy, server cache, or application cache is serving the response.
Use your browser's Developer Tools and inspect the Network tab. Check the response headers for the requested URL.
You should see the expected Cache-Control, Pragma, or related headers.
If cache-control rules are accidentally applied globally, CSS, JavaScript, images, and fonts may be downloaded repeatedly.
Keep no-cache rules limited to resources that actually require them.
Browser history behavior can involve more than ordinary HTTP caching. If a page contains sensitive information, use an appropriate cache policy and test navigation behavior across the browsers relevant to your application.
After implementing the changes, test the specific URL using browser Developer Tools.
In Chrome:
You can also test the response using command-line HTTP tools such as curl.
For example:
curl -I https://example.com/dashboard
Review the returned headers to verify that your CodeIgniter application is sending the intended cache policy.
When implementing browser cache control, follow these best practices:
Disable caching only for pages that genuinely require it.
When responses contain sensitive information that should not be stored, consider an appropriate no-store policy.
Images, CSS, JavaScript, and fonts can often benefit from long-lived caching when versioning or cache busting is implemented correctly.
Web servers, CDNs, proxies, and security layers can modify cache headers. Always verify the final response received by the browser.
Look beyond CodeIgniter. Check the browser, web server, CDN, reverse proxy, application cache, and database cache when troubleshooting stale content.
Cache-related problems can appear simple but become complicated when an application includes multiple caching layers, APIs, CDNs, custom middleware, authentication systems, and legacy CodeIgniter code.
An experienced software development company can analyze the complete application architecture and determine whether the problem is caused by browser caching, application caching, server configuration, database queries, CDN behavior, or incorrect HTTP headers.
This is especially useful for businesses running large CodeIgniter applications where disabling caching globally could negatively affect performance.
Blazingcoders is a software development company that provides custom web development and application development services for businesses that need reliable and scalable solutions.
Our development approach can help businesses with:
Whether you need to fix a specific browser caching issue or optimize a larger CodeIgniter application, working with experienced developers can help identify the underlying problem and implement a solution without unnecessarily affecting the rest of the application.
Knowing how to disable browser cache easily for a particular, individual, or separate function and controller in CodeIgniter gives developers much greater control over application behavior.
Instead of disabling browser caching throughout the entire website, you can set cache-control headers only on the functions or controllers that require fresh responses. This approach is particularly useful for dashboards, reports, authentication pages, dynamic data, and other areas where outdated content can cause problems.
For CodeIgniter 3, cache-control headers can be configured using the output class, while CodeIgniter 4 provides response-based header methods. Regardless of the version, the key is to apply the correct cache policy at the correct scope.
If your CodeIgniter application has persistent caching issues or requires more advanced performance improvements, Blazingcoders can help. As an experienced software development company, we can assist with CodeIgniter development, troubleshooting, optimization, maintenance, and custom web application development.
A properly designed caching strategy should achieve the right balance between fresh content, security, functionality, and application performance.
Set the appropriate Cache-Control, Pragma, and Expires response headers inside the specific controller function. This limits the no-cache behavior to that function's response.
In CodeIgniter 3, you can set the cache-control headers in the controller constructor so they apply to responses from that controller. In CodeIgniter 4, you can set the required headers using the response object.
No. no-cache generally means that a cached response must be revalidated before reuse. If the goal is to prevent storage of a response, no-store is generally more appropriate.
Yes. You can set cache-control headers only on the controller method that generates the particular page.
Usually, no. Global cache disabling can increase network requests and negatively affect performance. Selective cache control is generally a better approach.
The content may be coming from another caching layer, such as a CDN, reverse proxy, server cache, application cache, or database cache. Check the complete request and response path.
Open your browser's Developer Tools, go to the Network tab, select the page request, and inspect its response headers. You can also use an HTTP header inspection tool or curl.
For highly dynamic pages, disabling or controlling caching can help ensure that users receive current responses. However, it should be implemented selectively because caching is also important for website performance.
Request a FREE Business Plan.
+91 ▼ 
Modern web applications often deal with thousands or even millions of records. Displaying all this data on a single page is not practical because it slows down page loading and negatively affects the
Read More
Hiring the right offshore PHP developer can be a game-changer for businesses that rely on web applications, portals, or dynamic websites to engage their customers. With the growing demand for scalable
Read More
We provide custom software development for the textile industries. Our Software Solutions coordinates with all the user across the industries with various modules like Marketing/Sales, Planning, Produ
Read More