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.

Web Page Speed - A Most Important Feature


Published on

Once upon a time early modems were slow. The broadband came along and web page byte count and code skyrocketed. Now? Now we have slowness even at broadband speeds due to page bloat. And if you're on mobile, you've got slowness and the added annoyance of possibly higher battery drain.

It's time to start thinking about web site performance as a feature in and of itself. Because if you're too slow, none of your other features will matter. Your visitor will be gone before the page renders.

Presentation excerpt from Udemy course "Digital Product Management"

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Web Page Speed - A Most Important Feature

  1. 1. Special Focus: Speed TIME IS MONEY From the online course: Digital Product Management
  2. 2. The Need for Speed  You already know page load speed is important.  Did you know it might be the most important thing you can make sure is working well on your site?  Yup, even more important than some of the features.
  3. 3. How Bad Is the Problem?  Wolfgang 2016 E-commerce KPI Benchmarks Study “We found site speed matters more than any of the website engagement metrics. ‘Server response time’ enjoyed a conversion rate correlation three times stronger than the best engagement metric, ‘average session duration’. Because site speed is a SEO ranking factor, smart digital marketers can benefit from a ‘site speed multiplier effect as their faster site earns more traffic combined with a higher conversion rate.”
  4. 4. More from Wolfgang… “We found Average Server Response time is 0.76 seconds. We also found a strong correlation between low server response times and high conversion rates. This means for every two tenths of second you shave off your server response time you can expect to see an an 8% lift in conversion rate. Unsurprisingly, there was also a strong correlation between high server response time and high bounce rate.” “Average page load time 6.5 seconds. This is significantly slower than the 2 second threshold for e- commerce websites recommended by Google. Amazon’s research into site speed found that every one second delay reduces conversion rate by a whopping 7%.” Source: Wolfgang 2016 E-commerce KPI Benchmarks Study
  5. 5. More Problem Definition “A 1 second delay in page response can result in a 7% reduction in conversions.” - KISSmetrics “1 out of 5 online shoppers will abandon their cart because the transaction process was too slow..” - Radware Got that? These are people you had gotten to come to your site, and convinced them to buy. They were in the process of buying when they left you. And are less likely to ever come back.
  6. 6. And Even More Problem Definition “The average load time for mobile sites is 19 seconds over 3G connections…we found that 53% of mobile site visits are abandoned if pages take longer than 3 seconds to load.” - DoubleClick “Sites that loaded in 5 seconds vs 19 seconds were observed to have: 60% greater pageviews per visit. 35% lower bounce rates.”- DoubleClick
  7. 7. What Does Google Say? Says… “53% of mobile site visitors leave a page that takes longer than three seconds to load.” “Our research has been eye-opening. For 70% of the pages we analyzed, it took nearly seven seconds for the visual content above the fold to display on the screen, and it took more than 10 seconds to fully load all visual content above and below the fold.”
  8. 8. Some Cases - Shopzilla It’s an old case from 2009, but still instructive. • Load time brought from 6 to 1.2 seconds • Conversions increased 7-12% • Pageviews increased 25% • SEM based sessions increased 8% This was almost a decade ago. Speed is even more important now.
  9. 9. Some Cases - Walmart From 2012. • 2% increase in conversions for every ONE second of speed savings. • 1% additional revenue per 1/10 second savings in speed. • SEO Benefits.
  10. 10. Cascade Consequence: SEO  Slow site speed can affect SEO. “As part of that effort, today we're including a new signal in our search ranking algorithms: site speed. Site speed reflects how quickly a website responds to web requests.” - Google Blog 4/9/2010  Let’s say this more clearly. If you are slow, Google will hurt you.
  11. 11. How Does Speed Hurt SEO?  We can’t tell how slow pages can hurt SEO. Google is vague about how the signal affects ranking.  We don’t know if slow is based on time to first byte or full page render and how many seconds is of concern.  Google will also do this for your mobile experience. To what degree and when is all up to them.  Bottom Line: This is happening. And it will likely matter more and more over time.
  12. 12. The Verdict on Speed and SEO  There’s no way to know for sure of the impact. There are anecdotal reports and some impossible to be comprehensive studies. But it’s Google’s algorithm. Their Secret Sauce.  Here’s the thing though, we’ve already shown the value of getting load time down. So think of any SEO juice as bonus.
  13. 13. Is This YOUR Problem?  Is this your problem as a Product Manager?  Isn’t this kind of thing the responsibility of the CTO?  Well… yeah. And no.  There costs to network hardware, bandwidth, and more. That’s part of P&L. So you have to share that.
  14. 14. Why Does Speed Matter to Users?  It’s not just frustration.  Humans have thresholds for short term memory retention.  The idea of “flow” isn’t just for sports or work. We have it for everything.  When things for which we’re in task flow take too long, we can lose our train of thought and become frustrated.  And yes, perceived time during a focused task can seem longer than actual time. Sensory Memory Short-term Memory Forgotten Info
  15. 15. Convinced?
  16. 16. Why Do Pages Load Slowly?  Poor architecture in the first place. Code bloat, non-optimized graphics.  Unexpected usage loads.  Perhaps the number one reason is code and tag bloat over time. Things creep in. Feature after feature, marketing code tag after tag.  Tags and other tools introduce third party code and content that might not be optimized.
  17. 17. Why Do Pages Load Slowly?  Too many server requests. (Worse for mobile)  Large graphics. Poorly optimized graphics. Graphics can take up large percentages of overall page byte count.  Lot’s of ad calls and other third party widget calls that may not be efficient.
  18. 18. Problems With Fixing Speed Issues  Speed alone isn’t really a sexy feature.  There are many points along the page load journey that can affect speed.  Mobile has made things harder.
  19. 19. Speed Challenges with Mobile  Bandwidth is obvious issue.  Device processing capability varies.  Software may work differently.  E.g., browser caches less robust.  Mobile latency can change if a user turns a corner or if it happens to be raining.  Multiple requests are problematic.  If Mobile is critical, you may need to analyze Adaptive vs. Responsive methods.
  20. 20. What You Should Be Looking At  Generally you’re going to take action on things you’re measuring.  Speed is a KPI you need to be measuring.  Do you have a target load time? For first pixels to render? For total page load?  What are competitor benchmarks?
  21. 21. Diagnose Your Problem  Where are you now? Determine your baselines.  Page speed is made up of both page and site architecture and networking issues.  A proper approach to measurement will involve multiple methods.
  22. 22. General Types of Testing  Synthetic Lab testing. Clean browsers, etc. Goal is to understand what the best cases can be.  Real User Monitoring (RUM) Real users connected to typical ’net connections, mostly clean browsers, but many types of hardware, latencies, etc. These are really complementary methods. It takes both to give a full picture of what’s going on. (And even then you won’t fully know.)
  23. 23. Monitoring Speed  There are – as usual – a wide variety of tools, both do it yourself and professional enterprise grade, for monitoring site performance.  Note: Tools that help diagnose and monitor web site speed may also provide server uptime monitoring. However, operational monitoring is an entirely separate topic and also has it’s own dedicated toolsets.
  24. 24. Some Basic Quick Look Tools – Developer Tools  Chrome Developer Tools Easy to plug in to browser. Use the Network tab to see load times for elements and whole pages. You can disable cache, throttle speed, and determine scripts that block rendering.
  25. 25. Some Basic Quick Look Tools – Google Insights  Google’s Page Speed Insights  ”PageSpeed Insights analyzes the content of a web page, then generates suggestions to make that page faster.”
  26. 26. Some Basic Quick Look Tools – Ghostery  The Ghostery product isn’t a speed tool. It’s primarily to identify and potentially block tracking technology.  Also useful for troubleshooting.
  27. 27. More Speed Test Tools – WEBPAGETEST  Sponsored by Google, this Open Source Project shows loading waterfall charts, Page Speed optimization checks and suggestions.
  28. 28. More Speed Test Tools – GTmetrix  Freemium & Pro.  Page load times, requests, benchmarks, visualizations.
  29. 29. More Speed Test Tools – HttpWatch  Commercial Product.  Page debugging, Network traffic debugging, automation testing, recommendations, compare to others.
  30. 30. More Speed Test Tools – Pingdom  Commercial Product.  Heartbeat / uptime monitoring, Real User Monitoring, load speed analysis, alert / incident reporting.
  31. 31. More Speed Test Tools – New Relic  Commercial Product.  Large scale testing platform. Applications and networking monitoring. Requests reporting, geographic performance, API testing, etc.
  32. 32. Fixing Problems: Overall Goals  Get things rendering asap.  This follows an information scent pattern.  Minimally, let the user see that things are happening. This can be called “Time to Value” Get them some value and maybe they’ll hang around. But show them a blank nothing and they’re gone
  33. 33. Cutting Down Load Time  Get Diagnostics Going. Select Tools. Instrument your site as needed.
  34. 34. Cutting Down Load Time (cont’d)  Code Review. Remove components where possible. This not only reduces byte count and possible processing time, but also the number of network requests. Get rid of junk. Comments are generally good, but unnecessary text and lines may have crept in over time. Gzip compression.
  35. 35. Cutting Down Load Time (cont’d) JavaScript in particular can be problematic. Besides being interpreted in the browser, moving elements around, swapping CSS, etc., can slow things down. (As well as use of Ajax calls.) jQuery can be a decent chunk of code. In most cases, it’s unquestionably needed. But be sure about this. If you can get away without it, that’s something to consider. Can you use local storage / cache better?
  36. 36. Cutting Down Load Time (cont’d)  Optimize Graphics and Videos. While this is a well known issue, it can easily be an afterthought.  Consider a Content Delivery Network (CDN). This will require financial analysis, but getting content, (especially ‘heavy’ content), closer to users via edge of network servers can help.
  37. 37. Cutting Down Load Time (cont’d)  Optimize Critical Rendering Path.  This is somewhat advanced.  The goal is pixels to screen as soon as possible.  Google offers a free course on how to study and adjust rendering order.  Progressive rendering can be “lazy” by only loading as items come into viewport, or focus on ”above the fold” or other options.
  38. 38. Thanks! From the online course: Digital Product Management