We're Getting Faster: Learn How to Get Your Site Ready

We’re excited to announce that, starting soon, your sites will start loading faster in certain circumstances, thanks to the magic of server-side rendering.

Now that your code may run on the server or the browser, there are a few things you might want to know, and some changes which are important to understand.

When server-side rendering is used, your site’s pages will load faster. In most cases you won’t have to do anything at all to take advantage of the increased performance. You can, however, leverage the new Rendering API to further improve your site’s loading time. To learn more about what server-side rendering is and how to harness its power, see About the Page Rendering Process .

Important

When server-side rendering is used, some of your code will run twice, once server-side and once client-side. Although the code runs twice, the end result is still a faster load because the server is able to do all of the heavy lifting that takes longer when done on the client. However, this may change the behavior of your existing code. Read below to understand when this affects your site and what you can do to restore your desired behavior.

Rollout

Server-side rendering will be rolled out in two parts.

  1. Beginning today, you will be able to use the new Rendering API. However, sites will still not use server-side rendering.

  2. Two weeks from now we will begin rendering sites server-side.
    Use the time between now and 11 March to get your site ready for server-side rendering if needed.

What you need to do

There are some situations where your current onReady() or global code will cease to work as expected.
These include:

  • Code that causes a side effect.

  • Code that must be run in the browser.
    Here are three common examples of where your code might break and what you need to do for your code to work properly with server-side rendering.

Adding collection data from onReady() or global code

Problem: If you add data to your collection in your onReady event handler or in your page’s global code, that data will be added twice when server-side rendering is used.

Reason: Your onReady and global code run twice when server-side rendering is used. The data is added to your collection each time the code runs.

Solution: Use the renderCycle property of the Rendering API to make sure the data is only added the first time your code runs.

In the example below, the insert() call is wrapped in an if() that checks which render cycle is being run. The insertion will only occur during the first render cycle. If there is a second render cycle because server-side rendering is being used, the item will not be inserted a second time.

import wixData from 'wix-data';
import wixWindow from 'wix-window';

let toInsert = {
 "field1": "Some value",
 "field2": "Some other value"
};

$w.onReady(function () {
  if (wixWindow.rendering.renderCycle === 1) {
  return wixData.insert("myCollection", toInsert)
    .then(item => { 
      $w("#myText").text = item.title; 
    });
});

Retrieving storage data from onReady() or global code

Problem: If you try to retrieve data using wix-storage and use that data to populate a page element, the page will flicker when server-side rendering is used.

Reason: The data you’re trying to retrieve is stored in the user’s browser. When you try to retrieve it on the server, it isn’t there. So the element is populated with empty data during the server-side rendering. This is displayed on the screen for a moment before the client-side rendering replaces the empty data with the data retrieved from the client’s browser.

Solution: Use the env property of the Rendering API to make sure the data is only retrieved when your code is run in the browser.

In the example below, the getItem() function is wrapped in an if() that checks which environment the code is being run in. The retrieval will only occur when rendering client-side. If there was also a server-side render, no storage retrieval would have been attempted.

import {local} from 'wix-storage';
import wixWindow from 'wix-window';

$w.onReady(function () {
 if (wixWindow.rendering.env === "browser") {
    $w("#myText").text = local.getItem("key"); 
 }
} );

Using 3rd party analytics to track site events from onReady or global code

Problem: If you send analytics events to a 3rd part app, two events will be sent when server-side rendering is used.

Reason: Your onReady and global code run twice when server-side rendering is used. The the analytics event is sent each time the code runs.

Solution: Use the renderCycle property of the Rendering API to make sure the event is only sent when rendering in the browser.

In the example below, the trackEvent() call is wrapped in an if() that checks which environment the code is being run in. The event will only be sent when rendering client-side. If there was also a server-side render, an event would not have been sent.

import wixWindow from 'wix-window';

$w.onReady(function () {
 if(wixWindow.rendering.env === "browser") {
    wixWindow.trackEvent("ViewContent", {
      id: "P12345",
      name: "Really Fast Running Shoes",
      category: "Apparel/Shoes",
      price: 120,
      currency: "USD",
      brand: "Adidas",
      variant: "Black",
      position: 1
    } );
  }
} );
10 Likes

<3

excellent

I’ve got a question. Even if code is not being used, will sites in general load faster? Is this for mobile and desktop also.

Wix is the future

Hi Yoav,
can you please update

in new rendering condition.
Thank you very much!!!

This is great! Wix Rules B-)

So basically this rendering code is needed in a page that interacts with database right?

