Postback Request
A postback request is an HTTP POST that a Visualforce page sends back to the Salesforce server when a user interaction needs the server to do work.
Definition
A postback request is an HTTP POST that a Visualforce page sends back to the Salesforce server when a user interaction needs the server to do work. Clicking a Save button, an action link, or any control bound to a controller method generates one. The server decodes the page's view state, runs the matching controller logic, and returns refreshed markup.
Postback is the older, server-driven request model that Visualforce has used since its launch. It still works and ships in every org, but it predates Lightning. New user interface work is built on Lightning Web Components, which keep more logic in the browser and call the server through targeted Apex methods instead of full-form postbacks.
How a postback moves through the Visualforce lifecycle
Get request versus postback request
Visualforce splits page traffic into two request types, and the difference decides which controller code runs. A get request is the first load of a page. It happens when someone types the URL or follows a link that lands on the page fresh. On a get request the constructor runs, the action attribute on apex:page is evaluated, and getters fire to build the initial markup. A postback request happens later, when an interaction on that already-loaded page asks the server to update something. The classic example is a Save button that calls a save() method on the controller. The two paths are not interchangeable. The action attribute on apex:page is evaluated only on a get request, never on a postback. So a developer who expects an apex:page action to re-run on every button click will be surprised, because postbacks skip it entirely. Getters also behave differently. On a get they populate from scratch, while on a postback they run after the saved state is restored. Knowing which request you are in explains a lot of "why did my method run twice" and "why is this value stale" questions in Visualforce code.
View state is what makes postback possible
A postback would be useless if the server forgot everything between clicks, because HTTP is stateless. Visualforce solves this with view state. Any page that contains an apex:form tag also contains a hidden input field holding the encrypted view state. That blob carries all non-transient members of the page controller and every controller extension, the object graph reachable from those members, the component tree for the page, and internal housekeeping the framework needs. When the user triggers a postback, the browser posts that hidden field back. The server decodes it, rebuilds the controller and its data exactly as the user left them, applies the new input, then runs the requested action. After the action finishes, a fresh view state is encoded and sent back down with the response. This round trip is why a Visualforce controller can hold a wizard across several screens without writing anything to the database. It is also why view state size matters so much. Every postback pays to serialize, encrypt, transmit, decrypt, and deserialize that state, in both directions.
The order of execution on a postback
Salesforce documents a precise sequence for postback requests, and following it removes most of the guesswork. First the view state is decoded and used as the basis for updating the page. Next, expressions are evaluated and the set methods on the controller and any controller extensions run, including setters in controllers defined for custom components. This is where the values the user typed get pushed into controller variables. Then the action that triggered the postback is executed, for example the save() method behind a command button. If that action completes successfully, the data is updated. If the request returns the user to the same page, the view state is refreshed and the result is re-rendered using the latest values. Because setters run before the action method, your action code can safely read the new field values. Because getters re-run during rendering, any property the page displays is recalculated at the end. A common bug is doing expensive work in a getter, since that getter may fire many times across the lifecycle. Moving that work into the action method, which runs once, is the usual fix.
Partial page updates with rerender
A full postback reloads the entire page, which feels heavy for small interactions. Visualforce offers a lighter pattern through the rerender attribute, which is the simplest way to do a partial page update. You put rerender on an apex:commandButton, apex:commandLink, apex:actionSupport, or apex:actionFunction, and point it at the id of the component you want refreshed. The interaction still sends a postback to the server and still runs your controller action. The difference is that only the named region of the page is redrawn from the response, not the whole document. This is the AJAX style of Visualforce, and it predates anything browsers offered natively. apex:actionSupport adds this behavior to events like onchange so a picklist can update a dependent section. apex:actionFunction exposes a controller method as a JavaScript function you can call from your own scripts. apex:actionPoller fires postbacks on a timer. All of them are postbacks under the hood, so they all carry and update view state. Using rerender well is the main way to make a Visualforce page feel responsive instead of reloading constantly.
View state limits and the transient keyword
View state has a hard ceiling of 170 KB per page. Exceeding it throws the familiar "Maximum view state size limit (170 KB) exceeded" error, and the page stops working until you trim it. Even below the limit, a bloated view state slows every postback, because the framework must serialize, encrypt, ship, decrypt, and deserialize it on each round trip. The first tool for shrinking it is the transient keyword. Marking an instance variable transient tells Visualforce that the value cannot be saved and should not travel in the view state. It is ideal for data you only need while building the current response, such as a large list you query to render a table but never reference again on the next postback. Other tactics help too. Query only the fields and rows you actually display, avoid storing big collections on the controller when a fresh query is cheaper, and prefer read-only pages where you can set readOnly on apex:page to relax some limits. Watching view state is a core skill for anyone maintaining Visualforce, and it is the single most common cause of slow or broken legacy pages.
Why postback feels different from Lightning Web Components
The postback model is the clearest way to see why Visualforce and Lightning Web Components feel so different to use. Visualforce assumes the server owns the page. Most interactions send a postback, the server rebuilds state from view state, runs Apex, and returns markup. The browser is mostly a renderer. Lightning Web Components flip that. The component runs in the browser, holds its own state in JavaScript, and reaches the server only when it needs data or an action, usually through an Apex method marked with the right annotations or a wire adapter. There is no view state crossing the wire on every click, so the chatty postback round trips disappear. This is why LWC pages can feel snappier and why their performance profile is so different. None of this makes postback wrong. Plenty of working orgs still run Visualforce pages built on it, and Salesforce continues to support them. The practical guidance is to understand postback when you maintain or debug existing Visualforce, and to reach for Lightning Web Components when you build something new, because the newer model fits modern interaction patterns better.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Postback Request.
Hands-on resources to go deeper on Postback Request.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What triggers a Postback Request on a Visualforce page?
Q2. What happens server-side when a Visualforce Postback Request arrives?
Q3. How does the Visualforce postback model differ from Lightning Web Components?
Discussion
Loading discussion…