After a report from a user that installing a WordPress plugin adds seconds of load time to their wp-admin, @dereksmart and @ebinnion wanted a way to compare before and after performance metrics for that site.
Because we would be testing a unique set of circumstances on this user's site and because we were more interested in the performance deltas over a short window of time, rather than performance metrics over time, it seemed reasonable to just run many Lighthouse tests and then export the data to CSV for analyzing in Google Sheets. We did the first pass of this manually.
Afterwards, @ebinnion worked on this script to make future testing much simpler.
This script expects that you have the following installed:
- Get Chrome debugging port
- Open terminal window and run
chrome-debug - In the Chrome window that pops up, log in to the wp-admin of the site that you want to test
- After logging in, go back to terminal window where you called
chrome-debugand copy the Chrome debugging port
- Open terminal window and run
- Run Script
- Open new terminal window
- Run script:
index.sh --base_url=base_url --chrome_debug_port=chrome_debug_port [--passes=passes] [--condition_slug=condition_slug] [--output_location=output_location] [--remove_csv_header] [--add_uniqueness_to_url]base_url: This is thesiteurlvalue from the site, where the WordPress installation actually lives. The script will append/wp-adminto the URL to get the wp-admin URL used for testing.chrome_debug_port: See above.passes: How many times should a Lighthouse test be run for each URL? Default is 5.condition_slug: This is used to build the filename and also in the resulting CSV output for analyzing later. Defaults to the timestamp when the script was started.output_location: When set, will output a CSV file to this directory with a filename ofcondition_slug.csv.remove_csv_header: When present, will prevent the CSV header being printed. This is useful for later concatenating multiple runs.add_uniqueness_to_url: When present, will add a query arg to the audited URL. The envisioned use case for this is tying a specific Lighthouse run to a specific cachegrind report that would be generated by Xdebug. For this to work, the expectation is currently that you include%Rin thexdebug.profilter_output_namesimilar to this:xdebug.profiler_output_name="cachegrind.out.%p_%R".