Current Best Practice in Front End Ops
Alex Sexton gave a name to that big part of our life that we Front-End folks didn’t previously have a name for–Front-End Ops–the knowledge, techniques and practices we use to make faster Web sites and applications, monitor errors, and build and deploy our work.
But nearly two years on, and with developments like HTTP/2, what’s the state of Front-End Ops? Who better to tell us than the guy who came up with the name in the first place?
Quick recap: Alex’ article appears in Smashing Mag in 2013; FeOps conference in 2014; then people starting hiring roles called frontend ops… naturally naming front-end ops was the hardest part.
So what is front-end ops? Serving web pages is really hard. Front-End Ops is the collection of things you can do to make serving web pages easier.
It frees other devs from having to think about deployment stuff all the time. Developers split time between writing their app, and working on a great deal of other stuff which is not the app but still has to be done to get the app live.
FeOps also addresses the problem where it’s considered normal for frontend developers NOT to be monitoring their application in production. For backend devs that would be insane, so why is it normal for frontend? Particularly now that app logic is being pushed to the client via client-side MVVM/MVC/etc.
Backend programmers habitually automate stuff like error logging, lifecycle logging, application measurement over time (eg. is the app getting faster or slower?)
Performance is the basis of UX; speed is how we measure that. Everything can be measured and tracked, but it’s important to read that information correctly.
Tools not rules.
Make computers do the hard work. Use tools to evaluate things you are concerned about. There are testing tools for pretty much everything.
So…
Step 1: forget everything you know because it’s wrong. All the stuff yslow taught you is wrong.
Step 2: it’s probably the network
Step 3: read Browser Networking by Ilya to fix that…
(missed the others)
Then http2 will come along so we’ll have to forget it all over again!
Use Chrome dev tools to simulate slow networks. “If you throttle everything to 3G all the time, you’ll do a pretty good job of fixing speed problems…”
Theoretical graphs (timelines):
- show the load time of different devices on a scale (ie. Laptops are quicker than mobiles..)
- show the load time of different geographical regions
- show the load time of different network types (wifi, 3g..)
Theoretical graphs:
- plot the load times of desktop and mobile separately
Measure twice, optimise once!
Make a dashboard. Get this stuff visible and easy to read:
- speed index over time (…and then mark commits/deployments)
- graph your competitors speed index over time!
- Page weight over time
- File requests over time
- Errors IF YOU TAKE ONE THING AWAY… log errors! eg. New Relic
- Build time over time / general speed of tools
- Cache everything – don’t do the same thing twice
Speed of development = developer happiness.
Use component libraries.
- They let you focus on re-use, adaptability, performance, test things thoroughly, etc…
- Use your best days to build up your components, so you don’t ruin your app on your worst days.
- Build responsiveness and accessibility into your component library.
- Combine documentation and code samples
- bonus: you get consistency for internal apps
How to make one:
- choose a preprocessor (they liked kfcss for light preprocessing, Suit CSS for scoping styles and linting them)
- add your own tests and checks – eg. CSS Colorguard, you can test css!
- Alex created a tool that converts :hover to .pseudo-hover so they were easier to test. Don’t ship that CSS, it’s just for testing.
- Tool to automatically check in a screenshot of the changes that result from code changes.
- Then… convert your CSS components into JS components (for your JS app) – that is, template it. Never use the patterns directly!
Spare no expense in your tooling! Automate everything, cache everything!
Future considerations: http2 support, async loading, non-js dependencies, web components…
The ultimate idea here is to have machines take the load off the humans, so they can focus their energy on the people using the application rather than the application itself.
(refer to slides for the huge list of tools)
Q&A
Q: are there any really good resources to learn the deep depths of Chrome Dev Tools.
A: follow talks from Addy Osmani and Paul Irish, they do a good job showing off the shiny stuff.
