Open Camps is a huge open source conference that is going on right now at the United Nations with over 30 main topics to choose from. I attend Open Camps this past weekend to attend the Web Performance Camp as well as Apps Camp. I only stayed for about 2/3rds of each of these, but even so I still picked up on a bunch of interesting information.
So, You've Decided On 'API First'
I know just enough about APIs to skim the surface, but I wouldn't say I know what I'm doing. Tim stepped through the difference between REST APIs (considered resource focused: /order/12 ) and RPC (primarily method focused: /getorder). From what I gathered, the differences seem to just be about organization, but it seemed that the preference might be for a REST setup.
One of the main ideas of his talk was to make sure you're setting yourself up in a good position to be able to scale if you need to. So, if right now the data is only feeding your website, you might still want to have everything be functional enough to also serve your apps that might come as well from the same API.
Other things that were spoken on were:
- Authentication: three types, token is hardest to set up but could easily be revoked if needed. You would easily know both the app and the user of requests. Basic auth is suggested if you are the user (your product to your product).
- Errors: use HTTP statuses.
- Hypermedia: Basically makes accessing relevant data that might appear in different areas more easily by actually providing an associative link to the data, or even including it all in the request rather than having to do it manually.
- Versioning: try not to. Additive changes are easy.
Firebase for Fun & Profit
This talk was given by Nitya Narasimhan who is a tremendous community advocate. Firebase is a software as a service that is set up to make your backend easy. It is not open source but could potentially leg up a lot of other great projects that would be. Nitya calls it the "first step as a startup". Nitya's slides are excellent and available here.
The open source version of this (for the record) seems to be RethinkDB and Horizon, though I didn't stick around for that talk.
Web Performance Camp
The organizer of Web Performance Camp, Sergey Chernyshev has an excellent knowledge and understanding of web performance. The day was set up with two main talks that he gave, and then we decided on some open topics that we would like to discuss in small groups.
Talk: Tools of Speed
Sergey outlined some of the ways you would determine if your site stands up to the Rules and Best practices of performance:
- PageSpeed Insights
- GT Metrics
Then he discussed the differences between Synthetic testing and Real User Management. Which, as you can imagine, is that synthetic is manufactured testing environments, while RUM actually employs real users. Because of this it is a great way to predict money made from performance benefits; however, RUM can be more expensive. Aparently there is a service called 'Cedexis' that might offer free RUM testing.
Browser Profiling can also be completed to see how the browser is interacting w/your code (Chrome Dev Tools, ex).
As for the Optimization, they can be divided into five categories:
- Build Process (Grunt/Gulp/etc) - Combine js/css, manage URLs, Modular, JS, OOCSS, Optimize images.
- Embed Quality Testing (ESLint/CSS Lint) - Ensure best practices are followed, Set a performance budget with grunt-perfbudget.
- Image Optimization (JPEG Mini/Compressor.io)
- Page Loading (require.js/Lazy loading/ picture-fill)
- Operational (gzip, cache, CDN, FEO)
Image Compression (breakout)
- Lossless (meta data/ etc)
- Lossy (JPEGmini, etc)
Apparently there are different types of JPEGs now, moz-jpeg and web-p? That seems interesting to me.
Bottom line here is you'd want to develop a 'pipeline' that does all the magic to your photos when they are uploaded. It seems that some, if not most, CDNs offer this sort of thing as a added service. (Saving for web in photoshop is not enough.)
Designing for Speed with Progressive Enhancement
I loved this talk by Sergey, which was about how to involve performance into the design phase of an project.
- wpostats.com has a good bit of metrics that can put dollar bills (or something like that) to performance gains and losses. Such as: The Trainline reduced latency by 0.3 seconds across their funnel and customers spent an extra £8 million (~$11.5 million) a year.
- whatdoesmysitecost.com helps you determine.... what your site costs in different countries.
- Desiging with Progressive Enchancement Book.
Steps in Performance Thought Loop.
- Verify Destination (Core branding / colors/ breadcrumbs) - Inline CSS and logo in 1st 14kb.
- Primary Content - No JS, CSS, just HTML/Images.
- Allow Interaction - Skeletal CSS, async JS
- Secondary Content - All CSS, above fold images/fonts, ajax in content.
- Invisible Tasks (Below the fold, analytics, everything else) - The rest...
- Acknowledge Action. (Make sure users know their action is doing something. ie: 'save' button turning to 'saving...') - Perhaps even do a fake transition for the user. ...and repeat!
"Spinners are not progress indicators. They are slowness indicators."
I loved the idea of incremental mockups, actually showing each of these stages so the team can see how the page would be prioritized for performance.