O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

SearchLove San Diego 2018 | Mat Clayton | Site Speed for Digital Marketers

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio

Confira estes a seguir

1 de 77 Anúncio

SearchLove San Diego 2018 | Mat Clayton | Site Speed for Digital Marketers

Baixar para ler offline

We all know that site speed matters not only for users but also for search rankings. As marketers, how can we measure and improve the impact of site speed? Mat will cover a range of topics and tools, from the basic quick wins to some of the more surprising and cutting-edge techniques used by the largest websites in the world.

We all know that site speed matters not only for users but also for search rankings. As marketers, how can we measure and improve the impact of site speed? Mat will cover a range of topics and tools, from the basic quick wins to some of the more surprising and cutting-edge techniques used by the largest websites in the world.

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a SearchLove San Diego 2018 | Mat Clayton | Site Speed for Digital Marketers (20)

Anúncio

Mais de Distilled (20)

Mais recentes (20)

Anúncio

SearchLove San Diego 2018 | Mat Clayton | Site Speed for Digital Marketers

  1. 1. Site Speed for Digital Marketers @matclayton
  2. 2. Why should you care about Site Speed?
  3. 3. mixcloud.com mat@mixcloud.com3 2010: Google confirm Site Speed effects rankings
  4. 4. mixcloud.com mat@mixcloud.com4 2018: Google confirm Site Speed also impacts mobile rankings
  5. 5. Site Speed directly impacts conversion rates and your bottom line Read more: https://skilled.co/resources/speed-affects-website-infographic
  6. 6. GoogleBot will crawl more pages Read more: https://mitchfournier.com/2011/08/03/reducing-page-load-times-dramatically-increased-my-googlebot-crawl-ra This is due to Page Speed, which is a component of Site Speed. We’ve seen shifts in indexing based on Site speed as well but often less pronounced.
  7. 7. It is just a better user experience
  8. 8. What are Page Speed and Site Speed?
  9. 9. Page Speed: Time To First Byte Essentially how fast can you get the HTML to the browser
  10. 10. Read more: https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics Site Speed: Can mean many things to different people State Purpose Metric Is it happening? Did the navigation start successfully? Has the server responded? First Paint Is it useful? Has enough content rendered that users can engage with it? First Meaningful Paint Is it usable? Can users interact with the page, or is it still busy loading? Time To Interaction
  11. 11. What makes up a website?
  12. 12. Loading Waterfalls - https://www.webpagetest.org/
  13. 13. What makes up a website?
  14. 14. Waterfall View: https://www.webpagetest.org/
  15. 15. Waterfall View: https://www.mixcloud.com
  16. 16. Comparisons and loading videos
  17. 17. How to measure Site Speed
  18. 18. JavaScript: Navigation Timing API
  19. 19. JavaScript: Navigation Timing API
  20. 20. Google Analytics
  21. 21. Pingdom
  22. 22. YSlow: Browser Extension
  23. 23. YSlow: Browser Extension
  24. 24. Google PageSpeed: Site + Chrome Extension
  25. 25. Google LightHouse: Site and Inbuilt in Chrome
  26. 26. Google LightHouse: Overall Performance
  27. 27. Google LightHouse: Opportunities
  28. 28. Connections and Requests
  29. 29. - Anycast DNS - A round trip from San Diego to London ~160mS - Anycast send traffic to a local datacenter ~20ms - A few Anycast Providers - AWS Route53 - CloudFlare - EasyDNS Domain Name Service (DNS) How customers find where your web servers are.
  30. 30. HTTP2 http://www.http2demo.io/
  31. 31. HTTP 1.1 HTTP 2 Why HTTP2 speeds up your site
  32. 32. Head of blocking HTTP 2.0HTTP 1.1
  33. 33. Checking HTTP version
  34. 34. - HTTP Header Compression (HPACK) This will just work, and shaves off a good 1-2k depending on your use of cookies - Request Priorities Allows the browser to set request priorities and ensure that it get the most important ones first - Server Push: WARNING this is very very hard to get right, and you’ll make it worse if you get it wrong Other benefits of HTTP2
  35. 35. Domain sharing HTTP2: Yesterday’s performance best-practices are today’s anti-pa Read more: https://docs.google.com/presentation/d/1_SMrVmiMxW2X1QZ1EcCnLKSosiD0PppP70Q3bw-l5Lg/present?slide=id.g40fbe Sprites
  36. 36. (Things which don’t change)
  37. 37. Invest in Javascript/CSS tooling, specifically bundling
  38. 38. CSS + JS: Concatenate and Minify Read more: https://github.com/mishoo/UglifyJS2
  39. 39. Tree shaking less code == less data to transfer == faster site
  40. 40. Split up your CSS + Javascript into multiple small files (Advanced) This allows you to download more files in parallel and helps with caching You can also Lazy Load Javascript when its required.
  41. 41. Enable GZIP/Deflate
  42. 42. Enable GZIP/Deflate ompression will work well on text based assets: HTML / Javascript / CSS / JSON / XM Usually 2-3x saving
  43. 43. Caching is super important
  44. 44. Caching Requests
  45. 45. Caching Requests: Ensure they have a unique URL
  46. 46. Caching Requests: Headers
  47. 47. Caching Requests Caching works for static assets which never change: Images / CSS / Javascript / Static HTM
  48. 48. Use a Content Delivery Network (CDN) Advantages • Reduce request latency - A round trip from San Diego to London ~160mS - Anycast routes to a local datacenter ~20ms • Caching, reduces server load • SSL Termination done right • DDoS protection • HTTP2 support • Compression / Minify static assets Disadvantages • Cost (free plans available) • Provider dependency • Not all content is cacheable
  49. 49. The more elements in the HTML: • The more bytes there are to download • The slower the Javascript interactions will be • The slower scrolling will be Be especially careful with any parts of the HTML which involve loops Reduce the number of HTML elements Bad Good <div id=“my-list-item“> <li>My Content</li> </div> <li id=“my-list-item“>My Content</li>
  50. 50. Lazy load sections of the page Read more: https://developers.google.com/web/fundamentals/performance/critical-rendering-path Lazy Load in parts of the page which aren’t immediately required, or content critical.
  51. 51. Images are still the number one cause of bloat on the web.”
  52. 52. Fixing Images: BIG BIG WIN
  53. 53. Choose the right image format for the job Read more: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/image-optimizatio Vector Simple shapes represented by lines shapes and points. e.g. icons Raster Each pixel has individual colour values. e.g. photos
  54. 54. Vector Images: Use SVG • Prefer vector to raster images when possible • SVG are just simple XML files, exportable by all major image editors • Compress very well using gzip • Its also possible to build images using CSS3 or fonts
  55. 55. Choose the right image format Always check the file size after converting the image, this isn’t a hard and fast set of rules
  56. 56. WebP (Advanced) Read more: https://developers.google.com/speed/webp/gallery1 Typically a 30% saving for users with support for WebP (Chrome only)
  57. 57. Ensure raster images are the correct size: BIG BIG BIG WIN Responsive images can cause a lot of additional bloat Read more: https://internetingishard.com/html-and-css/responsive-images
  58. 58. Retina images Ship multiple variants, without downloading the large image for all devices
  59. 59. Perception of speed: Progressive JPEG’s Read more: https://optimus.keycdn.com/support/progressive-jpeg/
  60. 60. Perception of speed: Loading states
  61. 61. Perception of speed: Loading states Read more: https://code.facebook.com/posts/991252547593574/the-technology-behind-preview-photos
  62. 62. Caching is super important
  63. 63. <html> <head> <title>My Page</title> <link rel=“stylesheet" href=“my-css.css”> </head> <body> <div id="user-greeting">Welcome back, user</div> </body> </html> Ensure all CSS files required for rendering the page are included in the <head> Optimize CSS includes
  64. 64. Remove any unused CSS (hard to get correct) Read more: https://cscheng.info/2016/05/06/quick-way-to-find-unused-css-with-chrome-devtools.htm UnCSS: https://github.com/uncss/uncss PurifyCSS: https://github.com/purifycss/purifycss
  65. 65. Minimal CSS rendering (Super Advanced) (styled components, this is hard and needs a complete rethink of your design to achieve)
  66. 66. Caching is super important
  67. 67. Optimize <script> positions <html> <head> <title>My Page</title> <script type="text/javascript" src=“my-script.js"></script> </head> <body> <div id="user-greeting">Welcome back, user</div> </body> </html> Bad This will block rendering, causing the page to stall whilst it parses the Javascrip
  68. 68. Read more: https://stackoverflow.com/questions/436411/where-should-i-put-script-tags-in-html-markup Solution 1: Moved to just above </body><html> <head> <title>My Page</title> </head> <body> <div id="user-greeting">Welcome back, user</div> <script type="text/javascript" src=“my-script.js"></script> </body> </html> <html> <head> <title>My Page</title> <script type="text/javascript" src=“my-script.js" async></script> </head> <body> <div id="user-greeting">Welcome back, user</div> </body> Solution 2: Make the scripts async
  69. 69. Remove all the bloat (aka tracking pixels and 3rd party scripts) At least ensure they are embedded using async, so they don’t block page render I would recommend you setup a regular review and remove session.
  70. 70. In Summary Everything comes down to one of 4 techniques 1. Reduce the number of assets 2. Reduce the size of assets 3. Make the assets load faster (DNS / Caching / CDN’s) 4. Prioritise the order of assets 5. Use HTTP2 ;) It might not be your job, but hopefully you can now point your development team in the right direction
  71. 71. Thank you for listening Any Questions?
  72. 72. Mat Clayton Co-Founder mat@mixcloud.com +44 (0) 7872007851

