Skip Navigation

[Resolved] loading template

This support ticket is created 7 years, 1 month ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

Tagged: 

This topic contains 9 replies, has 2 voices.

Last updated by Christian Cox 7 years, 1 month ago.

Assisted by: Christian Cox.

Author
Posts
#579084

Hi

I am trying to:

I've created a custom template for some companies. The template has many custom fields and custom css. I'm showing these custom fields through the use of View

Link to a page where the issue can be seen:

hidden link

I expected to see:

When I'm viewing the page front end in the browser, the browser first loads a whole bunch of things that I don't want such as sidebars, author profile, etc, etc (I disabled those items through the use of css display: none; )

1- The page takes really a long time to load and shows first many things before it shows the final layout
2- The backend takes really a long time to load, also editing and saving the backend takes a long time

Instead, I got:

Can you please give me some advises to consider as to what causing this behavior and weather it is the right way to use the custom fields and templates?

I really look forward to your reply

Best regards,

#579173

Hi there, I can see what you mean. The page does appear to take quite some time to load - around 22 seconds time to first byte for the page HTML alone. Let me try to help with this.

When I'm viewing the page front end in the browser, the browser first loads a whole bunch of things that I don't want such as sidebars, author profile, etc, etc (I disabled those items through the use of css display: none; )
If the page is loading unnecessary information, then you should remove those unnecessary elements from the Content Template to cut down on page load time, rather than using CSS to hide that content after it's rendered already in the browser. You can remove unnecessary elements by hiding them programmatically using conditional HTML in a Content Template:
https://toolset.com/documentation/user-guides/conditional-html-output-in-views/
However, if the unnecessary elements are not part of a Content Template or View, then they may be part of your theme and you may need custom code to remove them.

The page...shows first many things before it shows the final layout
So it sounds like the CSS that you want to apply to the design is not being applied until after the content is fully rendered. That seems to indicate that the CSS could be enqueued more effectively. It's difficult for me to know how this CSS is applied without some more information from you. Have you added this extra CSS in WP Bakery Page Builder, or is it added to a Content Template's CSS panel, or a View's CSS panel? Or is it added as extra CSS somehow in your theme's Customizer? To be most effective, you probably need to create a separate CSS file that holds this code and enqueue it in the site's header. This will force the CSS to load before the page content is placed. However, in some systems this is not always possible.

The backend takes really a long time to load, also editing and saving the backend takes a long time
Okay let's try to narrow down the source of the load time issue on the front-end and back-end.
- Temporarily disable all plugins except Toolset Types and Views. Activate a default theme like Twenty Seventeen. If you need to activate a plugin like Maintenance Mode while running this test, that's fine.
- Review the performance of the site on the front-end and back-end by refreshing the page several times or editing some content several times. If the performance is much better, then you know there is probably a conflict somewhere between your theme or other plugins and Toolset. Reactivate your theme and plugins one by one, testing the front-end and back-end several times after enabling the component, until an obvious performance issue is revealed in either side of the site. Let me know what you find.
- If the performance of your site did not dramatically improve when you disabled all the other plugins and your custom theme, then it's possible we have something to investigate in your site's database. Let me know if that's the case and I can take a deeper look. I will need to access your site's wp-admin area and probably create a clone using the Duplicator plugin. If that's okay with you, please provide login credentials in the private reply fields I have enabled here.

#581167

Hi again Christian

I'm continuing to read....

A quick question: Is the Layout plugin perhaps a better way to deal with the issue of designing a template to hook in and displays only the custom fields that I created in the content template?

Best regards,

#581249

Q: If those elements are part of the theme. Is there a simply way using this plugins (View or Type) to display a "clean" template?
Content Templates can replace the main content area of a single post or post archive or single page, but they have limited to no effect outside this area. Usually this would require modifications to the theme or child theme's PHP template files.

