Moving an Existing WordPress website with over 5000 Articles

🙋Get Help
1

Hello,

I have an existing WordPress website with over 5000 Articles and we are planning to use frontity. so what you guys recommend for this type of heavy traffic blog? Any thoughts?
we already build a react component for this.

Thanks

2 Likes
2

AFAIK, frontity is just like an UI client which grab data from WP endpoint and display it using react. It’s like a theme for your site. So whether there are 5000 or just 5 posts it’s job is to fetch and display it. It’s not like Gatsby a SSG which get date and transfer into HTML pages.

3

Thanks.! But I am more concerned about challenges like pre render, wordpress native comments, previewing draft articles.

4

What do you mean by pre-render here?
Native comments aren’t supported yet but they are working.
You can preview draft posts

5

@inamkbmail is absolutely right, in Frontity it doesn’t matter how big is the site, it just works. If you use a serverless instead of a Node server, you don’t need to worry about scaling Node because serverless services autoscale automatically.

If I’m not mistaken, an official package to support native comments will be included in our next sprint. You can follow the progress on this Feature Discussion topic: Native WordPress comments

The preview will take a bit longer, but we are already working on the design. I have to open an official Feature Discussion topic for that, but you can read about our ideas in Does Frontity support Wordpress post preview? until then. It’s definitely one of our top priorities for this Q2. Of course, your editors can use the preview of your PHP theme until then. It won’t be the same, but at least they will see something :slight_smile:

2 Likes
6

Thanks for your reply. do we use any library for state management like redux?

7

Yes, Frontity has its own state manager, called internally Frontity Connect.

8

Thanks for quick reply!

  1. In current frontity scenario we need to change our current wordpress url to different one for rest api right? So what exactly happens to wordpress site after the deployment?

  2. Can we use this Library for react component (obviously we can use it :see_no_evil:) it supports emotion.sh https://github.com/rebassjs/rebass. Any Recommendations?

Thanks :slight_smile:

10

  1. Nothing will happen to the WP site it’ll be just available on a different URL.

  2. Check docs here https://docs.frontity.org/learning-frontity/styles. I found no specific criteria of using ‘emotion’ instead of you’ll import it’s package from frontity package as they’ve got merged into frontity.

11

Hi @mosamlife

You need to keep the WordPress site even after you’ve deployed your Frontity site as Frontity will fetch all its content from the WordPress site. The authors, editors, and maintainers of your content will continue to use the WordPress admin pages for managing the content that appears in your Frontity site.

If you don’t want the WordPress site to be visible to visitors you could activate a very minimal theme that just has a styles.css file with the requisite header info, and an index.php that outputs either blank page or a “Nothing to see hear” type of message, just in case anyone inadvertently
finds their way to the WordPress site.

13

That I already know. for that I am thinking to use underscore theme for this

14

@luisherranz @mburridge Thanks for the quick reply! one question though Should I wait for theme bridge or just continue with current frontity version?

15

Hi @mosamlife

If you’re happy to have your WordPress install on a separate domain/sub-domain, with your Frontity site on your primary domain, then you don’t need to wait for the theme bridge.

At present this is the configuration that we recommend anyway.

16

@mosamlife

Rather than using Underscores, which provides much more than you need, you could try Nude with is a minimal theme specifically designed for ‘headless’ sites:

1 Like
17

Yea I just read that Thanks for the reply @mburridge. can you please tell me what is benefits to use theme bridge over the current one?

18

Hi @mosamlife

Please take a look at this discussion: Theme Bridge.

In brief, some of the advantages are:

  • You don’t need your admin pages to be on a different domain from your public facing site
  • Content editors can preview their posts
  • The admin bar is visible to logged-in users

However, there are disadvantages too:

  • there is more routing involved…
  • …so you need to use a cache plugin or your public facing site will be very slow
19

So If performance is more concerned than we can use current stack. correct?

20

Hi @mosamlife

Our current recommendation is the ‘Direct to Frontity’ installation.

https://docs.frontity.org/installation-and-deploy/possible-architectures#direct-to-frontity

21

Great conversation here guys :slight_smile:

Yes, the Theme Bridge is not available yet, only a proof of concept.

I’d like to take this opportunity to outline some facts about the performance of WordPress, Frontity and other similar JS frameworks.

I have noticed that a lot of times the term performance is used to refer to server response time (SRT) and that is not correct, so I think it’s necessary to understand the difference.

The SRT is the amount of time it takes for the browser to receive a response, usually the HTML.

