Beat the Clock: Finding the Gremlins Behind Slow Mobile Page Loads
•Als PPTX, PDF herunterladen•
1 gefällt mir•681 views
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Beat the Clock: Finding the Gremlins Behind Slow Mobile Page Loads
Ähnlich wie Beat the Clock: Finding the Gremlins Behind Slow Mobile Page Loads (20)
Mehr von Keynote Mobile Testing
Mehr von Keynote Mobile Testing (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Beat the Clock: Finding the Gremlins Behind Slow Mobile Page Loads
- 1. Beat the Clock Finding the Gremlins Behind Slow Mobile Page Loads Ken Harker Senior Consultant @Ken_Harker February 2014
- 2. Today… We are accustomed to fast page loads Speed is even more important on mobile Success is measured in milliseconds, not seconds Speed = Sales Speed = Loyalty …but there are gremlins in our way…
- 3. We All Expect Fast Page Loads “In the blink of an eye.”
- 4. Fast Mobile Page Loads, Too After 10 seconds, half of your customers are gone.
- 5. The Motivation is Clear Delays in page load time result in increased abandonment, decreased loyalty, and loss of revenue Even very small delays will drive your potential customers to the competition or keep them from returning to your site Success is measured in milliseconds, not seconds You need to take command of the situation before it takes command of you!
- 8. A Winning Combination Culture Tools
- 9. A Winning Combination Culture Tools Best Practices
- 10. 10 Mobile Performance Gremlins
- 11. 1. Too Many New HTTP Requests The slowest of these three mobile home pages is 50% slower than the fastest, and it has 20% more new HTTP requests. Can you tell which one?
- 12. 1. Too Many New HTTP Requests
- 13. 2. Too Many Domains Each new domain encountered in a page can result in a slow DNS lookup
- 14. 3. Serial Downloads Serialization is the enemy of performance
- 15. 3. Serial Downloads Serialization in action
- 16. 4. Slow Initial Render ABOVEBELOW Start above the fold
- 17. 4. Slow Initial Render [Source: https://developers.google.com/speed/docs/insights/mobile]
- 18. 5. Unnecessary Redirections Remove all redirections except for necessary HTTP HTTPS redirections
- 19. 6. Third-Party Calls Find the right balance
- 20. 6. Third-Party Calls This is a waterfall of the home page load of a major US financial news web site
- 21. 7. Inefficient Images PNG image - 304 x 181 pixels - 89K sent over the mobile network Converted to a JPEG image (85% quality) - 304 x 181 pixels - 22K sent over the mobile network This image from a mobile phone retail site in Europe is less than 1” (2.5 cm) wide on an Apple iPhone 5S display Using the wrong image format can have performance implications
- 22. 8. Caching Gremlins The return visitor experience can be vastly improved by strategic cache control on the mobile-optimized site.
- 23. 9. Nonpersistent TCP Connections Enable HTTP Keep Alive, also known as Persistent Connections
- 24. 10. Unnecessary SSL SSL establishment (via key exchange) is done on each new TCP connection and is the slowest part of the SSL process
- 25. Let’s Go!
- 26. 10 Mobile Performance Gremlins Serial Downloads Slow Initial Render Too Many New HTTP Requests Too Many Domains Unnecessary Redirections
- 27. 10 Mobile Performance Gremlins Serial Downloads Slow Initial Render Too Many New HTTP Requests Too Many Domains Unnecessary Redirections Caching Gremlins Nonpersistent TCP Connections Unnecessary SSL Third-Party Calls Inefficient Images
- 28. Beat the Clock Develop a performance culture in your organization Make performance a business priority for the mobile site Ongoing performance monitoring and measurement Synthetic, RUM, and diagnostic tools Follow industry best practices to fight the mobile performance gremlins Disciplined development will lead to a faster site A faster site means better conversion, reduced bounce rate, increased customer loyalty, and more sales!
- 29. Thank you! Ken Harker Senior Consultant @Ken_Harker ken.harker@keynote.com
Hinweis der Redaktion
- 2 second or faster page load times are expected for retail web sites on desktop browsersIn 2006, Google experiments report that extra delays as short as 1/10 second affected sales and ad revenueIn 2006, Amazon reported that a 1/10 second increase in page delay translates into a 1% revenue lossIn 2009, Forrester Research identified 2 seconds as the threshold for user satisfaction with page loads In 2010, Forrester Research found that over half of site visitors abandon page loads slower than 3 secondsIn 2010, Google announces that it has begun using site speed in web search rankingsIn 2012, the New York Times reported on findings that as small a difference as 250 ms between your site and that of a close competitor can reduce your web site visits For context:the human eye blinks in 300-400 ms
- 3 second or faster page load times are expected for retail sites on mobile browsersIn 2011, Strangeloop found that an extra 500 ms delay for mobile users resulted in fewer return visitorsThe impact was still observed 4 months after the extra delay was removedIn 2011, DoubleClick removed a client-side redirection from their service, saving over 1 second on average on mobile devices, and click-through rates increased 12%In 2012, a Strangeloop study concluded that smartphone users view fewer pages, spend less time on sites, and have higher bounce rates than visitors on desktop browsersYou have less time to captivate and retain mobile site visitors In 2013, Etsy found an increase in the image content on one of their mobile site pages increased the bounce rate by 12%In 2013 a Kissmetrics study showed that 49% of mobile web visitors would abandon a site that didn’t load in 10 seconds
- Culture is the Most Important ToolCreate a Performance Culture and A Way of Ongoing CommunicationA dysfunctional culture creates dysfunctional sites/applicationsMake performance part of the lifecycleMake performance a business metricAdmit you have a problemStop arguing about the “perfect” metric
- You Can’t Manage What You Don’t MeasureOngoing synthetic performance measurementsKeynote, Compuware Gomez, Neustar, AlertSite, PingdomReal User Monitoring (RUM) dataKeynote, SOASTA, New Relic, Compuware GomezDiagnostic ToolsMITE, Keynote DeviceAnywhere, HTTP Watch, Chrome Developer Tools, Google PageSpeed, Screenfly, Akamai Mobitest, Webpagetest.org
- Best Practices are approaches to performance that consistently show superior resultsLeverage the knowledge gained by experts in performance managementDevelop disciplined approaches to deliver the highest performance possibleEncourage a culture where doing the right thing for performance is the norm, not the exception
- The number of unique elements mattersSeems simplistic but it has a major bearing on overall load timeEven if your site uses a Content Distribution Network (CDN)Requires a disciplined approachRequires a “user centric” architecture to maximize reuseFor mobile sites, aim for 20 or fewer new HTTP requests per page load
- How?Combine JS and CSSDevelop modularly and combine in production launchCombine small (under 2K) and static imagesSpritesData URIsLeverage cachingDownload frameworks once and reuseDevelop with a user “journey” in mindGet out of silosCreate standards and stick to them
- Each new domain encountered in a page can result in a slow DNS lookupDNS lookups can easily take ¼ second each over 3G mobile network connectionsDomain sharding is deadModern browsers now support better parallelismhttp://calendar.perfplanet.com/2013/reducing-domain-sharding/Or at least not nearly as important as it was 5 years agoHow?Use a single domain for your content Or at most 2 domains – to reduce cookie trafficLoad all third-party tags only after your site’s contentTo defer DNS lookup and TCP connection delays until a point where the user experience is not impacted
- Serialization is the enemy of performanceA single blocking call averaging 500 ms can have same impact of downloading 10 unique requests on mobileBrowsers are becoming better at avoiding serialization Browsers user parallel threadsMost modern browsers can download JS in parallel (yeah!)Application calls can be done asynchronously
- This is a waterfall diagram of a page load on a major US insurance company siteJavaScript and JSON calls on the page are blocking/serializing the page loadFor most of the time it takes the page to load, only 2 or 3 assets can load in parallelHow?Avoid application calls for non-core HTML generation (i.e. tag frameworks, etc.)Avoid redirectionsAvoid complex application frameworksAvoid using Flash to call images/files (use native browser threads)Understand if that third-party tag you are thinking of adding will block/serialize the content that is requested after itIf a serializing call is absolutely necessary, move it down to load later in the page load
- Site visitors will be the most sensitive to initial delayTime to First Paint should ideally be under 1 second for mobile site visitorsAbove The Fold (ATF) content should ideally load in under 1 second for mobile site visitorsThe challenge for mobile sites is even greater than for desktop sites because of how TCP worksThe “slow start” algorithm of TCP means that the first round-trip of data delivery over a new network connection carries fewer bytes than subsequent round-tripsIf you want to begin rendering the page with the first packets of data, you need to be extremely disciplined about what payload you deliver
- HowOptimize the base page HTML response to 14K or less on mobileNeeded to fit payload entirely in first payload delivered from a new TCP connectionDeliver CSS as early as possible Either as part of the base page HTML content or as the very next requestIdeally, load no Javascript at all prior to initial renderPlace all render-critical JS inline in the base page HTML responseKeep all third parties out of the initial renderDon’t trust the most critical performance event to a stranger…Test and target (A/B testing) etc.Remove all blocking to core rendered content
- Redirections are a major performance issue for sites retrieved over mobile networksUsed more often than you realizeMoving from a mobile to non-mobile domainMoving from an insecure to a secure domainMoving from a generic version of the response to one customized for a particular handset or device (e.g. iPhone- versus Android-optimized HTML)Redirections most often serialize the download in the browserThis is always true when the redirections precede the base page HTML deliveryHaving a redirection prior to the base page HTML will most often prevent any chance of the browser doing initial render in under 1 secondHowAvoid having a separate mobile domainServe mobile-optimized base page content from the same ‘www’ domain as the desktop site, if possibleRemove all redirections except for necessary HTTP -> HTTPS redirectionsAvoid situations where a link uses a URL that will require an HTTP -> HTTPS redirectionLink directly to the HTTPS URL instead
- Third-party calls and tags are assets loading on your web site that you don’t directly controlAd serving and ad trackingMarketing analytics (Omniture, Google, WebTrends)Real User Monitoring (RUM)A/B testing servicesTag management frameworksSocial media (Twitter, Facebook, Pinterest)Video player frameworksThird-party hosted JS frameworks (Google API)All of these services have business value, but add risk to the performance and availability of the pages they are served onHowMove them all down unless critical for renderA/B testingRevenue generating adsAudit their usage periodicallyAre they still needed?Is the business value they promised being delivered?Choose light frameworksSingle domains1-2 calls per pageNever use an application call for a “tag”Have a healthy skepticism of vendor claimsAbout their speed, quality, asynchronous natureMeasure their impactOngoingGet both an HTTP and an HTTPS version of the codeAvoid Onclick TrackingUnderstand their strategy internationally
- The assets on the page served from third-party domains are highlighted in purpleSome are critical (revenue-generating ad tags, video players, stock ticker content) and others are less critical (marketing analytics tags, tracking tags)Any one of these calls could be slow or fail with an errorHow will that impact the user experience?How does the site owner manage this risk?
- Some image content is best served in PNG, some is best served in JPEGToo often, images are served over slow 3G mobile network connections that are larger than they need to beServing small images (less than 2K) is highly inefficient over TCP in general, and especially bad over TCP on high-latency mobile networksIn many cases, images are used when no image needs to be sent at all HowReplace “designer” images and color swatches with HTML5 markupUse HTML5/CSS3 features to do effects like rotations and transitions without loading new imagesLosslessly compress all imagesTools can optimize color palettes and remove metadata without any change in image appearanceUse JPEG for photo imagesChoose quality levels of 85 of lowerLook at newer compressible formats for transparencyUnderstand what mobile phones are capable of displayingResponsive design is not always so responsiveCombine small images with CSS spritesReplace small images with base 64-encoded data URIsCheck outhttp://www.slideshare.net/mobile/guypod/a-picture-costs-a-thousand-words18062013Guy Podjarny (from Akamai)
- The return visitor experience can be vastly improved by strategic cache control on the mobile-optimized siteAvoiding round-trips to the server in the first place (because an asset can be pulled from cache) is the most powerful means to improve performanceMobile browser caches are often much smaller than desktop browsers that may not persist across device rebootsAlmost all mobile browsers support localStorageThis can be an effective way to store small assets on the device for reuse on subsequent visitsMost browsers allow up to 5MB of content to be stored in localStorage per siteHowUse “Far Future” Expires headers to ensure that elements remain in the browser cache as long as possibleSet the Expires header to a date in the distant futureChange the filename to force a new version of the content to load if neededBe very careful using “no cache” settingDo not use ETagsOnce popular, ETags often produce as many problems as they solveLook at your ongoing monitoring dataDo you see 200 responses for the same content on different pages?Do you see 304’s in a first visit session – something is really brokenDo you see 304’s in a cached session – can these objects be cached longer?Use localStorage control to explicitly manage cached assets for the mobile site
- The entire page delivery rides atop of TCPThe single largest issue related to TCP is the initial connectionThis is commonly done once per domain and is largely a problem when the sites force new TCP connections for each request by disabling HTTP Keep Alive, also known as persistent connectionsWith HTTP Keep Alive Enabled:The browser will establish new TCP on each domain and REUSE that connection throughout the life of the sessionConnections remain open unless they are forced close (by a server or network device setting)Closing connections for each request can add SECONDS to the load of a page and further impacts long latency networksHow:Turn on persistent connections in the web server configurationUpdate all servers to support HTTP 1.1, where all connections are persistent unless specifically declared otherwise
- SSL is used to encrypt secure data to enable a secure communication between the server and the browserThe SSL establishment (via key exchange) is done on each new TCP connection and is the slowest part of the SSL processUsing HTTP Keep Alive is especially critical for pages served with SSL connectionsHowUnless you are a bank, avoid design frameworks or core libraries that require SSL for all pagesOnly serve pages with sensitive information using SSL