Day 1, Monday
Several tutorials, the main things that were learned:
- Caching strategies with Ajax via LocalStorage - Google search results
- Tools for debugging Web Performance and UX
- Webpagetest.org
- Sitespeed.io
- ngrok - super good for sharing local URL and having secure tunnel
- Tampermonkey
- SpeedCurve
Day 2, Tuesday
General keynotes and talks. Introduction talks were not that great. Got some cool swag and a lot of the online tools for monitoring, chat support, load testing are great. I wonder how our departments are testing out these tools to find the best-of-breed. This makes me reflect if we are making the most of the slew of front-end tools at our disposal for review.
Monitoring as a Service talk by James Turnbull
Wrong metrics, should not be measuring things like disk, load, and space. Although that's not bad to know, it's not really actionable besides the fact that based on some criteria (CPU load > 80%), that you log in and check the server is okay. But if you measure things based on how they impact business and customers, it's trivial to go to C-level executive and show how these reports are effecting these things so change can happen where needed.
- Should be measuring:
- Business metrics (payment system)
- Reach out to customers and see what they value (performance of data coming to view and working with it on large data sets)
- Change the accountability
- Usually with Ops
- Make it an objective of your team to own a specific metric for the area of Application Development
- From a DevOps perspective, Provide an API
- Not just a ticket, so people can do it themselves to submit issues
Ilya Grigorik - There is a client-side proxy (ServiceWorker) in your browser!
Ilya works for Google and I've come across his videos about web performance. This talk explores the use of a new feature available mostly in Chrome and Firefox called ServiceWorkers.
What are ServiceWorkers?
- Runs on a separate thread
- Is ServiceWorker ready?
- Works in Chrome
navigator.serviceWorker
- Registration is asynchronous
- Can fulfill requests if client is not connected
onfetch
event: contains all meta data for requestevent.request
event.request.headers
- and more
- Can modify and create a response depending on request
This can be a powerful foot gun
Some use-cases
- Fetching/Writing to local cache
- Enforcing a 3rd party lib with a Performance SLA (Service Level Agreement)
- Request timeout after a certain time
- MD5 the content, send it back after the request (
requestURL?content=<contentHash>
), getting the diff, and writing to cache. Enable new caching schemes, delta delivery - If
requestUrl === /article/1234
, also fetch the 2nd page of this and save to cache. This is dope
- Some API
event.respondWith
can have multiple responses in an array
- Notifications
- push messages outside of the Web Application
onnotificationclick
to do something once they view
Crafting Performance learning tools
Allison McKnight (Etsy)
- Providing context for alerts
- What code was deployed since the alert happened
- Know what to measure
- API response times, as this effects perceived performance of how UI is functioning
Look into
- Logster - generating metrics from logfiles
Resource hints - cluing the browser in
Yoav Weiss (Akamai)
- Costly if you preload and don't use the asset
- What's a preloader?
Sidenote
- Really just want to work on creating a Docker container
- Working on this Ghost blog deployed to Heroku right now
- There's a filmstrip view in Chrome under Network tab. Check Canary and enable experiments for Dev Tools: https://developers.google.com/web/updates/2015/07/23/devtools-digest-film-strip-and-a-new-home-for-throttling
Action
- Evaluate what is being monitored in our data endpoint APIs
- Since our UI works directly with data endpoint APIs, what else are direct dependencies that the UI works with that we can provide alerts for so that we can be proactive with whomever we need to get in contact with?
- Check out
grunt-perfbudget
and how it ties into WebPageTest