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. 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?

5. Performance

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

10. My sites

11. WPSerbia

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

14. GTMetrix

15. New Relic loads later

16. GTMetrix

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

19. Worst case scenario

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

23. Trackers (can) suck

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

31. Quality

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

34. Remote calls are bad!!!

35. It’s not a front-end issue

36. The solution

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

42. What happens with
poor quality

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

46. Conclusion

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

49. Marko Heijnen
@MarkoHeijnen
info@markoheijnen.com
https://markoheijnen.com