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
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 withpoor 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 [email protected] https://markoheijnen.com
Top Related