This is a post to talk about possible integrations with WordPress. Right now we have in mind these:
The JS injector
This is what we have used until now to inject only the mobile version while keeping the desktop version intact. It works, but it’s not ideal because it uses a document.write
to override all the HTML of the WordPress version. It doesn’t make sense if the users want to use Frontity for both their desktop and mobile versions.
Pros:
- It works just by installing the WP plugin.
- It may be useful for previewing how Frontity works without changing your theme.
- Users don’t need to move their WP to a new domain.
Cons:
- It uses a
document.write
to override all the HTML of the WordPress version. - It doesn’t make sense if the users want to use Frontity for both their desktop and mobile versions.
- A Frontity server is needed.
PHP Theme Bridge
This is a PHP theme that doesn’t generate any HTML. Instead, it does an HTTP call to the Frontity server to retrieve the HTML and outputs that.
Pros:
- Users don’t need to change their domain.
- The cache can be done with WP plugins, which know when to invalidate it intelligently.
Cons:
- There is more routing involved (it goes to WP, then Frontity, then WP outputs the HTML)
- Users must use a cache plugin or it will be very slow.
- A Frontity server is needed.
Direct to Frontity
This means users use a different domain for WP, for example. wp.myblog.com
and their main domain points to a Frontity server: www.myblog.com
.
Pros:
- Perfect fit for people with free WP.com blogs (myname.wordpress.com)
- Fastest server side rendering (no useless WP request needed).
Cons:
- Users need to change their WP domain.
- The server side rendering is still slow if the WP is slow, so it may need a cache layer on top.
- A Frontity server is needed.
React-only PHP theme:
This is a PHP theme generated by a Frontity command that renders an empty HTML that only contains the scripts to React. It’s basically a single page application.
Pros:
- No cache is needed.
- No Frontity server is needed.
- Users don’t need to move their WP to a new domain.
Cons:
- It doesn’t have server side rendering:
- No HTML: bad for SEO.
- Bad for First meaningful paint of Lighthouse (bad for SEO as well).
- Readers don’t see anything until React has finished loading: bad user experience.
- The first React load is slower because it needs to do all the API calls.
Static Rendered HTML:
This means users create an HTML file for each possible route at building time. It’s like Gatsby or Next export
.
Pros:
- No Frontity server is needed.
- No cache is needed.
- Server-side rendering is done at building time, so it is like “instant”.
Cons:
- You need to generate a new build each time you publish or edit content.
- A static HTML server is needed (but it’s cheaper than a Frontity server).
- Users need to move their WP to a different domain.
- Not useful for big blogs with thousands of posts.
- Not useful for blogs that update content frequently.
Static HTML PHP Theme
This is a PHP theme generated by a Frontity command but instead of rendering an empty HTML it includes an HTML file for each possible route.
Pros:
- Users don’t need to change their WP domain.
- A Frontity server is not needed.
- A static HTML server is not needed.
- No cache is needed.
Cons:
- You need to generate a new build each time you publish or edit content and update your theme.
- Not useful for big blogs with thousands of posts.
- Not useful for blogs that update content frequently.