Just imagine. You have a meeting with your client tomorrow and have promised to deliver the final iteration of their new homepage design. Luckily you have have awoke to a stroke of creative genius, and fueled by a fresh pot of your favorite coffee, you lose yourself in a design trance for hours creating what is perhaps your best work ever! You sit back, cock your head back and forth and take it all in with a smile when the unthinkable happens. Your browser crashes and you realize that in your state of design-induced euphoria, you completely forgot to save! Your heart sinks when you think about having to do it all over again. That magic is gone. You are out of time. There is no way you can build a new design it in time for your deadline tomorrow.

This is where the Visual Builder’s new Auto-Save system steps in to save the day. That whole time you were building your design, Divi was keeping track of your changes and saving each adjustment as an auto-save. These backups were being stored to your database just in case disaster struck. When you re-start your browser and launch the Visual Builder, Divi knows that you forgot to save and gives you the option to restore your lost data.

A similar auto-save system already exists for the standard WordPress post editor, but this functionality is brand new to the Visual Builder. If your computer crashes, your browser closes unexpectedly, or if you just forget to save, you can rest assured knowing that Divi will be there to lend a helping hand.

Even if you remember to save your work frequently, things can go wrong that prevent those saves from completing successfully. Your internet could go down, your server might be experiencing incremental downtime or a network issue might be causing packet loss between your home network at your hosting company. Even if you are saving frequently, you still need a good internet connection for that data to travel from your browser to your website. That’s where the Visual Builder’s Browser Backups come in. In addition to the auto-saves that are being saved to your website, an additional backup now gets saved in your browser whenever you make a change in the Visual Builder. If your normal saves and auto-saves fail, and you exit the Visual Builder to find that your changes have disappeared, simply launch the Visual Builder again and Divi will detect the browser backup and provide you with the option to restore it.

Sometimes everything goes wrong at once. Something outside of Divi’s control might be preventing successful saves, auto-saves and browser backups. Maybe there is a plugin conflict. Perhaps a browser extension is causing problems. Maybe there is a bug in the Visual Builder that we need to fix! Whatever the case, when you try to save your work in the Visual Builder and that save fails, Divi will now detect that the save failed and will warn you that something went wrong. Not only does the Divi let you know that a save failed, it also gives you to option to download a backup of your work so that it can be restored using the Divi Portability System.

A few months ago we introduced Divi 3.0 and the all new Visual Builder. This Visual Builder has all the same features as the standard Divi Builder (we now call it the Backend Builder), except that changes are made on the front-end of your site using an all new visual interface.

When we introduced this new interface, we did not predict that many users would prefer to make some changes in the Visual Builder and other changes in the Backend Builder. In hindsight, it seems natural that when both builders are available, a designer’s transition from one interface to another would be incremental. Often times we observe users opening up two tabs for the same page, one instance of the Visual Builder and one instance of the Backend Builder, attempting to use both at the same time. The problem with this, until now, was that if you bounced back and forth between two different tabs and made different changes in each, you would end up overwriting the changes you had made previously. This is not a new problem. The same thing would happen if you opened up two instances of the same page in the WordPress Dashboard. The thing is, no one ever did that before because there was no reason to!

When we thought about this update, and ways to help protect our users from losing their work and wasting their valuable time, we realized that it was important that the Divi Builder adapt to this new user behavior. That’s why we created Divi Builder Sync. This new system keeps multiple instances of the builder that are open in different tabs of your browser in sync. If you make some changes in the Visual Builder, when you open up a tab that has the Backend Builder active for the same page, those updates will be loaded automatically. It works in reverse too. Changes made using the Backend Builder are synced to the Visual Builder. You can bounce back and forth and use both builders however you like without saving your works, and those changes will be synced back and forth to ensure a smooth and error-free editing experience.

Before

• Backend Builder Saved Post Size: 8,097 chars
• Visual Builder Saved Post Size: 18,756 chars
• Visual Builder Load Object: 151,801 chars
• Visual Builder Initial Ajax Object: 643,131 chars
• Visual Builder Save Request Duration: 3.81 sec
• Visual Builder Save Request Object: 21,208 chars

First of all, these stats have nothing to do with how long your page takes to load on your website or the size of the pages on your website when loaded by your website’s visitors. These stats only showcases the speed at which the Divi Builder loads, the amount data and time it takes to render a page in the builder, and the time it takes to save a page to your database. We are comparing the speed and efficiency of the builder itself, and comparing the Visual Builder to the Backend Builder. As you can see from these stats, when comparing pages saved with the Visual Builder vs the standard Divi Backend Builder, the Visual Builder resulted in much larger save requests due to how much information was gathered and used to render your page inside of the builder. Long story short: The Visual Builder had a lot more going on and it took a lot longer to load than the Backend Builder. Similarly, it took a lot longer to save the page due to the amount of information being sent from your browser to your website (in the example layout above, the Visual Builder was sending 230% more information to the server than the Backend Builder would. That’s a pretty huge difference).

After

After today’s update, the speed and efficiency of the Visual Builder has been greatly improved. In fact, the Visual Builder is now slightly more efficient than the original Divi Backend Builder. This means that the Visual Builder interface will load faster and your changes will save faster. One of the reasons that improving saving performance and reducing the size of the save request is so important is that it can often result in failed saves and timeouts on shared hosts with limited resources.

• Backend Builder Saved Post Size: 8,097 chars [unchanged]
• Visual Builder Saved Post Size: 7,449 chars [60% reduction]
• Visual Builder Load Object: 111,044 chars [27% reduction]
• Visual Builder Initial Ajax Object: 566,185 chars [12% reduction]
• Visual Builder Save Request Duration: 1.44 sec [62% reduction]
• Visual Builder Save Request Object: 8,723 chars [59% reduction]

So what does that all mean exactly? First of all, the Visual Builder post size is now smaller than the Backend Builder’s post size. The Visual Builder loads about ~21% faster than before and the time that it takes to save a page has been reduced by ~62%. That’s more than twice as fast! This means less time wasted waiting around for the loading spinner to fade away, and a much smaller chance that your save will fail on shared hosts with strict resource limits.