How about this statement in one of the article provided here: “For example, if you call the expand() function in your page’s onReady() event handler to display an image that was set in the Editor to be collapsed on load, the expand() might be called twice. The first time expand() is called it will expand the image. The second time it is called it won’t do anything.”

Will running the expand code twice slowing down page load? Should that need to be configured as well?

Can we clarify that if we have code on the sites with forms, databases and dynamic pages, interactions, we need to go back and add some extra code to make sure it works. You mention "These include:

  • Code that causes a side effect.

  • Code that must be run in the browser."
    Do the cases above fall under these two categories? Sorry just want to make sure I’m ready…

So all code that needs to run in the clients browser like redirects, use of local storage, cookies and also all kinds of GEO functions must be inside wixWindow.rendering.env === “browser” to make sure it is executed on the browser and not the server.

Also all kinds of actions that will actually insert or do something should be inside wixWindow.rendering.renderCycle === 1 so we make sure it is executed only once and not twice.

So if we use these two things we will be all good I guess?

WOW - so glad I stumbled upon this post. Will have to make a lot of changes.

I want to get it right so I’m going to second Ivan Terechin’s request to update
https://support.wix.com/en/article/how-to-create-member-profile-pages-with-wix-code
to reflect the rendering logic.

andluism,

You only need to worry if you call your database in the $w.onReady function, or before that as part of the global script scope.

As for expand running twice - the impact is minimal, as one runs on the server, one on the client.

lorraine,

In most cases you need not do anything. This include (the safe category)

  • Data Binding

  • Dynamic Pages

  • Forms

  • Any Event handler

  • Any code in $w.onReady that only uses $w APIs

Hay Andreas,

You are right.

But also note that any event handler (e.g. onClick) only runs on the client, as no one will click a button on the server.

wix need to improve loading time on any network any computer my site loading slow and heavy

I had decided to move away from Wix due to site loading times. So needless to say, Will my photo gallery’s load faster now? Will I be able to upload better quality images and not have to sacrifice load time?

Hi,
My Plant Library site (domain www.theplantlibrary.co.za) (site name the-plant-li) looks terrible on small/ mobile screens as the text and image galleries overlap, and it looks as though each gallery is added twice. Perfect on a desktop. I’m trying to work out if and where to add the suggested code. My page codes look like this:

imp ort {local} from “wix-storage”;
const linkField = “link-Plants-title”;

$w.onReady(function () {
setUrls(‘#grasslandTrees’, ‘trees’);
setUrls(‘#grasslandShrubs’, ‘shrubs’);
setUrls(‘#grasslandPerennials’, ‘perennials’);
setUrls(‘#grasslandSucculents’, ‘succulents’);
setUrls(‘#grasslandGroundcovers’, ‘groundcovers’);
setUrls(‘#grasslandBulbs’, ‘bulbs’);
setUrls(‘#grasslandGrass’, ‘grass’);
});

function setUrls(datasetSelector, galleryCategory) {
$w(datasetSelector).onReady(() => {
const numberOfItems = $w(datasetSelector).getTotalCount();
$w(datasetSelector).getItems(0, numberOfItems)
.then( (result) => {
const plantsTitle = result.items.map(item => item[linkField]);
local.setItem(galleryCategory, plantsTitle);
})
.catch( (err) => {
console.log(err.code, err.message);
});
});
}

export function trees_click() {
local.setItem(‘selected-gallery’, ‘trees’);
}
export function shrubs_click() {
local.setItem(‘selected-gallery’, ‘shrubs’);
}
export function perennials_click() {
local.setItem(‘selected-gallery’, ‘perennials’);
}
export function succulents_click() {
local.setItem(‘selected-gallery’, ‘succulents’);
}
export function groundcovers_click() {
local.setItem(‘selected-gallery’, ‘groundcovers’);
}
export function bulbs_click() {
local.setItem(‘selected-gallery’, ‘bulbs’);
}
export function grass_click() {
local.setItem(‘selected-gallery’, ‘grass’);
}

So do I add your code below? If so, where, and what do I replace the #myText with?

import {local} from ‘wix-storage’;

import wixWindow from ‘wix-window’;

$w.onReady( function () {

if (wixWindow.rendering.env === “browser”) {

$w(" #myText ").text = local.getItem(“key”);
}

} );
}

Those of you wondering about SPEED IMPROVEMENTS ought to read my experience

Has this gone live now? I’m not seeing any difference in load time.

I don’t think it’s live yet? I tried making some basic code with an if statement, that runs only on the backend and nothing happens. Maybe we had until today to update it and it goes into effect tomorrow?

if wixWindow.rendering.env === 'backend' {
**test code**
}