A: for the content template I'm using the content template css customizer and some other stuff in the style.css of the child theme customizer
Q: How to enqueue css of the content template it in the site header? Is there an article in knowledge base explaining this?
Content Template CSS and theme Customizer Additional CSS are actually encoded in the source of the page, so there is no delay before these styles are applied to the site content. Something else is causing the shift in styles, probably a JavaScript plugin modifying the DOM after page load. As a test, disable JavaScript in your browser and refresh the page. When I test this, I see quite a different page design. One problem I see is that other plugins, like the premium stock market widgets, are delaying the load of their javascript until after the page is loaded. This means that there will be a flicker before everything is downloaded and initialized. Toolset won't be able to help you with that, as it involves optimization of another plugin.

1- disabled plugins and using twentyseventeen theme [only activated Type, View, VC ]
>> backend template browsing, editing and saving is still very sluggish and extremely slow [30+ seconds]

This isn't normal. Toolset should not cause your site's backend to be this slow. There could be a server / hosting issue, or an issue in the database itself. You could try a few things to isolate this:
- Move the site to a better host or platform, or install a copy of the site somewhere else. If performance improves, you know the issue is the host. This might be difficult if you can't create a clone.
- Make a backup of your site's database, then delete all the current database contents. Install WordPress again to start with a clean database and test the backend again. If the problem was immediately resolved, then you know there is a problem with the data in your database, or a problem accessing it with Toolset. If the problem was not immediately resolved, then you most likely have a server / host issue.
- Install Query Monitor plugin to monitor the performance of all the queries needed to load a page. Isolate any long-running queries for further investigation. Toolset queries should take no longer than 0.5ms to run.

Did I hit the limit of performance and I need to upgrade to a dedicated server or build the website from the ground up without all those plugins?
Re performance, I couldn't say, because I cannot install a clone on a fast system to compare the results with your live results. Anything I could offer there would be speculative.
Re plugins, you could try to install a caching plugin that would help deliver your site's contents more efficiently (faster time to first byte), but I am not sure if this will help the performance of those other plugins. That's a bit outside the scope of the investigation I can offer here.

It's not permitted to create a clone unfortunately. I hope we can solve this issue through this thread.
This is going to make it difficult but we can try! What exactly is not permitted, can you explain in more detail? Is it all the data in the database, or is it specific posts that you could potentially delete? Is your custom theme off-limits? Some specific plugins? Is it possible to make a clone of a development version of the site instead of production version? If I have the ability to replicate any of your site at all it will be helpful for me to diagnose here.

Is the Layout plugin perhaps a better way to deal with the issue of designing a template to hook in and displays only the custom fields that I created in the content template?
I'm not following - better than what exactly? Any time you add another plugin into the mix, you're going to need to consume more resources to run the site, and that will affect performance in most cases. If you can get by without it, performance will be better. But if you need the ability to build a drag and drop site design, Layouts might be a good solution for you instead of some other page builder system.

#581280

Hi Christian

Thanks again for your attention

What I did is the following:

I used Toolset Export to export Types and Views settings.

Then I imported those settings of Types and Views onto a fresh wordpress install (fresh database, native theme, no plugins except types and views)

The export and the import process went like a charm

Then I created a custom post and here is my finding

- Again it takes extremely long time for the backend of this post type to load.....the backend just hang! Editing, saving and browsing is almost impossible.

- The front end of this freshly installed site is extremely fast to load

What do you think the problem might be.

Just a note worth mentioning is that the same solution with post type, custom fields and template worked out quite well just a few months ago. When we started to write content in these fields. It was not extremely fast but it was really okay to fill content into those fields, edit and save was not a problem at all....

Now I don't know why this strange behaviour on fresh install, fresh database, without any plugins...and even no content yet. Just trying to create a new custom post with a simple title and save it and look at the front end.

I can send you the exported Types and Views zip files for you to test

Let me please know

I look forward to your reply

Best regards,

#581291

Sounds like a hosting / server issue. If you'd like to post the files to Dropbox or Drive, you can provide a download link or links in the private reply fields here. No need to provide accurate server information, just include the link(s) in your comments.

