Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Faster response times without a CDN

36 Aufrufe

Veröffentlicht am

Jacob Carrington and Hayden Shaw from digital agency Harvey Cameron share a few tips for faster response times without using a CDN at the Christchurch SilverStripe Meetup, June 2019.

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Faster response times without a CDN

  1. 1. SilverStripe Performance
  2. 2. Introduction Jacob Carrington Lead UX & UI developer Harvey Cameron Hayden Shaw Solutions Architect Harvey Cameron
  3. 3. Performance Standards For response timing standards we use the RAIL - a user centric performance model that breaks down the user's experience into key actions. ● Response to user interaction within 100ms ● Pages to be interactive within 1 - 2 seconds. Up to 5 on slow connection. https://www.nngroup.com/articles/response-times-3-important-limits/ https://developers.google.com/web/fundamentals/performance/rail
  4. 4. Measuring Performance Lab Data ● Chrome Dev Tools / Lighthouse ● Webpage Test (https://www.webpagetest.org) ● Page Speed Insights Field Data ● Google Analytics ● New Relic
  5. 5. Our Common Performance Patterns ● We host all template assets to reduce round-trips ● Inline SVGs and use the SVG symbol pattern ● Optimize Fonts (Subset, Reduce weights and styles) ● We use Imgix / Lazysizes for optimizing image patterns ● Code Split JS into small chunks ● UNCSS / cssnano to optimize CSS and remove unused rules ● No javascript in head Etc...
  6. 6. But we were still...
  7. 7. SilverStripe: Size & Complexity vs. Performance The more complex data models equals more DB queries equals poor TTFB 200ms computational budget plus latency adjustment.
  8. 8. We sought advice from the gods
  9. 9. SilverStripe’s Response Use a CDN.
  10. 10. Oldman + CloudFlare ● Easy to setup - generate API key and add some config ● Publishing/Unpublishing will clear the CloudFlare cache for that url ● Handy dev/tasks https://github.com/symbiote/silverstripe-oldman
  11. 11. What if you can’t use a CDN? ● Client doesn’t want to switch their DNS ● Client doesn’t want to pay for it
  12. 12. Partial Caching ● Core goodness ● Gives you the ability to cache portions of your templates ● Easy to invalidate the cache via the use of aggregates and controller generated cache keys ● Cut out database queries - although still requires a database query https://docs.silverstripe.org/en/4/developer_guides/performance/partial_caching/
  13. 13. Cache Objects ● Core goodness ● Formally SS_Cache on SS3 ● Great for caching arbitrary data e.g. fetching from another service ● Ties into flush=1 https://docs.silverstripe.org/en/4/developer_guides/performance/caching/
  14. 14. Cache Include ● Caching based on URLs not database queries ● Event driven approach rather than having to query the database ● Cache block config is handled via yml so easy to follow and customise ● Template or full request options ● Base href gets messed up on SilverStripe Platform deploys until you login https://github.com/heyday/silverstripe-cacheinclude https://www.silverstripe.org/blog/whats-the-cache-this-silverstripe-module-will-painlessly-boost-your-sites- performance/
  15. 15. Static Publish Queue ● Superb for sites that rarely change ● Runs off cron ● Bypasses SilverStripe completely by creating HTML files ● Exclude page types from being cached e.g. pages with forms ● Reduces server load ● Run on a low performing (cheap) server https://github.com/silverstripe/silverstripe-staticpublishqueue
  16. 16. https://media.giphy.com/media/JC6 BaGcw0538I/giphy.gif