1 / 67

Effective Web Performance Optimization Strategies for Scaling Your Website

In the ever-evolving landscape of web technology, optimizing web performance is crucial for businesses to thrive. This guide explores key strategies to enhance speed and efficiency, from reducing HTTP requests to utilizing CDNs and adaptive performance techniques. Understand the entire lifecycle of a web page request, the importance of minimizing latency, and the trade-offs involved in various optimization practices. With insights drawn from industry best practices and real-world case studies, this resource empowers developers and decision-makers to improve user experience, enhance scalability, and drive profitability.

coy
Download Presentation

Effective Web Performance Optimization Strategies for Scaling Your Website

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Performance Optimization: scaling the witchcrafts Xiaoliang “David” Wei • www.facebook.com/DavidWei

  2. Agenda

  3. A web site is a distributed system • A web page request can involve many parties: • Client browser • Web server (and backend caches, DBs) • Content distributor

  4. Life of a web page request • From a user clicking event to the presentation of the page at the browser: Browsers Web Servers

  5. Life of a web page request • From a user clicking event to the presentation of the page at the browser: • time to send to and receive from web server through Internet Browsers • ½ NetTime Web Servers

  6. Life of a page request • From a user clicking event to the presentation of the page at the browser: • time to send to and receive from web server through Internet • time to generate HTML at web server Browsers • ½ NetTime Web Servers • GenTime

  7. Life of a page request • From a user clicking event to the presentation of the page at the browser: • time to send to and receive from web server through Internet • time to generate HTML at web server Browsers • NetTime Web Servers • GenTime

  8. Life of a page request • From a user clicking event to the presentation of the page at the browser: • time to send to and receive from web server through Internet • time to generate HTML at web server • time to download multimedia contents and to render the page at browser Browsers Content Distribution Network (CDN) Render Time • NetTime Web Servers • GenTime

  9. Web service: a distributed system • Questions: • Scalability • Consistency • Performance Browsers Content Distribution Network (CDN) Render Time • NetTime Web Servers • GenTime

  10. Web Performance Optimization

  11. Performance impacts business • Google: +400ms => -0.6% daily search per user • Bing: +500ms => -1% click, +1.2 sec time to click (2x) • Facebook: user session time stays the same, faster => more page views

  12. Status of web performance optimization • Decade-old protocols: TCP, HTTP, HTML • Fast-changing industry: browser war • Optimization is mostly witchcraft • Some rules emerging (e.g. Steve Souder’s books) • Large scale optimization is difficult

  13. Web performance: TCP / HTTP / HTML • TCP overhead: 3-way handshake, slow start => persistent conn • TCP performance: depends on loss rate and distance => multiple conn • HTTP persistent connection: maximum 2 per server • HTTP Pipeline:failed, sequential loading • HTML: very limited description for priority/concurrency • => Big resources, multiple connections are preferred

  14. Web performance: Browsers • most browsers blocked on JavaScript download / execution; some blocked on Stylesheet • Stylesheet application might be slow • JS execution might be slow • Maximum connections per browser • => The less the better

  15. Web performance: “best practice rules” • Minimize HTTP requests • Gzip resources • Preload Components • Reduce DNS Lookup • Split Requests Across Domain

  16. Web performance: trade-offs • Minimize HTTP requests  Increased unused bytes • Gzip resources  Increased CPU utilization • Preload Components  Increased bandwidth cost • Reduce DNS Lookup Split Requests Across Domain • Split Requests Across Domain  Reduce DNS Lookup

  17. Web performance optimization • Improve speed • Reduce cost (both latency penalty and $ cost) • Operate on the equilibrium • Easy for a single page, hard for large scale systems

  18. Performance optimization: challenges • Large scale • Viral growth • Agile development

  19. Challenges: Large scale • Thousands of servers in multiple locations • Millions of users per minute • Billions of page views served per day • Hundreds of thousands of developers • Thousands of web resource components

  20. Challenges: Viral growth • Concept of “Platform”: A single web page can have many features from many developers • A feature could be adopted by millions of users in a day • Features come and go

  21. Challenges: Agile development • Fast release, allow mistake, fix quickly • Frequent code base changes • Continuous release

  22. Web performance: the gap • Large scale • Viral growth • Agile development “Reduce # of HTTP Requests” Package JS/CSS; Sprite Image Large Scale Operation

  23. Web performance: fill the gap • Large scale • Viral growth • Agile development “Reduce # of HTTP Requests” Package JS/CSS; Sprite Image Interface, Model, and Infrastructure Large Scale Operation

  24. Adaptive Performance Optimization

  25. Adaptive Performance optimization • Example: “Best Practices for Speeding Up You Web Site” – YUI Rule 1: Minimize HTTP Request • Combined files: package Javscript and Stylesheets • Sprite Images • …

  26. Performance optimization: Case Study • Day 1: Some smart engineers start a project! <Print css tag for feature A> <Print css tag for feature B> <Print css tag for feature C> <print HTML of feature A> <print HTML of feature B> <print HTML of feature C> … “Let’s write a new page with features A, B and C!”

  27. Day 2: Some smart engineers read YUI blog and says… <Print css tag for feature A> <Print css tag for feature B> <Print css tag for feature C> <print HTML of feature A> <print HTML of feature B> <print HTML of feature C> … “A & B & C are always used; let’s package them together!”

  28. Day 2: Awesome! <Print css tag for feature A&B&C> <print HTML of feature A> <print HTML of feature B> <print HTML of feature C> …

  29. Day 3: feature C evolves… <Print css tag for feature A & B & C> <print HTML of feature A> <print HTML of feature B> If (users_signup_for_C()) { <print HTML of feature C>} …

  30. Day 3: <Print css tag for feature A & B & C> <print HTML of feature A> <print HTML of feature B> If (users_signup_for_C()) { <print HTML of feature C>} … A&B are always used, while C is not. ..

  31. Day 4: feature C is deprecated <Print css tag for feature A & B & C> <print HTML of feature A> <print HTML of feature B> // no one uses C { <print HTML of feature C>} …

  32. Day 4: we start to send unused bits <Print css tag for feature A & B & C> <print HTML of feature A> <print HTML of feature B> // no one uses C { <print HTML of feature C>} … It is hard to remember we should remove C here.

  33. One months later… <Print css tag for feature A & B & C & D & E & F & G…> if (F is used) <print HTML of feature F> <print HTML of feature G> if (F is not used) { <print HTML of feature E>} … Thousands of dead CSS bytes in the package.

  34. Performance Optimization: the gap • One months later… <Print css tag for feature A & B & C & D & E & F & G…> if (F is used) <print HTML of feature F> <print HTML of feature G> if (F is not used) { <print HTML of feature E>} … “Reduce # of HTTP Requests” Package JS/CSS; Sprite Image Large Scale Operation

  35. Adaptive Static Resource Optimization Fill the gap: • Build interface to separate requirement declaration and delivery of static resources • Model the trade-off of optimization • Infrastructure to analyze requirement logs and globally optimize the delivery performance “Reduce # of HTTP Requests” Package JS/CSS; Sprite Image Interface, Model, and Infrastructure Large Scale Operation

  36. Adaptive Packager: Designs

  37. Interfaces • Back to Day 1: require_static(A_css); <render HTML of feature A> require_static(B_css); <render HTML of feature B> require_static(C_css);<render HTML of feature C> <deliver all required CSS> <print all rendered HTML> Separate Declaration from actual Delivery Requirement Declaration lives with HTML Global Optimization on Delivery

  38. Packager: Global JS/CSS Optimization Offline analysis Online process require_static(A_css); <render HTML of feature A> require_static(B_css); <render HTML of feature B> require_static(C_css); <render HTML of feature C> <deliver all required CSS> <print all rendered HTML> Usage Pattern logs Packaging algorithm “Optimal” packages

  39. Packager: Usage Pattern Logs Usage Pattern logs

  40. Packager: Cost/Benefit Model • To package two files A & B: • “Cost”: for page requests that only uses A, we waste the bytes of B, vice versa • “Benefit”: for page requests that uses both A and B: we save one round trip • Bytes / Bandwidth ~ Latency • “Profit” to be maximized: Benefit – Cost

  41. Packager: Cost/Benefit Model • Assume: latency = 40ms, and bandwidth = 1 Mbps • A+B: 40ms * 11.131M • No cost, pure gain. • Definitely package

  42. Packager: Cost/Benefit Model • Assume: latency = 40ms, and bandwidth = 1 Mbps • B+C: 40ms * 11.1M • – 300B / 1Mbps * 0.031M • Benefit larger than cost • OK to package

  43. Packager: Cost/Benefit Model • Assume: latency = 40ms, and bandwidth = 1 Mbps • B+D: 40ms * 1K • – 2K / 1Mbps * 11.13M • Cost larger than benefit • Don’t package

  44. Packager: Optimal packages • Pkg 1: A, B, C • Pkg 2: E, F, G Usage Pattern logs Packaging algorithm “Optimal” packages

  45. Packager: Cost/Benefit Model The weight (count) of each page load The usage matrix (0/1) on the left for m page loads and n resources The package definition (0/1 matrix). P[i,j] = 1 if resource j is in package i. The byte size of each resource

  46. Packager: Cost/Benefit Model The usage matrix (0/1) on the left for m page loads and n resources The weight (count) of each page load Packages for each page load The byte size of each resource Byte size of each package The package definition (0/1 matrix)

  47. Packager: Cost/Benefit Model The usage matrix (0/1) on the left for m page loads and n resources Byte Cost The weight (count) of each page load RT Gain The byte size of each resource The package definition (0/1 matrix)

  48. Packager: Cost/Benefit Model The usage matrix (0/1) on the left for m page loads and n resources The weight (count) of each page load The byte size of each resource The package definition (0/1 matrix)

  49. Packager: Algorithms • Greedy algorithm • Simulated Annealing • Clustering algorithms • … Packaging algorithm

  50. Adaptive Static Resource Optimization Adaptive Packaging / Spriting • Cross-feature optimizations (e.g. search + ads) • Adaptive to change of user behaviors and code developments • Same methodology works for image spriting

More Related