Notas do Editor

  • Hey I’m Mat, I’m the CTO and Co-founder of Mixcloud.

    Mixcloud is the online radio hosting platform of choice for todays DJ’s and radio stations.

    I’m a techie at heart.
  • Rankings
  • Mobile Rankings
    I would argue that Site Speed on Mobile just makes the problem more obvious
  • No ever bought from a site because it was slower to load, they got to stare at the page for more time.
    It just doesn’t work like that
  • I believe Google allocate an amount of time per domain, and therefore the slower the site is the less it’ll scrape.
    We’ve seen shifts which match this logic in Webmaster Tools, such as the reported one above.

    Google has indicated site speed (and as a result, page speed) is one of the signals used by its algorithm to rank pages.
    They can also clearly measure Site Speed from Chrome and use that as a signal if they so wish.

    Research has shown that Google might be specifically measuring time to first byte as when it considers page speed. In addition, a slow page speed means that search engines can crawl fewer pages using their allocated crawl budget, and this could negatively affect your indexation.
  • Google has indicated site speed (and as a result, page speed) is one of the signals used by its algorithm to rank pages.

    And research has shown that Google might be specifically measuring time to first byte as when it considers page speed. In addition, a slow page speed means that search engines can crawl fewer pages using their allocated crawl budget, and this could negatively affect your indexation.
  • TTFB - Time to First Byte
  • 80% of load time is once the page is sent to the browser.
    TTFP - Time to First Paint
    TTFMP - Time to First Meaningful Paint
    TTI - Time to Interaction
    FPS - Frame Per Second, interaction speed
  • Explain about 3G testing
    Multiple runs
    Videos
  • Explain about 3G testing
    Multiple runs
    Videos
  • Explain about 3G testing
    Multiple runs
    Videos
  • Major issue with this, is that is measures async and external scripts as well, which in our case don’t block rendering, and can easily be loaded after the effect.
  • Use a CDN, is often wrong. You might have to confirm some domains are on your CDN.
    Also timings etc on Google Analytics
  • Use a CDN, is often wrong. You might have to confirm some domains are on your CDN.
    Also timings etc on Google Analytics
  • This will flip to Mobile mode, I’ve not yet figured out why
  • It swaps to mobile, I’ve not seen a good way to keep it on Desktop yet, which can be an issue if you have 2 different sites
  • HTTP Head of line blocking
     
    Head of Line blocking (in HTTP/1.1 terms) is often referring to the fact that each client has a limited number of TCP connections to a server (usually 6 connections per hostname) and doing a new request over one of those connections has to wait for the previous request on the same connection to complete before the client can make a new request.
     
    HTTP/1.1 introduced a feature called "Pipelining" which allowed a client sending several HTTP requests over the same TCP connection. However HTTP/1.1 still required the responses to arrive in order so it didn't really solved the HOL issue and as of today it is not widely adopted.
     
    HTTP/2 (h2) solves the HOL issue by means of multiplexing requests over the same TCP connection, so a client can make multiple requests to a server without having to wait for the previous ones to complete as the responses can arrive in any order.
  • You want to see h2
  • Sharding hurts in HTTP2 world
  • Static assets are things which don’t change
  • These tools essentially take the code your developers produce, and process it in ways that make it run on the browser and as part of that they optimise it for the browser as well.

  • Removes white space
    Collapse variable names down
    Essentially make it a whole lot smaller, less bytes == less to download and less to parse
  • Developers are lazy, this essentially finds the code they don’t use and stripes it out.

    Tree shaking is the concept of removing dead code by analysis, and can radically help you to reduce the size of your Javascript bundles
  • For example on Mixcloud we download just the Javascript you need, then we will download the rest in the background as you need it.

    Reduce the bytes at the start and ready for when the user needs the code
  • Ideally use Content addressable urls, these should automatically update on the content changing.

    We use Hashes of the content. if not ?V=1 would work.

    Slight preference for putting it in the name and not the query params as some caches can ignore them.
  • Note the (from memory cache) 0ms
  • “Images are still the number one cause of bloat on the web.”
    If you do one thing make after this talk Fix your images!
    They account for a huge amount of Content on the page, and are usually fairly easy to fix up.
  • A site on optimising images, is still getting this wrong
  • - Vector / Raster
    - SVG/CSS3 or even Font’s are great for simple shapes
    - You can use fonts instead of SVG’s if you so wish.
  • Under many scenarios progressive JPEG’s will actually be smaller
    However the perception of speed can help a lot
  • You can either set the image color, or you can use a very tiny blurred version and load these in quickly.
    This will only give you a perception of speed and won’t help with actual speed, infact it’ll make it slightly slower
  • You can either set the image color, or you can use a very tiny blurred version and load these in quickly.
    This will only give you a perception of speed and won’t help with actual speed, infact it’ll make it slightly slower
  • If you are not caching the CSS you are wasting a lot of time on page render, and parsing.
    CSSDOM
  • The main issue with this, is the CSS might be needed on another page, but its not a bad place to start looking for way to save bytes
  • A flavour of what is possible,
    We can at pageview calculate the necessary styles to render a page, and only send down that CSS, so the page render is super quick and removes all css bloat.
  • If you are not caching the JS you are wasting a lot of time on page render, and parsing.
  • Most ad and tracking scripts want to run inline, and aren’t good neighbours.
    If you see them running before the all important First Paint line in the waterfallls, find a way to contain them and at least rewrite their <script> tags to be async

×