Web Performance
•Download as PPTX, PDF•
0 likes•61 views
Eine durchschnittliche Webseite lädt 2299KB an Daten und macht dafür 100 HTTP Anfragen. Dass Ladezeiten einen immensen Einfluss auf User-Zufriedenheit und Business-Metriken haben, bezweifelt dieser Tage niemand mehr. Aber die Meinungen darüber, welche Techniken Ladezeiten effektiv minimieren, gehen weit auseinander. Dieser Vortrag gibt einen detaillierten Überblick zu den wichtigsten Techniken der Web Performance Optimierung vom Critical Rendering Path bis zu verteilten Caching-Infrastrukturen an einem Beispiel aus der Praxis.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Web Performance
Similar to Web Performance (20)
Recently uploaded
Recently uploaded (20)
Web Performance
- 1. Insert company logo UX/Frontend Web Performance Die effektivsten Techniken aus der Praxis Erik Witt Erik Witt 30.09.2016
- 3. Average: 9,3s Loading… -1% Revenue 100 ms -9% Visitors 400 ms500 ms -20% Traffic 1s -7% Conversions Why performance matters
- 4. What should be the goal? Delay User Perception 0 – 100 ms Instant 100 – 300 ms Small perceptible delay 300 – 1000 ms Machine is working 1+ s Mental context switch 10+ s Taks is abandoned Stay under 1000 ms to keep users attention I. Grigorik, High performance browser networking. O’Reilly Media, 2013.
- 6. Concrete Example A scalable webshop at Expectations: • 2.7 Million Viewers • 300.000 Visitors in 30 minutes • 20.000 Requests per second
- 7. If performance is so important for Business Success ...what causes slow page load times?
- 8. State of the Art The tree bottlenecks Network Backend Frontend
- 9. CSS Render Tree Layout Frontend Performance The critical rendering path Paint Network JavaScript CSSOM DOM <!doctype html> <title>Code Talks</title> <link href=all.css rel=stylesheet /> <script src=app.css ></script> <div> <h1>Web Performance</h1> </div> div { color: green; } h1 { padding: 10px; } <script> elem.style.width = "50px"; document.write("JS is awesome!"); </script> HTML DOM Execution
- 10. Frontend Performance Render and parser blocking Google Developers, Web Fundamentals https://developers.google.com/web/fundamentals/performance/critical-rendering-path/analyzing-crp What to do: • Inline critical CSS and JS above the fold • CSS at the top, JS at the bottom • Load non-critical CSS and JS asynchronously • Rendering the page progressively • Minify, concatenate, compress and cache CSS, JS and images
- 11. Frontend Performance Tools to improve your page load PageSpeed Insights Profiling Minification & Compression Inlining & Optimization Google Closure UglifyJs & cssmin processhtml
- 12. Frontend Performance Applied in the example processhtml Caching 565,9 KB Size: 767 ms Load time: 24 Requests:
- 13. Network Performance Break down of a single resource load DNS Lookup • Every domain has its own DNS lookup Initial connection • TCP makes a three way handshake 2 roundtrips (1 with the new TCP Fast Open) • SSL connections have a more complex handshake +2 roundtrips (only 1 with TLS False Start or Session Resumption) Time to First Byte • Depends heavily on the distance between client and the backend • Includes the time the backend needs to render the page Session lookups, Database Queries, Template rendering … Content Download • Files have a high transfer time on new connections, since the initial congestion window is small many roundtrips Maximum 6 parallel connections DNS Lookup Initial Connection SSL Handshake Time to First Byte Content Download https://www.thinks.com/ 20 ms0 53 ms 70 ms 90 ms36 ms
- 14. Network Performance The average website http://httparchive.org/ Transfer Size: 2480 KB Total Requests: 104
- 15. I. Grigorik, High performance browser networking. O’Reilly Media, 2013. Network Performance Network latency impact
- 16. Network Performance Network latency impact I. Grigorik, High performance browser networking. O’Reilly Media, 2013. 2× Bandwidth = Same Load Time ½ Latency ≈ ½ Load Time
- 17. Network Performance Common Tuning Knobs • Persistent connections, if possible HTTP/2 • Avoid redirects • Explicit caching headers (no heuristic caching) • Content Delivery Networks • To reduce the distance between client and server • To cache images, CSS, JS • To terminate SSL early and optimized • Single Page Apps: • Small initial page that loads additional parts asynchronously • Cacheable HTML templates + load dynamic data • Only update sections of the page during navigation HTTP/2 Performance Advantages: • Server Push • Header Compression • Request Pipelining • Multiplexing over 1 TCP connection (no head-of-line blocking)
- 18. Network Performance Applied in the example What we do: • Heavy browser and CDN Caching • Avoid Redirects (+ serve from CDN) • Single Page App functionality • Persistent Backend Connections • Gzip Compression • IP Anycasting to nearest POP
- 19. Backend Performance Overview • Horizontally scalable databases (e.g. “NoSQL”) • Replication • Sharding • Failover Load Balancer Application Server Database • Load Balancing • Auto-scaling • Failover • Stateless session handling • Minimize shared state • Efficient Code & IO Load Balancer Application Server Database
- 20. Content-Delivery- Network Polyglot Storage Backend-as-a-Service Middleware: Caching, Transactions, Schemas, Invalidation Detection, … Standard HTTP Caching Unified REST API Backend Performance Applied in the example
- 22. Performance: State of the Art Summarized Frontend Latency Backend • Doable with the right set of best practices • Good support through build tools • Caching and CDNs help, but a considerable effort and only for static content • Many frameworks and platforms • Horizontal scalability is very difficult
- 23. Performance: State of the Art Summarized Frontend Latency Backend • Easy with the right set of best practices • Good support through build tools • Caching and CDNs help, but large effort and only for static content • Many frameworks and platforms • Horizontal scalability is very difficult Good Resources: Good Tools: https://developers.google.com/web/fundamentals/performance/?hl=en https://www.udacity.com/course/website-performance-optimization--ud884chimera.labs.oreilly.com/ books/1230000000545 shop.oreilly.com/produc t/0636920033578.do https://developers.google.com/speed/ pagespeed/ https://gtmetrix.com http://www.webpagetest.org/
- 24. Accelerated Mobile Pages Google‘s Approach for a Faster Web How AMP works: • Stripped down HTML + AMP tags rendered asynchronously by AMP runtime • All CSS must be inlined • All JS must be async • Static sizes (e.g. iframes) no repaints • Cached in Google CDN, as long as it is crawled the next time (no invalidation) only suited for static media, e.g. news How to apply the same techniques for any website? https://www.ampproject.org /docs/reference/spec.html
- 25. Goal: Low-Latency for Dynamic Content By Serving Data from Ubiquitous Web Caches Low Latency Less Processing
- 26. 6 Years Research & Development New Algorithms Solve Consistency Problem Stale Data Innovation Problem: changes cause stale data
- 27. Innovation Solution: Baqend proactively revalidates data Bloom filter updateIs still fresh? 1 0 11 0 0 10 1 1 6 Years Research & Development New Algorithms Solve Consistency Problem
- 28. Innovation Solution: Baqend proactively revalidates data Bloom filter updateIs still fresh? 1 0 11 0 0 10 1 1 6 Years Research & Development New Algorithms Solve Consistency Problem < F. Gessert, F. Bücklers, und N. Ritter, „ORESTES: a Scalable Database-as-a-Service Architecture for Low Latency“, in CloudDB 2014, 2014. F. Gessert und F. Bücklers, „ORESTES: ein System für horizontal skalierbaren Zugriff auf Cloud-Datenbanken“, in Informatiktage 2013, 2013. F. Gessert, S. Friedrich, W. Wingerath, M. Schaarschmidt, und N. Ritter, „Towards a Scalable and Unified REST API for Cloud Data Stores“, in 44. Jahrestagung der GI, Bd. 232, S. 723–734. F. Gessert, M. Schaarschmidt, W. Wingerath, S. Friedrich, und N. Ritter, „The Cache Sketch: Revisiting Expiration-based Caching in the Age of Cloud Data Management“, in BTW 2015. F. Gessert und F. Bücklers, Performanz- und Reaktivitätssteigerung von OODBMS vermittels der Web-Caching-Hierarchie. Bachelorarbeit, 2010. F. Gessert und F. Bücklers, Kohärentes Web-Caching von Datenbankobjekten im Cloud Computing. Masterarbeit 2012. W. Wingerath, S. Friedrich, und F. Gessert, „Who Watches the Watchmen? On the Lack of Validation in NoSQL Benchmarking“, in BTW 2015. M. Schaarschmidt, F. Gessert, und N. Ritter, „Towards Automated Polyglot Persistence“, in BTW 2015. S. Friedrich, W. Wingerath, F. Gessert, und N. Ritter, „NoSQL OLTP Benchmarking: A Survey“, in 44. Jahrestagung der Gesellschaft für Informatik, 2014, Bd. 232, S. 693– 704. F. Gessert, „Skalierbare NoSQL- und Cloud-Datenbanken in Forschung und Praxis“, BTW 2015 F. Gessert, N. Ritter „Scalable Data Management: NoSQL Data Stores in Research and Practice“, 32nd IEEE International Conference on Data Engineering, ICDE, 2016 W. Wingerath, F. Gessert, S. Friedrich, N. Ritter „Real-time stream processing for Big Data“, Big Data Analytics it - Information Technology, 2016 F. Gessert, W. Wingerath, S. Friedrich, N. Ritter “NoSQL Database Systems: A Survey and Decision Guidance”, Computer Science - Research and Development, 2016 F. Gessert, N. Ritter „Polyglot Persistence“, Datenbank Spektrum, 2016.
- 29. 1 4 020 purge(obj) hashB(oid)hashA(oid) 31 1 110 Flat(Counting Bloomfilter) hashB(oid)hashA(oid) Browser Cache CDN 1 • Clients load the Cache Sketch at connection • Every non-stale cached record can be reused without degraded consistency Faster Page Loads1 𝑓 ≈ 1 − 𝑒− 𝑘𝑛 𝑚 𝑘 𝑘 = ln 2 ⋅ ( 𝑛 𝑚 ) False-Positive Rate: Hash- Functions: With 20.000 distinct updates and 5% error rate: 11 KByte
- 30. Continuous Query Matching Generalizing the Cache Sketch to query results Main challenge: when to invalidate? ◦ Objects: for every update and delete ◦ Queries: as soon as the query result changes How to detect query result changes in real-time? 2
- 31. Query Caching Example Add, Change, Remove all entail an invalidation and addition to the cache sketch SELECT * FROM posts WHERE tags CONTAINS 'b' Query Predicate P Cached Query Result Q 𝑜𝑏𝑗1 ∈ 𝐐 𝑜𝑏𝑗2 ∈ 𝐐 Change Add Remove 2
- 32. InvaliDB Architecture BAQEND Create Update Delete Pub-Sub Pub-Sub 1 0 11 0 0 10 1 1 Fresh Cache Sketch Continuous Queries (Websockets) Fresh Caches Polyglot Views Felix Gessert, Michael Schaarschmidt, Wolfram Wingerath, Steffen Friedrich, Norbert Ritter: Quaestor: Scalable and Fresh Query Caching on the Web's Infrastructure. Under Submission. 2
- 33. Scalable ACID Transcations • Solution: Conflict-Avoidant Optimistic Transactions • Cache Sketch fetched with transaction begin • Cached reads → Shorter transaction duration → less aborts 3 Cache Cache Cache REST-Server REST-Server REST-Server DB Coordinator Client Begin Transaction Bloom Filter 1 validation 4 5Writes (Public) Read all prevent conflicting validations Committed OR aborted + stale objects Commit: readset versions & writeset 3 Reads 2
- 34. Scalable ACID Transcations • Novelty: ACID transactions on sharded DBs like MongoDB • Current Work: DESY and dCache building a scalable namespace for their file system on this 3 With Caching Without Caching
- 36. BaqendParse Kinvey 0.3 s2.6 s 3.9 s
- 37. Competitive Advantage What impact does Baqend have in practice? 0.7s 1.8s 2.8s 3.6s 3.4s CALIFORNIA 0.5s 1.8s 2.9s 1.5s 1.3s FRANKFURT 0.6s 3.0s 7.2s 5.0s 5.7s SYDNEY 0.5s 2.4s 4.0s 5.7s 4.7s TOKYO +156% 0.5s 1.3s FRANKFURT
- 38. Summary 0 1 0 0 1 0 1 0 1 1 1 1 0 0 0 0 0 0 1 1 HTTP Caching Cache Sketch TTL Estimation RT Query Matching Invali-dations Frontend
- 40. Shop Simultaneous Users < 1 second Page Load Time 7.8% Conversion Rate 3% Server Usage
- 41. Ziel mit InnoRampUpOur Vision for Baqend: „A web without load times“ www.baqend.com @Baqendcom
Editor's Notes
- -Das (was?) waren 9,3 s – so lange lädt eine durchschnittliche E-Commerce Webseite -Selbst kleinste Ladezeitverzögerungen haben immense Auswirkungen auf die Nutzerzufriedenheit und den Geschäftserfolg -Zahllose Studien haben diese Effekte quantifiziert, hier sind einige der bekanntesten -Amazon, 800 Mio. verlorener Umsatz -Yahoo, weil Nutzer unzufriedener sind -Google, 500ms durch attraktivere Inhalte und trotzdem Rückgang des Umsatzes und der Aufrufe -Aberdeen Group, Marktforschungsinstitut, d.h. 7% weniger Besucher werden zu Kunden -Neben diesen abstrakten Zahlen haben wir mit Unternehmen wie GoodGame Studios und WLW gesprochen
- -So you probably know that many of the shops presented there are overloaded or offline during the show.
- -These studies show, that time is money -I personally have always hated slow websites. So coming from a research background, I asked myself: what is the underlying problem?
- -Here we see a user from the US accessing a european application -Two bottlenecks cause slow load times 1. Während ein Nutzer auf eine Webanwendung zugreift und erwartungsvoll auf sein Display starrt, muss zunächst ein Web-Server das sogenannte „Backend“ die Webseite generieren. Dabei entsteht eine hohe Verarbeitungszeit beim Zusammenstellen der Inhalte aus einer Datenbank. 2. Diese Webseite und alle Ressourcen, die sie enthält –z.B. Bilder- müssen über das Internet zum Nutzer übertragen werden. Dadurch entsteht eine als „Latenz“ bezeichnete Übertragungszeit, die um so höher ist, je weiter der Nutzer von dem Backend entfernt ist. Diese Latenz und nicht die Bandbreite bestimmen die wahrgenommenen Ladezeiten. - Diese beiden Engpässe können wir durch unser Produkt Baqend für beliebige Anwendungen lösen
- Is loading of images part of the CRT?
- In build tools das meiste kombinierbar „WebPack“
- Webpack baut performante strukturen für single page apps und optimiert schon vieles Post CSS optimiert vendor prefixe anhand von browser statistiken, fasst mediaqueries zusammen
- TCP Fast Open (TFO) is a mechanism that aims to eliminate the latency penalty imposed on new TCP connections by allowing data transfer within the SYN packet. However, it does have its own set of limitations: there are limits on the maximum size of the data payload within the SYN packet, only certain types of HTTP requests can be sent, and it works only for repeat connections due to a requirement for a cryptographic cookie. Based on traffic analysis and network emulation done at Google, researchers have shown that TFO can decrease HTTP transaction network latency by 15%, whole-page load times by over 10% on average, and in some cases by up to 40% in high-latency scenarios!
- A lot of small transfers
- Was ändert sich Client-seitig bzw. für die Anwendungsentwickler?
- -Bei unserem Ansatz werden alle Daten nicht nur im Backend sondern auch global verteilt zwischengespeichert, um so dicht wie möglich an Endnutzern positioniert zu sein. Wenn also ein Nutzer die Webanwendung aufruft, ist unabhängig von seinem Standort die Latenz gering Durch die Zwischenspeicher, sogenannte „Caches“, entsteht kein Verarbeitungsaufwand im Backend. Durch unsere Algorithmen können diese existierenden und zahlreich vorhandenen Caches erstmals für alle Anwendungsdaten genutzt werden.
- -Die technische und wissenschaftliche Basis von Baqend beruht auf verschiedenen Innovationen im Bereich Datenbanken und Cloud Computing Die neuen Algorithmen und Architekturen sind durch 4,5 Jahre Forschung und Entwicklung am Institut für Verteilte Systeme und Informationssysteme an der Uni Hamburg entstanden. Kern der Innovation ist eine Technik, die es erlaubt, die bestehende Caching-Infrastruktur auf eine völlig neue Art zu verwenden Beim klassischen Caching werden angefragte Daten automatisch in Caches zwischengespeichert Ein Problem entsteht, wenn Daten geändert werden. Nach der Änderung sind die Einträge in den Caches veraltet. Wenn Nutzer also die Webanwendung aufrufen, erhalten sie veraltete Daten.
- -Es gibt zwei Typen von Caches: solche die durch ein Backend aktualisierbar sind und solche die unter keiner Kontrolle stehen -Unsere Lösung verwendet eine spezielle Datenstruktur, über die effizient festgestellt werden kann, welche Daten veraltet sind. Zusätzlich werden bei einer Änderung Daten in kontrollierbaren Caches automatisch aktualisiert Die Webanwendung verwendet daraufhin automatisch den Bloomfilter, um veraltete Daten neu zu laden, wodurch Caches sich selber aktualisieren. Für alle Anwender ist dadurch garantiert, dass sie stets aktuelle Daten erhalten.
- -Es gibt zwei Typen von Caches: solche die durch ein Backend aktualisierbar sind und solche die unter keiner Kontrolle stehen -Unsere Lösung verwendet eine spezielle Datenstruktur, über die effizient festgestellt werden kann, welche Daten veraltet sind. Zusätzlich werden bei einer Änderung Daten in kontrollierbaren Caches automatisch aktualisiert Die Webanwendung verwendet daraufhin automatisch den Bloomfilter, um veraltete Daten neu zu laden, wodurch Caches sich selber aktualisieren. Für alle Anwender ist dadurch garantiert, dass sie stets aktuelle Daten erhalten.
- Sollte man das wirklich ‚Architecture‘ überschreiben? Vielleicht besser ‚Principle‘ oder ‚Basic Idea‘ oder ‚Basic Principle‘ … Warum zweimal Pub-Sub? Warum die Pfeile in diese Richtungen? Kann man ‚Websockets‘ weglassen? Was ist Continuous Query? Was ist das grundlegende Prinzip der Wartung von Queries durch den Cache Sketch?
- -But you might argue „hey, I have an e-commerce portal for german sausage for german customers, why would I care about latency?“. Sorry, I know, jokes about german sausage are the worst. But here is the thing…
- Hier fehlen die Queries (und die polyglotten views)
- One of the most successful startups that ever presented there was Thinks. The developed a Fitness Towel sold over their shop.
- -4 of the other shops were completely down -3 remained available, and the Baqend-based shop scored the maximum Google Page Speed Score -and that advantage is the difference between apologizing for being offline and apologizing for being out of stock
- Unsere Vision ist eine Web- und App-Welt ohne Ladezeiten. Und wir wollen Ihnen als Unternehmen und Entwickler die technische Plattform dafür geben.