About 60 percent of its users enter Parcel Details
through the search page. The search page calls out to a SOAP service with query and then it’s returned a
JSON payload of results.
If there is a single result it bumps you out to the account, if there are multiple it displays a table of
results, and if there are none it tells you so. This is relatively straight forward workflow.
Why then does this page require almost 500 KBs of data, 19 HTTP requests, and 1.74 seconds to render!?!
The answer is that it was originally built using rapid application tools from a vendor. These tools offered a
drag and drop interface for UI elements like the search box and results table.
They also offered a GUI for attaching these UI elements to client-side actions like querying a SOAP service
and server-side actions like gathering data for a list of accounts into a results table.
Unfortunately, these UI elements and the framework that supported them required the inclusion of a license
page for the UI elements to function.
The solution to this problem required a lot of repetitive work. But replacing all the vendor’s UI elements
and data formatting methods resulted in a significant performance boost for Parcel Detail’s search page.
By choosing a specific search result that was ambiguous enough to fill out the search results table I found a
sort of stress test for this page. Thanks to the removal of the vendor’s UI elements the rebuilt search page
has an order or magnitude fewer DOM nodes than the original.
From 500 KBs this page is now slimmed down to 218 KBs, from 19 HTTP requests it’s now at 12, and from a 1.74
second page load time we’re down to 881 milliseconds.
It’s always difficult to justify refactoring an existing application but when you’re working with a web app
where performance gains are this accessible it almost feels like malpractice not to try.