Frontend Performance Optimization and Testing

tmp.txt

Why do I need frontend testing?

There are untold number of subtle
errors that can occur on the frontend.

Minor CSS changes that throw things off
Changes to JS files that break things
Aggregates changing when not necessary
Performance regressions


Additionally, frontend development is
becoming more critical as the trade matures.

We need the same testing abilities
that the backend has had for years.

Testing page load times
Testing render speeds
Sticking to a performance budget
Verifying visual changes
Accountability for code changes

http://www.seleniumhq.org/
https://code.google.com/p/selenium/
https://amsterdam2014.drupal.org/session/automated-frontend-testing.html
http://www.slideshare.net/neilcrosby/automated-frontend-testing
http://www.slideshare.net/rteijeiro/frontend-automated-testing


Functional Testing
-> CasperJS
	Casper allows for scripted actions to be tested. It uses PhantomJS under the hood.

	Run the same test with multiple screen sizes.
	Test complex features or components.
	Automate complex user actions.
	Test content creation, transactions, other features.
	Keep an eye on problematic pages.
	
	https://www.youtube.com/watch?v=3qNdxjfgbAg
	http://fourkitchens.com/blog/article/series/casperjs
	http://fourkitchens.com/blog/article/simulate-user-actions-casperjs
	http://www.helpscout.net/blog/functional-testing-casperjs/


	https://github.com/rupl/frontend-testing

	
Performance Testing
-> Automating PageSpeed
	Google has a service called PageSpeed Insights that grades your site and boils down tons of factors into a "speed index"
	Testing sites can be automated. Get your API key first (https://developers.google.com/speed/docs/insights/v1/getting_started#auth). 
	
	PageSpeed API is documented quite thoroughly, but there's also a grunt plugin
	-> https://github.com/jrcryer/grunt-pagespeed
	
	Una Kravets wrote up an excellent walkthrough for gulp + pagespeed + local development
	http://una.im/gulp-local-psi/
	
	See the Four Kitchens frontend performance training for an alternate implementation
	-> https://github.com/fourkitchens/frontend-perf/blob/398d19071e5eaff874e05b9ed43059ccf94a7a1d/gulpfile.js#L306-L338
	
	

-> Phantomas
	Phantomas is a PhantomJS-based web performance metrics tool
	It gives you loads of data about how the frontend of your website is performing.
	
	# run a basic report
	$ phantomas --url http://gruntjs.com

	# set viewport dimensions, generate images of rendering process
	$ phantomas --url http://gruntjs.com --viewport=320x480 --film-strip

	# assert a test for total number of requests
	$ phantomas --url http://gruntjs.com --assert-requests=20
	
	-> grunt-phantomas
	This grunt plugin is not just a wrapper for running the tool.
	It provides detailed reports that track your data over time, allowing you to identify trends using dynamic charts that update themselves each time you run the grunt task
	
	# examples/grunt/phantomas
	$ grunt phantomas:default

	# run report and generate screenshot
	$ grunt phantomas:screenshot

	# test for certain values. this might cause failure!
	$ grunt phantomas:requests



Performance Budgets
	The idea is simple: performance budgets are just like a monthy expense budget. We should keep track of how fat our sites grow over time.
	-> https://timkadlec.com/2013/01/setting-a-performance-budget/
	
	grunt-phantomas has performance budget features that visualize over-budget metrics that you set.
	
	grunt-perfbudget
	Tim Kadlec, who first suggested performance budgets, released this tool to help teams meet their goals.
	grunt-perfbudget relies on the immensely useful WebPageTest API to enforce a budget.
		-> http://www.webpagetest.org/
	WebPageTest.org and its API are much more flexible than PhantomJS tools, because it can leverage multiple browsers, geographic locations, and network speeds.
	
	# examples/grunt/perfbudget
	$ npm install

	# run report
	$ grunt perfbudget
	
	

CSS Regression testing
-> Wraith
	Wraith is the easiest way to take screenshots of two environments, producing a visual diff.
	
	# examples/wraith
	$ gem install wraith

	# run the capture process
	$ wraith capture demo

	# view results in the browser
	$ open shots/gallery.html

	Multiple tests

	Wraith handles one comparison per config file.

	However, it has support for multiple configs, so several config files in one repo allows for multiple comparisons.
	
	https://github.com/BBC-News/wraith#wraith
	
	
	
Automating Tasks with CI
	The Basics
		Everything outlined in this section requires two key ingredients:
			Continuous integration (CI)
			Git hooks - http://git-scm.com/book/ch7-3.html
			
	Trigger Jenkins builds by pushing to GitHub
		http://fourkitchens.com/blog/article/trigger-jenkins-builds-pushing-github
		
		You push to GitHub master branch (or merge PR)
		GitHub pings your CI server using post-receive hook
		"Yo Jenkins, the repository was updated!"
		CI server pulls the new code to your staging area
		
		Although fairly simple in application, the post illustrates the basic concepts underlying all tasks involving Jenkins.
	
	Use git hooks to test before pushing code
	
		Git can be configured to automatically run tasks before or after many of its operations.
		
		pre-commit hook that runs jshint on your JavaScript.

		pre-push hook that runs performance tests on your local. Helps enforce performance budgets.

	Travis CI
		Simple config via YAML file
		FREE for open-source projects
 
 
 http://www.smashingmagazine.com/2013/06/front-end-ops/
 https://speakerdeck.com/addyosmani/automating-front-end-workflow
 http://yeoman.io/blog/performance-optimization.html
 https://drupalize.me/blog/201410/using-remote-debugger-casperjs-and-phantomjs