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 info@markoheijnen.com https://markoheijnen.com