Measuring frontend performance - Takis Bouyouris

Measuring frontend performance - Takis Bouyouris

WordCamp Thessaloniki 2019

Αν δε μπορείς να το μετρήσεις, δε μπορείς να το βελτιστοποιήσεις. Το αρχαίο ρητό λέει την αλήθεια! Σε αυτή την παρουσίαση θα προσπαθήσω να περιγράψω τις βασικές αρχές μέτρησης του front-end performance μιας ιστοσελίδας WordPress και τους τρόπους με τους οποίους μπορούμε να εντοπίσουμε τα προβληματικά σημεία που έχουν ανάγκη από βελτιστοποίηση. Θα δώσω και μερικά tips, κι ελπίζω να μάθω και μερικά νέα.

If you can’t measure it, you can’t optimise it. This ancient saying is right! In this talk I will present the fundamentals of measuring front-end performance in a WordPress web page and how to spot the problematic spots and thus search for means of optimisation. Ι will also give some useful tips and ideas on optimisation and I hope to learn some new ones, too.

A717e9d055b2284e573b2412e32f5397?s=128

WordPress Greek Community

October 12, 2019
Tweet

Transcript

  1. “measuring frontend performance” Takis Bouyouris web developer @ Nevma.gr

  2. performance is good - users are happy - servers are

    happy - it is an SEO factor SEO factor - conversions increase - revenue increases
  3. (cliché) (cliché) “if you cannot measure it, you cannot improve

    it” 1. know what to measure 2. actually measure it 3. then improve it
  4. 1. know what to measure

  5. HTTP browser <=> server browser server Hello, can you send

    me the page http://www.website.gr/portfolio/? browser server Sure thing, here it is: http://www.website.gr/portfolio/
  6. HTTP browser analyses HTML

  7. HTTP browser asks for assets CSS JS IMG videos fonts

    etc...
  8. browser developer tools > network tab

  9. …and on...

  10. in the meantime, in the server, for every single request

    disk/files OS PHP database system stuff logging monitoring etc
  11. and in the browser - HTML parsing - DOM building

    - CSS parsing - CSSOM building - Javascript compiling - Javascript running - image decoding/resizing - lots of processing - lots of rendering
  12. with even some blocking factors: - each asset is a

    new request - browsers only make 6-8 requests per domain - scripts block rendering - the network (2G, 3G, 4G, wifi, *DSL)
  13. 2. measure it

  14. what (traditionally): - total page size (Mbs) - total HTTP

    requests - total load time (sec) NOT ENOUGH!
  15. what (now): - time to first byte (TtFB) - first

    paint (FP) - first contentful paint (FCP) - first meaningful paint (FMP) - above fold complete - time to interactive (TtI) - DOMContentLoaded DOMContentLoaded event - page load load event
  16. (any) browser developer tools

  17. Chrome Lighthouse

  18. Chrome Lighthouse

  19. online tools: webpagetest.org

  20. online tools: webpagetest.org

  21. online tools: webpagetest.org

  22. online tools: webpagetest.org

  23. online tools: webpagetest.org

  24. online tools: webpagetest.org

  25. online tools: gtmetrix.com

  26. online tools: tools.pingdom.com

  27. detect Javascript bottlenecks

  28. Javascript performance API https://developer.mozilla.org/en-US/docs/Web/API/Performance

  29. Javascript performance API https://developer.mozilla.org/en-US/docs/Web/API/Performance

  30. Javascript performance API https://developer.mozilla.org/en-US/docs/Web/API/Performance

  31. 3. improve it

  32. “to improve” means to be able to detect where where

    optimisation is possible possible and when when your efforts will yield the best results best results
  33. if ( big TtFB ) server issues; else browser issues;

    (repeat many times) detect
  34. detect is your website a transactional website or a content

    website or perhaps a mix?
  35. server issues: - theme (not optimised) - plugins (too many,

    too heavy) - database (too many, too heavy queries) - disk (too many files, inodes, etc)
  36. browser issues: - many requests - no caching - many

    images - big images - many CSS files - many JS files - lots of processing (scripts, libraries, frameworks, etc)
  37. some tips

  38. server side/WordPress - use trusted, tested themes - avoid multipurpose

    themes - use page builders with caution - use as few plugins as possible - be minimal
  39. server side/profiling P3 Profiler plugin Debug Bar Debug Objects Debug

    Queries PHP timer/microtime functions
  40. server side/software - keep server side healthy and secure -

    perform regular updates on OS, application server, db server - perform regular updates on WordPress, plugins and themes - get a reliable, secure hosting, with good support - upgrade to PHP 7+
  41. server side/cleanups - delete old post revisions - delete auto

    drafts - delete spam comments - delete unused terms - delete orphaned post meta - set revisions not too often - set number of revisions low - cleanup old sticky posts WP-Optimize, WP-Sweep
  42. server side/database - optimise database mysqltuner.pl - lookout for slow

    queries use EXPLAIN query
  43. server side/images - use as few custom thumbnail sizes as

    possible - prefer JPEGs over PNGs - compress images well - use SVGs - use icon fonts Imsanity, AJAX thumbnail rebuild, Regenerate Thumbnails, PNG-to-JPG, Smush, EWWW, Adaptive Images
  44. server side/caching - use a CDN - use a caching

    plugin - use a caching server (NginX, Litespeed, Varnish) - use an object cache (ie Redis, Memcached) W3TotalCache, WPSuperCache, Litespeed Cache, NginX
  45. browser side/caching - make as few requests as possible -

    minify and concatenate CSS - minify and concatenate JS - use https, and http2 - make requests when you need them - lazy load images - lazy load Javascript Autoptimize, Better WordPress Minify
  46. browser side/caching - expires headers - allow HTTP keep-alive -

    enable GZIP for text assets (HTML, CSS, JS) - use multiple domains if possible - avoid redirects - avoid 404 requests
  47. browser side/code - put CSS in HEAD but make it

    as small as possible - think of critical CSS - put Javascript before BODY close - async JS, defer JS - use prefetching, preconnecting, prerendering
  48. browser side/measure - time to first byte - first paint

    - first contentful paint - first meaningful paint - time to interactive - DOMContentLoaded event - Load event - above the fold rendering - CSS critical path - CSS and JS coverage
  49. (cliché) (cliché) test early, test often

  50. takeaway we used to worry about light websites that make

    as few HTTP requests few HTTP requests as possible now we also need to care about metrics metrics such as TtFB, FP, FCP, FMP, TtI, above the fold rendering
  51. and this is not something to care about only when

    necessary it needs to be a a mentality mentality it needs to be the way one works the way one works
  52. “thank you” questions?

  53. “measuring frontend performance” Takis Bouyouris web developer @ Nevma.gr