Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Custom coded projects

•
•
Marko Heijnen
Marko Heijnen

Custom Coded Projects - When picking up a project you have many choices to make. Do you go for a premium theme and already builded plugins or will you write parts yourself. I will discuss what impacts custom building a project can have. I will focus on time, cost and speed to help you out with your decision making with future projects.

1 of 49
Custom Coded Projects Marko Heijnen - WordPress Meetup Novi Sad
“There is no such thing as too many plugins but there can be too much code and functionality”
Dilbert to the rescue
What should I choose for this feature?
Performance
Performance • Out of the box solutions can come with a higher performance penalty • This goes more for themes then plugins • This because themes want to do more then you need, this to have a wider target group
My sites vs WPSerbia
Comparison • Everything is hosted on the same infrastructure • Caching is the same which is Batcache/Redis • My sites do use Elasticsearch
My server setup Thumbor Public Memcached Elasticsearch MariaDB Micro services Webserver 1 Webserver 2 Private Loadbalancer
My sites
WPSerbia
Comparison • Average of ~150ms vs ~300ms • Spikes of my sites are caused by network traffic for WPCentral • Spikes from WPSerbia are caused by Jetpack
Comparison • Browser time is 3.3s vs 5.77 (hard to tell an average) • My site is almost fully custom coded • Even does some complex stuff with WPCentral • WPSerbia isn’t that bad performing at all • It has more images but it’s also local targeted
GTMetrix
New Relic loads later
GTMetrix
WPSerbia - good • It does load the images through Jetpack Photon • Server infrastructure is good • Not to many plugins
WPSerbia - can be better • There are still some wrong http links in it (redirects) • Stricter page caching • Images are directly loaded (no lazy loading) • Custom code Twitter widget (17 calls) • Has a theme that also has helper plugins (widgets) which includes small stylesheets which could have been combined with the theme
Worst case scenario
Worst case scenario • One project with international traffic • Dedicated server in Germany • Theme from Themeforest with Visual Composer • Browser time with spikes to ~30s`
Improved version • Created a new parent/child theme • Stripped all options away • Some additional performance and bug fixes • Spikes are now ~10s and went to ~8s • Not bad at all if you look at the overhead of trackers • And keep in mind this is fully loaded time
Improved version • Still no caching in place • This was on a longer roadmap • It was already switched to PHP7
Trackers (can) suck
Time
Time • There are qualitative plugins out there • Say for forms you would choose Gravity Forms, Contact Form 7, Ninja Forms etc • For search you could choose SearchWP, FacetWP or ElasticPress • And more use cases where you have options • So no reason to build everything yourself
Search • Can become complicated very easy • Depending on your requirements something custom or SearchWP/FacetWP can work for you • Using Elasticsearch would have created additional development time due to plugin support • Elasticsearch can save time when complex search is required like fuzzy or partial matching
Custom coded projects
Why FacetWP • It was relative easy to implement • It saved up a considerable time of development • It did create additional effort due to client demands • It saved the client a big chunk of their budget
Cost
Cost • For ElasticPress (Elasticsearch) you would need specific hosting or a VPS • Also most likely a new VPS is needed going for $10 • So decisions you make aren’t only initial cost • Still going for something as ElasticPress could save up cost as your webserver could perform better
Quality
WPCentral • Showing download history • Showing version usage history • List all locales and their current state (being updated) • Showing contributors data (work in progress) • Getting checksums for plugins & themes • Parsing all commits of WordPress (work in progress)
How it worked • A lot of data handling by wp_remote_get • Scrapping profiles.WordPress.org to read data • Multiple API calls to api.WordPress.org • Combine data so it can be presented
Remote calls are bad!!!
It’s not a front-end issue
The solution
Microservices • Microservices are small, autonomous services that work together • Small, and Focused on Doing One Thing Well
Benefits • If WordPress breaks, the services still keep running • Offload functionality from WordPress • High level separation • Ease of Deployment • Different services can use different programming languages
Benefits • Scale services that require more resources • In general they have an (REST) API • Reusable • Other microservices could call the service to run a task
How it works now • All logic in WordPress is gone and simple pipes the calls • Still enough remote calls but to a local server • All calls are still being cached by WordPress • Less code in WordPress means less notable breakage
How it works now • Several small Node.js services • All API based so easy to reuse • Cronjobs are now actual cronjobs • The node services handles things way faster • Pushing new updates has become easier
What happens with
 poor quality
Poor quality • Put your own standard on a project you took over • Specially when it doesn’t add any value • Quick fixes over the place because of cost • Copy/pasted previous theme and put new functionality in there without removing unused ones • Having random functionality that slows down the site without any benefit
Client project • I had several clients in the past that call me for small fixes • Last case was having several session_start() calls when using Varnish • Included functionality that wasn't used which was the main bottleneck • Also having additional page caching through WordPress
What went wrong • Multiple caches could speed up a bit but the changes are high that it will not • sessions/cookies are dangerous when using Varnish and it’s better to not use it at all • A client made changes without having enough knowledge what the negative impact could be
Conclusion
Conclusion • Custom coding a theme is well worth the effort • It doesn’t need to cost as much time • Inform your customers about the decisions the want to make. • Thing outside the box with microservices next to WordPress
Marko Heijnen • Founder of CodeKitchen • Core contributor for WordPress of 15 releases • 1 of the organizers for WordCamp Belgrade • Plugin developer of Tabify Edit Screen, Site Manager etc
Marko Heijnen @MarkoHeijnen info@markoheijnen.com https://markoheijnen.com

More Related Content

Custom coded projects

  • 1. Custom Coded Projects Marko Heijnen - WordPress Meetup Novi Sad
  • 2. “There is no such thing as too many plugins but there can be too much code and functionality”
  • 3. Dilbert to the rescue
  • 4. What should I choose for this feature?
  • 6. Performance • Out of the box solutions can come with a higher performance penalty • This goes more for themes then plugins • This because themes want to do more then you need, this to have a wider target group
  • 7. My sites vs WPSerbia
  • 8. Comparison • Everything is hosted on the same infrastructure • Caching is the same which is Batcache/Redis • My sites do use Elasticsearch
  • 9. My server setup Thumbor Public Memcached Elasticsearch MariaDB Micro services Webserver 1 Webserver 2 Private Loadbalancer
  • 12. Comparison • Average of ~150ms vs ~300ms • Spikes of my sites are caused by network traffic for WPCentral • Spikes from WPSerbia are caused by Jetpack
  • 13. Comparison • Browser time is 3.3s vs 5.77 (hard to tell an average) • My site is almost fully custom coded • Even does some complex stuff with WPCentral • WPSerbia isn’t that bad performing at all • It has more images but it’s also local targeted
  • 17. WPSerbia - good • It does load the images through Jetpack Photon • Server infrastructure is good • Not to many plugins
  • 18. WPSerbia - can be better • There are still some wrong http links in it (redirects) • Stricter page caching • Images are directly loaded (no lazy loading) • Custom code Twitter widget (17 calls) • Has a theme that also has helper plugins (widgets) which includes small stylesheets which could have been combined with the theme
  • 20. Worst case scenario • One project with international traffic • Dedicated server in Germany • Theme from Themeforest with Visual Composer • Browser time with spikes to ~30s`
  • 21. Improved version • Created a new parent/child theme • Stripped all options away • Some additional performance and bug fixes • Spikes are now ~10s and went to ~8s • Not bad at all if you look at the overhead of trackers • And keep in mind this is fully loaded time
  • 22. Improved version • Still no caching in place • This was on a longer roadmap • It was already switched to PHP7
  • 24. Time
  • 25. Time • There are qualitative plugins out there • Say for forms you would choose Gravity Forms, Contact Form 7, Ninja Forms etc • For search you could choose SearchWP, FacetWP or ElasticPress • And more use cases where you have options • So no reason to build everything yourself
  • 26. Search • Can become complicated very easy • Depending on your requirements something custom or SearchWP/FacetWP can work for you • Using Elasticsearch would have created additional development time due to plugin support • Elasticsearch can save time when complex search is required like fuzzy or partial matching
  • 28. Why FacetWP • It was relative easy to implement • It saved up a considerable time of development • It did create additional effort due to client demands • It saved the client a big chunk of their budget
  • 29. Cost
  • 30. Cost • For ElasticPress (Elasticsearch) you would need specific hosting or a VPS • Also most likely a new VPS is needed going for $10 • So decisions you make aren’t only initial cost • Still going for something as ElasticPress could save up cost as your webserver could perform better
  • 32. WPCentral • Showing download history • Showing version usage history • List all locales and their current state (being updated) • Showing contributors data (work in progress) • Getting checksums for plugins & themes • Parsing all commits of WordPress (work in progress)
  • 33. How it worked • A lot of data handling by wp_remote_get • Scrapping profiles.WordPress.org to read data • Multiple API calls to api.WordPress.org • Combine data so it can be presented
  • 35. It’s not a front-end issue
  • 37. Microservices • Microservices are small, autonomous services that work together • Small, and Focused on Doing One Thing Well
  • 38. Benefits • If WordPress breaks, the services still keep running • Offload functionality from WordPress • High level separation • Ease of Deployment • Different services can use different programming languages
  • 39. Benefits • Scale services that require more resources • In general they have an (REST) API • Reusable • Other microservices could call the service to run a task
  • 40. How it works now • All logic in WordPress is gone and simple pipes the calls • Still enough remote calls but to a local server • All calls are still being cached by WordPress • Less code in WordPress means less notable breakage
  • 41. How it works now • Several small Node.js services • All API based so easy to reuse • Cronjobs are now actual cronjobs • The node services handles things way faster • Pushing new updates has become easier
  • 43. Poor quality • Put your own standard on a project you took over • Specially when it doesn’t add any value • Quick fixes over the place because of cost • Copy/pasted previous theme and put new functionality in there without removing unused ones • Having random functionality that slows down the site without any benefit
  • 44. Client project • I had several clients in the past that call me for small fixes • Last case was having several session_start() calls when using Varnish • Included functionality that wasn't used which was the main bottleneck • Also having additional page caching through WordPress
  • 45. What went wrong • Multiple caches could speed up a bit but the changes are high that it will not • sessions/cookies are dangerous when using Varnish and it’s better to not use it at all • A client made changes without having enough knowledge what the negative impact could be
  • 47. Conclusion • Custom coding a theme is well worth the effort • It doesn’t need to cost as much time • Inform your customers about the decisions the want to make. • Thing outside the box with microservices next to WordPress
  • 48. Marko Heijnen • Founder of CodeKitchen • Core contributor for WordPress of 15 releases • 1 of the organizers for WordCamp Belgrade • Plugin developer of Tabify Edit Screen, Site Manager etc