If you generate a LightHouse report, you will get a performance score, measuring this (as of v6 of LH):

  • First Contentful Paint: 15%
    SRT has some importance here, but it’s not the only fact.
  • Speed Index: 15%
    SRT doesn’t have any importance here
  • Largest Contentful Paint: 25%
    SRT doesn’t have any importance here
  • Time to Interactive: 15%
    SRT doesn’t have any importance here
  • Total Blocking Time: 25%
    SRT doesn’t have any importance here
  • Cumulative Layout Shift: 5%
    SRT doesn’t have any importance here

You can read more about all these metrics here: https://web.dev/performance-scoring/ (the docs of LH are actually pretty good).

First Contentful Paint is the only metric affected by SRT and it works more or less like this:

Screen Shot 2020-04-16 at 17.49.05
Screen Shot 2020-04-16 at 17.49.051470×720 111 KB

As you can see, having a good SRT is important, but it’s not the only factor.

Frontity bundles everything together in the initial HTML to avoid the additional requests. It works more like this:

Screen Shot 2020-04-16 at 17.55.09
Screen Shot 2020-04-16 at 17.55.091094×576 63.4 KB

Frontity also applies other optimizations apart from that, but I guess that is the most important for this metric.

That doesn’t mean you need a good SRT, you do.

So now, what is a good SRT?

LightHouse docs say it will fail if it is higher than 600ms:

This audit fails when the browser waits more than 600 ms for the server to respond to the main document request.

In CMS’s like WordPress we are dealing with static content (the content is the same for all the visitors), so the best to improve the SRT is by using a cache.

There are three types of cache from slower to faster (bear with me):

  • WordPress cache plugins.
  • Server cache, like varnish.
  • CDN.

A non-cached WordPress request works like this:

WordPress (without cache)

Screen Shot 2020-04-16 at 18.14.24
Screen Shot 2020-04-16 at 18.14.24972×786 65.7 KB

But when you introduce a cache, the subsequent requests are much faster:

WordPress (with cache)

Screen Shot 2020-04-16 at 18.19.28
Screen Shot 2020-04-16 at 18.19.281402×1214 145 KB

So if you use a cache, then the SRT of WordPress is not relevant anymore. And that is the reason that WordPress is rather slow, but still so popular among big publishers.

Let’s talk a little bit about Frontity now.

Frontity access the data using the REST API, like this:

Frontity (without cache)

Untitled-2020-04-16-0919 (1)
Untitled-2020-04-16-0919 (1)1131×808 59.6 KB

So you need to cache it as well.

As you can see, it is also important to cache the REST API properly. We usually recommend this plugin: https://wordpress.org/plugins/wp-rest-cache/

Once you’ve added cache to the picture, Frontity looks like this:

Frontity (with cache)

Screen Shot 2020-04-17 at 08.23.08
Screen Shot 2020-04-17 at 08.23.081580×1300 260 KB

Problem solved.

By the way, modern servers like Now or Netlify include a CDN by default, which is the best type of cache for this.

Remember:

  • No matter how fast is your SRT, if it is combined with a bad HTML which contains a lot of blocking requests and parts of the DOM that need jQuery for the render will result in a very low performance score.
  • The reason that Frontity is so fast is the combination of a low SRT + avoiding blocking requests (CSS, fonts) + perfect SSR + some other minor optimizations.

Finally, let’s see the Theme Bridge architecture without cache:

Theme Bridge (without cache)

Screen Shot 2020-04-16 at 18.41.42
Screen Shot 2020-04-16 at 18.41.421686×1068 154 KB

And the Theme bridge with cache.

Theme Bridge (with cache)

Screen Shot 2020-04-16 at 18.44.46
Screen Shot 2020-04-16 at 18.44.46974×554 43 KB

So yeah, it’s as fast as your cache, like any other solution.

The thing with the Theme Bridge is that it has many benefits. You don’t need two separate domains, things like previewing draft posts become much simpler and others like sitemaps, external files (ads.txt, robots…) or instant cache invalidation just work out of the box.

I think the main points I am trying to make are:

  1. Be careful, a fast server response time doesn’t mean a fast performant site.
  2. No matter how fast or slow your server is, you should always use a cache.
  3. Once you introduce a cache, how fast or slow is your server is not important anymore.

Drawings

4 Likes
22

@luisherranz Thanks for your detailed reply.! Appreciate it. So I finally decided to go with the current frontity version. can you please tell me Is it to migrate to the theme bridge version when it’s released? other than changing WordPress URLs and all?