Auditing Your Front-End for Performance and Scalability

Transcript

1. Auditing The Front-End for Performance and Scalability From 50 Shades of Grey to 5
2. Hi I'm James! James Wilkinson is the Executive Director of Full Stack Toronto; a non-profit providing intermediate and advanced education for web professionals. James has worked for Canada's largest retailers including Loblaws, Cineplex, Indigo, and Walmart. James is passionate about bringing together all aspects of the web from business, user experience, and technology to deliver the best experience online and off. In his spare time, James enjoys board games with friends and traveling the world James Wilkinson/Web Professional
3. WHY AUDIT YOUR FRONT-END? ∠
4. @jerw 4 Key Reasons to Audit 7 Reduce Technical Debt Many large projects have been iterated on over and over again, multiple package managers, a giant list of dependancies, and you're left with what many developers would call spaghetti code. Auditing will help you identify the areas of your code that you can fix to reduce your technical debt. 5 Performance The performance of your site is key to it's success. Stats show that slow performing sites don't convert well compared to those that are performant. Engaging in an audit of your front- end is going to identify areas of improvement to the UX and speed of your application. = Maintainability Bringing on a new developer to a messy code base isn't an easy task, asking them or a seasoned developer to add a new feature on top of your technical debt can be an impossible task. Completing the audit will leave your code in a state that anyone can come in and hit the ground running. G Scalability Architecture decisions are often made by picking what's cool and new at the time, then down the road you realize it can't do what you need it to do anymore, preventing you from adding new features. Following the patterns you will learn through auditing you will make better architecture decisions that take into consideration performance and scalability.
5. @jerw the time a user expects to see a change after an interaction, such as tap or click 100ms In 2006, the average online shopper expected pages to load in 4 seconds or less. Today, almost half — 49% — expect load times of 2 seconds or less, and 18% — one out of five — expect pages to load instantly. 2s the average revenue loss for an hour of downtime according to a survey of 300 companies conducted by TRAC Research $21,000 Sobering Stats Reducing site load times by 1sec has resulted in 3-10% increases in conversion across multiple case studies of e-commerce businesses 3-10% 5
6. ∠ HOW THE BROWSER WORKS
7. Request to Server Once you hit enter your request is sent to the server and the server returns your HTML. D CSSOM Formed After the DOM has been created the browser then downloads and parses all of the CSS and creates the Cascading Style Sheet Object Model a DOM Formed & Image Download Once the server has returned the HTML the browser then parses it and creates the Document Object Model Ư Render Tree Formed Once the DOM and CSSOM are ready the browser then matches them together and creates coordinates for where to put all the content on the page, this is placed into what's called the render tree. q The Journey from URL to Website www
8. Layout occurs Once the render tree is formed the browser starts to place all of those elements in the correct spots in a process called Layout fin First Painting Occurs Once the Layout phase is done styles are then made visible through a process called Painting A Script Manipulation Any of these processes can be interrupted by your scripts, so the browser has been downloading them this whole time waiting to execute them incase they change the DOM or CSSOM Y Repaint, Reflow, Repeat A repaint will occur if your scripts changed a style that doesn't change the position of an element. A reflow will happen if your scripts move content on the page or add new content to the page. A
9. ∠ AUDITING TOOLS
10. @jerw 10 Tool Demos « Web Page Test Use webpage test at 5Mbps and at a location near your user base but not in the same city as your data centre. Style Stats Use Style Stats to get a visual of your CSS files to see where you have too many colours, too many fonts, and other fun stats. Google Developer Tools Google Page Speed Insights provides you with your speed score as seen by Google. Chrome Dev Tools has hidden features to help you spot problems. Continuous Integration Tools Find tools that work into your build such as code linters, automated tests and report builders.
11. HOW TO FIX , SCALE, AND STAY THERE! ∠
12. @jerw 12 Steps to Clean Up Your Mess 01 CSS Make CSS the first thing to download Reduce nesting, speeds up CSSOM Load only what is needed for the page 02 JavaScript Reduce complexity Avoid manipulating styles async as much as possible Only load what is needed for the page 03 Images JPEG Quality of <50 and Simplify Images Use Image Sprites and SVGs for UI Lazy Load and Cache 06 Budget Budget load times in ms and s for sections of the app, prioritizing the user experience. 05 Colours Reduce colours Properly nest and inherit Increase contrast 04 Web Fonts Reduce unneeded characters Don't apply faux effects Reduce sizes, weights, and families
13. @jerw 13 A Paradigm for Performance and Scaling Google Developers RAIL Performance Model R A I L Response Respond to the user in under 125ms to let them know what they did has triggered something in the application. After 500ms provide user feedback. This "perceived" performance can go a long way. Animation Every time the user scrolls or triggers an action it should be smooth in the browser at 60fps. Animation is more than just CSS and JS animations, attaching code to scroll events for example can drop your frame-rate and make the user start to see jank. Idle Maximize the time the application is doing nothing so that it is doing something, such as preloading more content for when the user clicks "Load More" Load Deliver content in under 1000ms, you don't have to deliver the entire page in 1s but the user should see something substantial.
14. @jerw 14 Bringing it all Together for Scaling Maintainable Code When your code base is in a maintainable state without errors and performance bugs you're able to start adding new features with ease. Productivity Now that your code base is clean, automated, and you know exactly what you're developing , you can start to be more productive, focusing on making good clean code. Budgeting A performance budget along with a good user story and UX will help you make better decision about your architecture . Feedback Through monitoring you application you will always be on the pulse for when things have started to not perform for you users and with the clean code, budget, and how productive you are , you can now respond faster and more efficiently.
15. QUESTIONS?
16. Thank You! Please stay in touch! Contacting James Please feel to reach out to me through twitter or linkedin. I am open to speaking opportunities, consulting, playing board games, and finding the local must do's in your city! @jerw TWITTER Tweets on performance, leadership and board games. /in/jamwilk LINKEDIN Connect with me professionally for new projects. jerw.ca PORTFOLIO Check out my work with other retailers and businesses.
17. @jerw 17 Appendix Sources WebPagetest Documentation - https://sites.google.com/a/webpagetest.org/docs/ SOASTA "Conversion Impact Score: How to Use Yours to Deliver Better User Experiences" - https://www.soasta.com/whitepapers/ Tammy Everts "Time is Money - The Business Value of Web Performance" Preview Edition -https://info.soasta.com/eBook-Business-Value-of-Web-Performance.html Neilson "The Future of Grocery - E-Commerce, Digital Technology and Changing Shopping Preferences Around The World" - http://www.nielsen.com/content/dam/nielsenglobal/vn/docs/Reports/ 2015/Nielsen%20Global%20E-Commerce%20and%20The%20New%20Retail%20Report%20APRIL%202015%20(Digital).pdf Google "PageSpeed Tools" - https://developers.google.com/speed/pagespeed/ Google Developers "The RAIL Performance Model" - https://developers.google.com/web/tools/chrome-devtools/profile/evaluate-performance/rail?hl=en Frontend Babel "What Every Frontend Developer Should Know About Webpage Rendering" - http://frontendbabel.info/articles/webpage-rendering-101/ Friendly Bit "Rendering a web page - step by step" - https://friendlybit.com/css/rendering-a-web-page-step-by-step/ https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-tree-construction?hl=en Tools ESLint - http://eslint.org/ Grunt AMD Check - https://www.npmjs.com/package/grunt-amd-check CSSLint - https://github.com/CSSLint/csslint/wiki/Command-line-interface StyleStats - http://www.stylestats.org/ WebPage Test - http://www.webpagetest.org/ Google Page Speed Insights - https://developers.google.com/speed/pagespeed/insights/ Chrome Dev Tools - https://www.google.com/chrome/ Photographs Copyright James Wilkinson - All Rights Reserved Presentation Copyright James Wilkinson - Creative Commons Share-Alike Attribution