#581662

Well I don't see anything wrong with the Types and Views exported data. When I import these, I am still able to navigate the backend efficiently without the long delays you've mentioned, and save and edit posts as expected. Just to clarify, if you disable all Toolset plugins, are the performance problems resolved?

#581676

Okay that's a bit of a good news narrowing on the issue.

What I did in the few last days I implemented a new clean single.php to use the template for. This is now a clear improvement on the frontend because no other stuff like sidebar, footer, author box is loaded. Only header and content template. However the backend is still very slow

I recognize that the options panel of my theme (Highend Theme) has the same delay issues. So when I disable Views and Types the issue of delay on the Theme Options panel disappears and there's no delay.

BUT yesterday I tested on a fresh install (native wordpress theme, fresh database, Views and Tools) I had the same delay issues.

So what I'm thinking of doing next is to do fresh install of my theme and see what happens. I'm running of options.

The server could be also an issue....I just don't know now.

QUESTION: You have seen the template solution with Tools and Views that I've sent you. Do you think this is the right way to implement such a solution with Views and Types? Do you have any suggestions or recommentdatioins?

Thank you so much Christian

Best regards,

#581699

QUESTION: You have seen the template solution with Tools and Views that I've sent you. Do you think this is the right way to implement such a solution with Views and Types? Do you have any suggestions or recommentdatioins?
The Private Airlines Template looks pretty heavy to me. I assume that the contents of all tabs must be loaded upfront, as opposed to loading via AJAX on demand? If so, that means you'll have a lot of db queries required to get all the necessary information and display this page. With a caching plugin incorporated, this might not be a major concern, but I would keep an eye on it.

BUT yesterday I tested on a fresh install (native wordpress theme, fresh database, Views and Tools) I had the same delay issues.
I will gladly run some tests locally if you can provide a copy of your parent-theme (and optionally child-theme) files. It's a paid theme and I do not currently have access to a copy. I will provide private reply fields again here so you can share a download link in confidence.

#582528

I moved my site to a new more powerful host WPEngine.
Great. I have seen some other WPEngine / Toolset users mention performance issues when WPEngine's Object / Transient cache system is enabled, so be aware that you may need to experiment with those settings in your controls.

- Then I tested the same existing solution in FireFox. Opening a new custom post takes a bit long but once the post backend is loaded the browsing and saving is like a breeze. No delays in typing, no delays in scrolling. It's amazing!!
Great, but you're describing better browser performance as opposed to better server performance. Delays in typing, scrolling, and responsiveness of the user interface like this are not directly related to server performance. These issues will be present even after all the assets are downloaded and the browser has finished rendering the page. They're more related to how different browsers work and are optimized differently.

This is completely different from delays in page load time and downloading assets from your server, which we've been discussing up until now. So if you're having better luck using the site in Firefox, I say stick with it. I've noticed that Chrome is sluggish when certain plugins like Yoast SEO are active, and also when a post editor includes multiple WYSIWYG fields. If either of those is true for your site, I recommend toggling as many panels closed as possible while using the wp-admin editors. Break multiple WYSIWYG custom fields in to separate post field groups, so they can be independently toggled open and closed, and always toggle Yoast SEO closed unless you're actively using it.

once again I would like to ask your companies wisdom to tell me if this is the right way to do things.
I don't have access to most of your site, so I'm not able to give you a very thorough analysis here. Based on what I can see, you should limit the number of WYSIWYG fields you include in any single post group, so that you can always toggle these closed when you're not editing them. This will help improve the browser performance on the backend of the site. Your post types seem fine, I don't see any relationships between your CPTs so I don't think those could be optimized any more. I see an inactive custom taxonomy called "Tags", which seems a bit confusing because there is already a native taxonomy called "Tags". I would avoid duplicate taxonomy names for simplicity. Beyond that, I'm not able to tell much without being able to see actual Views or Posts.