--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
--
Nice list of practices there.
I would make a few observations:> Memcached / APC for SS based caching - what is the best one?Memcached is probably slightly more performant, but APC has the advantage of being a native PHP module; I think they also do slightly different things as APC caches the compiled PHP files, rather than compiling on every request (as well as acting as an cache store). see http://docs.silverstripe.org/en/3.1/developer_guides/performance/caching/ for more info
> Caching in PHP using private statics for custom methods that may be called more than once (e.g. if self::$foo is empty then fill it using the method below otherwise return self::$foo without further ado)This is good, but you make a memory trade-off. Note that the template engine will do this automatically for you, too.> Frameworks (e.g. jQuery) via Google / Another CDNThis contradicts an earlier point about minimising HTTP requests. Ultimately, if you have gzip and good cache headers, you may as well include jQuery in your minified JS file. That connection will be opened anyway. Also, using CDNs to deliver jQuery can actually slow your site if they are unavailable (unlikely but possible) or blocked by the ISP/country of the visitor (more likely).
> Use IDs rather than classes for CSS + JS references (faster to lookup)tl;dr: Although IDs may be fractionally faster, they aren't worth the trade-offsThis is really a trade-off between more maintainable and "modular" CSS/JS and speed, and when we say "speed" we mean micro optimisations here. Using an ID for CSS is so minutely slower, it's not worth the pain of it's specificity. It's best to keep a flat class structure (any kind of nested rules are slower) further reading: http://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/. If you're interested in modular CSS that's fast and flexible, I'd recommend reading up on BEM.The same is true with JS - I'd say it's quite rare that you'd ever have a JS component that can safely hook into an ID (ie: you only need it once on any page) and the cons of tightly coupling your JS to your IDs, again, make this a pain. An interesting article and it's test results actually show class selectors are faster?!Anyway, these kinds of optimisations for the front-end are really only important if you're running a massive front-end app OR have very large datasets/DOM trees to work with.> Ajaxify forms - only load forms on request using ajax techniquesI'm not sure if I follow, if you mean lazy-load forms like one could with images this may be quite bad for people using assistive technologies (like screen readers) that expect to be able to find a form on the page when loaded.
To add to server: HTTP 2.0 / turn on Keep-Alive; and Image resampling optimisation.As with lots of these things (and particularly your front-end ones) the scalability, modularity and maintainability (of your development workflow) are often going to be at odds with some of the things you've suggested.I strictly work to never using IDs (for selectors) and if we need an extra wrapper div to make a component modular or to add another styling hook, then we do. The trade-offs for front-end performance (for the work we do) is completely unnoticeable and using minification, image optimisation, gzip, caching and faster protocols will all make a far superior speed difference to the browser than replacing your CSS class selectors with IDs.Last thought: Lots of your server optimisations are about moving things into memory - again, it's about being pragmatic (unless you have a huge quantity of memory available) when determining what can and can't be held in RAM. I probably wouldn't load by 5GB DB into memory on a small VPS (for example) especially if it involves using the page file as you'll just end up thrashing anyway.
Hope that's somewhat informative and useful.
--
Hi,
My 2 cents:
Use nginx instead of apache, and a newer version of php (PHP 5.6 is a lot faster than 5.4…)
Use staticpublisher where it makes sense (no forms, no dynamic stuff…), or load forms with ajax (with fallback for js disabled browsers, screenreaders etc..)
Cheers,
Werner
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.