The Page Lifecycle

Analogy categoryAnalogies

Every ASP.NET Web Forms page executes through a well-defined sequence of stages on every single request, known as the page lifecycle: PreInit, Init, InitComplete, PreLoad, Load, control events (like Click), LoadComplete, PreRender, SaveStateComplete, Render, and Unload. Understanding this order matters because ViewState is loaded before Load fires but after Init, and control events fire after Load but before PreRender, so where you place code determines exactly what data is available and whether your changes will actually reach the final rendered HTML.

🏏

Cricket analogy: A Test match follows a fixed sequence of innings — toss, first innings, follow-on decision, and so on — and a captain who declares before understanding where in that sequence they are will make a costly mistake, just as a developer who sets a control's Text before ViewState loads will see it silently overwritten.

Key Lifecycle Stages: Init, Load, and Beyond

Page_Init fires first and is where the control tree is created and control IDs are assigned, but ViewState has not yet been loaded, so control property values here are still their design-time defaults. Page_Load fires after ViewState and postback data have both been restored, which is why Page_Load is the standard place to read submitted values, populate data-bound controls conditionally, or apply business logic that depends on the current state of the page.

🏏

Cricket analogy: Selecting the playing XI (Page_Init) happens before the toss result is known (ViewState restored), so team composition decisions made at selection time can't yet account for who will bat first — that only becomes clear once play actually begins, like Page_Load.

After all control events have fired, the page enters PreRender, the last chance to modify control properties before their final output is generated, followed by SaveStateComplete (after which further changes won't be persisted in ViewState), Render (which writes the actual HTML to the output stream), and finally Unload, where cleanup like closing database connections or disposing of resources should occur since the page object is about to be discarded.

🏏

Cricket analogy: PreRender is like the final team huddle just before the innings starts — the last chance to adjust batting order — while Render is the actual innings being played out and broadcast, and Unload is the post-match debrief once the game is fully over.

IsPostBack and Lifecycle Decisions

The Page.IsPostBack property distinguishes the very first request for a page (a fresh GET) from a subsequent postback caused by user interaction, and checking it inside Page_Load is the standard pattern for avoiding wasteful or destructive work: data-bound controls like a GridView should only be populated from the database when IsPostBack is false, because on a postback ViewState already holds the previously rendered data, and re-binding would both waste a database round trip and, worse, wipe out user edits like a selected row or typed text that hadn't been saved yet.

🏏

Cricket analogy: Checking IsPostBack is like a stadium announcer distinguishing 'this is the very first ball of the match' from 'this is a replay after a no-ball', so they only re-announce the full team lineups once at the start rather than repeating it after every delivery.

csharp

protected void Page_Load(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
        // Runs only on the initial GET request
        CustomersGridView.DataSource = CustomerRepository.GetAll();
        CustomersGridView.DataBind();
    }
    // On postback, ViewState already holds the grid's prior data/selection
}

protected override void OnInit(EventArgs e)
{
    base.OnInit(e);
    // Control tree exists here, but ViewState has not been loaded yet
}

A very common Web Forms bug is forgetting the IsPostBack check when binding data. If you rebind a GridView or DropDownList on every postback, any selection, sort order, or in-progress edit the user made is silently discarded because the freshly bound data overwrites what ViewState was about to restore — the page will still look correct at first glance but user input quietly disappears.

The page lifecycle runs through fixed stages every request: Init, Load, control events, PreRender, Render, Unload.
Page_Init fires before ViewState is loaded; Page_Load fires after ViewState and postback data are restored.
Control click events fire after Load but before PreRender, affecting when handler-driven changes are visible.
PreRender is the last opportunity to change control properties before the final HTML is generated.
Page.IsPostBack differentiates the first GET request from a subsequent postback in Page_Load.
Skipping the IsPostBack check when data-binding wastes database calls and can wipe out user input.
Unload is where cleanup such as closing connections or disposing resources should be performed.

Practice what you learned

1. In which lifecycle stage is the control tree created, before ViewState has been loaded?

2. Why should data-bound controls typically only be populated when IsPostBack is false?

3. Which stage is the last opportunity to change a control's properties before the HTML is generated?

4. What is the correct place to close database connections or dispose of resources?

5. Relative to control click events, when does PreRender occur?

Was this page helpful?

What Is ASP.NET Web Forms?

Server Controls

Related Study Notes in Microsoft Technologies

Browse all study notes

Microsoft Technologies

Windows 10 / UWP Development Study Notes

.NET · 30 topics

Microsoft Technologies

Windows Batch Scripting Study Notes

Batch · 30 topics

Microsoft Technologies

MFC (Microsoft Foundation Classes) Study Notes

C++ · 30 topics

Microsoft Technologies

Silverlight Study Notes

.NET · 30 topics

Microsoft Technologies

XAML Study Notes

.NET · 30 topics

Microsoft Technologies

WPF (Windows Presentation Foundation) Study Notes

.NET · 30 topics

Topics covered

#NETFramework#ClassicASPNETWebFormsWebPagesStudyNotes#MicrosoftTechnologies#ThePageLifecycle#Page#Lifecycle#Key#Stages#StudyNotes#SkillVeris

The Page Lifecycle