Creating a Visualforce page is straightforward but the design considerations matter for performance, maintainability, and the migration path to LWC. The walkthrough below covers the standard sequence for building a new Visualforce page in a Salesforce DX project.
- Decide whether Visualforce is the right choice
Before building a new Visualforce page, confirm Visualforce is the right tool for the use case. For email templates and PDF generation, yes. For new interactive UI scenarios, evaluate LWC first. Document the rationale in the code comments or a design document so future maintainers know why Visualforce was chosen rather than the modern alternative.
- Create the page with a standard or custom controller
From VS Code with the Salesforce Extensions, create a new Visualforce page file with the appropriate API version. Add the apex:page root tag with the controller (standardController for object-based pages, controller for custom Apex controllers, or extensions for the hybrid approach). Add the page content using standard tags. Save and deploy to a sandbox for testing.
- Implement controller logic and reusable components
Write the Apex controller class with the methods the page references: properties, action methods, page references. Cover the controller with unit tests at 75 percent or higher coverage. For UI patterns that recur on multiple pages, extract them into Visualforce Components so the markup stays DRY. Test the page in the sandbox with realistic data, including edge cases (empty data, large data sets, validation errors).
- Deploy and monitor
Promote the page and controller through the standard deployment pipeline. Add the page to the relevant page layouts, custom buttons, or app routing. Test in production with a small group of users before broader rollout. Monitor for performance (view state size, render time) and any errors in the debug logs during the first week. Update documentation in the team's wiki so future maintainers can find the page.
The unique identifier and human-readable label for the page.
The Salesforce API version the page targets, affecting available features and runtime behavior.
The Apex class providing data access and behavior for the page.
Required to create and edit Visualforce pages in the org.
Apex test classes meeting 75 percent coverage are required for production deployment.
- View state has a 170 KB limit. Pages with large datasets in instance variables hit this limit and produce confusing errors at render time.
- Visualforce pages in Lightning Experience run inside an iframe. Some styling and JavaScript behavior differs from the standalone Visualforce rendering.
- Standard Controllers work only with the object they are bound to. Cross-object work requires custom controllers or extensions.
- Apex unit test coverage applies to controllers, not to the Visualforce markup. The markup itself is not test-coverable in the standard way.
- Visualforce pages do not auto-refresh on field changes the way LWC does. Every interaction is a server round trip.