Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Ten practical ways to improve front-end performance

387 views

Published on

Conference talk presented at PHP South Coast 2017. Ten concrete ways to improve web performance, split between quick tactical wins and longer-term overarching strategies.

Published in: Software
  • Be the first to comment

Ten practical ways to improve front-end performance

  1. 1. @AndrewRota
  2. 2. The web is no longer simply a platform for serving static documents.
  3. 3. Today we can build rich, highly interactive applications on the web.
  4. 4. And while users expect rich interactivity, they also expect performance.
  5. 5. Measure performance Reuse data Load important resources first Manage perceived performance Run less code Anticipate poor connections Parallelize requests Don’t try to do everything at once Only ask for what you need Send content as it’s ready
  6. 6. Tune performance based on data, not guesses.
  7. 7. Types of performance tests ● Synthetic ● RUM
  8. 8. Synthetic performance metrics ● Measure performance in isolation ○ Tools: webpagetest, lighthouse ○ Use real devices if possible ○ Emulate network connections
  9. 9. A developer’s browser/device/network are not necessarily representative of their users.
  10. 10. Common client testing mismatches ● Browser types and versions ● Device CPU power ● Network conditions ○ Bandwidth ○ Latency ○ Intermittent connections
  11. 11. Real User Metrics (RUM) ● CDNs and other services can collect aggregate user performance data ● Data is less detailed, but more accurate ○ But influenced by outside factors. ● Problems will often manifest in the upper 90th percentile rather than the mean
  12. 12. Prioritize resources the user is likely to need first (e.g., above the fold images) before those they won’t need until later.
  13. 13. Deprioritize
  14. 14. Priority matters. If everything is important, nothing is.
  15. 15. Performance, is all about trade-offs.
  16. 16. is the core of the problem we have to solve [...] legitimately difficult problems. is all the stuff that doesn’t necessarily relate directly to the solution, but that we have to deal with anyway. Neal Ford, Investigating Architecture and Design (2009)
  17. 17. We can have essential and accidental performance costs, too. * And often it can be hard to tell the difference.
  18. 18. Know the essential performance cost of features you write.
  19. 19. Look for opportunities to remove accidental performance costs.
  20. 20. (function () { const condition = true; function fibonacci(x) { return x <= 1 ? x : fibonacci(x - 1) + fibonacci(x - 2); } if (condition === true) { window.result = fibonacci(23); } else { window.result = fibonacci(32); } })();
  21. 21. (function(){function b(a){return 1>=a?a:b(a-1)+b(a-2)}window.result=b(23)})(); UglifyJS2 https://github.com/mishoo/UglifyJS2 Closure Compiler https://developers.google.com/closure/compiler
  22. 22. result = 28657; Prepack (experimental only!) https://prepack.io/
  23. 23. Browsers limit the number of HTTP/1.1 requests made in parallel from a single hostname.
  24. 24. Distribute resource requests across multiple domains, allowing the browser to parallelize requests
  25. 25. Distribute resource requests across multiple domains, allowing the browser to parallelize requests … but there’s overhead. New DNS lookup, time to establish connection.
  26. 26. Distribute resource requests across multiple domains, allowing the browser to parallelize requests … but there’s overhead. New DNS lookup, time to establish connection. General guideline: shard across two domains.
  27. 27. But we have a better solution today...
  28. 28. H2 can download multiple files in parallel over a single multiplexed connection.
  29. 29. H2 can download multiple files in parallel over a single multiplexed connection.
  30. 30. Adopt H2 today ● Ensure resources are served via HTTPS ● If you use a content-delivery network (CDN) there’s a good chance it supports HTTP/2 today. ● If you’re already domain sharding, make sure those hostnames resolve to the same IP.
  31. 31. Designing APIs is difficult
  32. 32. How data is requested between browser and server can impact performance.
  33. 33. Imagine using the GitHub API to request the description of a repo.
  34. 34. GET repos/octocat/Hello-World { "id": 1296269, "name": "Hello-World", "full_name": "octocat/Hello-World", "owner": {}, "private": false, "html_url": "https://github.com/octocat/Hello-World", "description": "My first repository on GitHub!", "fork": false, "homepage": "", "size": 578, "stargazers_count": 1405, "watchers_count": 1405, "language": null, "has_issues": true, "has_projects": true, "has_downloads": true, "has_wiki": true, "has_pages": false, "forks_count": 1169, "mirror_url": null, "open_issues_count": 251, "forks": 1169, "open_issues": 251, "watchers": 1405, "default_branch": "master", "network_count": 1169, "subscribers_count": 1544 } { REST }
  35. 35. In a RESTful API, provide mechanisms to request only the data needed.
  36. 36. Alternative API paradigms might provide a better format for selecting only the data needed.
  37. 37. repository(owner:"octocat", name:"Hello-World") { description } { "data": { "repository": { "description": "My first repository on GitHub!" } } }
  38. 38. GraphQL can help prevent over-serving data, and reduce the number of overall requests.
  39. 39. How can you avoid re-requesting data we’ve already downloaded?
  40. 40. ● Caching layers on the server ● Single-page application on the client, share data between routes or components ○ Normalized top-level data ○ Smart client-side caching
  41. 41. A lot of performance is about perception.
  42. 42. 70k https://code.facebook.com/posts/991252547593574/the-technology-behind-preview-photos/ 200 bytes
  43. 43. There’s no one-size-fits-all method for improving perceived performance. Be creative!
  44. 44. “Progressive Web Apps” ● PWAs focus on building web applications that work well in environments with slow, intermittent, or zero network connectivity. ● More than just “offline” support, PWA techniques can provide features of your app even when the network connection is imperfect.
  45. 45. ServiceWorker ● ServiceWorker is browser technology that allows a separate script to run in the browser background, separate from your web site, intercept and handle network requests, and communicate back to your web application. ● You can cache data and other page assets in order to serve them to your web application even if no external network connection is available.
  46. 46. The browser has a lot to do on a single thread when rendering a page...don’t let JavaScript get in the way.
  47. 47. window.requestAnimationFrame() allows you to schedule something before the next repaint.
  48. 48. But what about non-critical JS...how do we ensure it doesn’t block more important work on the main thread?
  49. 49. window.requestIdleCallback() allows you to schedule something when the browser is idle.
  50. 50. window.requestIdleCallback() allows you to schedule something when the browser is idle.
  51. 51. Request > router/controller > request data > prepare view > request data > prepare view > prepare view > flush response
  52. 52. Why make the user wait for the whole page to be done?
  53. 53. “The general idea is to decompose web pages into small chunks called pagelets, and pipeline them through several execution stages inside web servers and browsers.” Changhao Jiang, “BigPipe: Pipelining web pages for high performance” (2010)
  54. 54. ● Streaming HTML ○ HTML Chunked Encoding ○ ob_flush() ● Client-side powered ○ XHR requests for individual components
  55. 55. Request > router/controller > request data > prepare view > flush response > request data > prepare view > flush response > prepare view > flush response
  56. 56. Measure performance Reuse data Load important resources first Manage perceived performance Run less code Anticipate poor connections Parallelize requests Don’t try to do everything at once Only ask for what you need Send content as it’s ready
  57. 57. @AndrewRota

×