Thomas August Ryan

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!?!

Dependencies

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 from the vendor and series of vendor specific JavaScript and CSS libraries that had to be included on every page for the UI elements to function.

Road Blocks

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.

Google’s PageSpeed Insights Benchmark Before/After

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.

Chrome Inspect DOM Stats Before/After

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.