Purging the Search Page
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.
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.
The gain in Google’s PageSpeed Insights from the low 80s before up to 99/100 is quite gratifying.
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.