Performance

Please find here all the hands-on best practices to keep your admin panel performant. Depending on your user’s needs, you might either hide or optimize some fields to limit the number of components, avoid a large datasets display or rework complex logic. You can display bellow performances improvement tricks in this video. For any further help to improve admin panel performances, get in touch with the community.

Layout optimization

1. Show only Smart fields you absolutely need.

As you can see in the Loading time benchmark below, Smart fields can be quite costly in terms of loading performance. Limiting them to those you need is key.

2. Reduce the number of records per page

3. Reduce the number of fields displayed

You can hide some fields in your table view; this will not prevent you from seeing them in the record details view.

Relationship fields are links to other collection records within your table view:

Having Relationship fields can decrease your performance, especially if your tables have a lot of records. Therefore you should display only those you need and use!

Optimize smart fields performance

To optimize your smart field performances, please check out this section.

Restrict search on specific fields

Sometimes, searching in all fields is not relevant and may even result in big performance issues. You can restrict your search to specific fields only using the searchFields option.

Rails

In this example, we configure Forest to only search on the fields name and industry of our collection Company.

class Forest::Company
  include ForestLiana::Collection

  collection :Company

  search_fields ['name', 'industry']

  action 'Mark as Live'

# ...
end

Disable pagination count

This feature is only available if you’re using the forest-express-sequelize (v8.5.3+), forest-express-mongoose (v8.6.5+), forest-rails (v7.5.0+) or django-forestadmin (v1.2.0+) agent.

To paginate tables properly, Forest triggers a separate request to fetch the number of records. In certain conditions, usually, when your database reaches a point where it has a lot of records, this request can decrease your loading performance. In this case, you can choose to disable it…

Rails
Django
Laravel

creating a controller in the repository lib/forest_liana/controllers for override the count action

class Forest::BooksController < ForestLiana::ResourcesController
  def count
    deactivate_count_response
  end
end

adding a route in app/config/routes.rb before mount ForestLiana::Engine => '/forest'

namespace :forest do
    get '/Book/count' , to: 'books#count'
end

adding a route in app/routes/web.php

To disable the count request in the table of a relationship (Related data section):

Rails
Django

class Forest::BookCompaniesController < ForestLiana::AssociationsController
  def count
      if (params[:search])
        params[:collection] = 'Book'
        params[:association_name] = 'company'
        super
      else
        deactivate_count_response
    end
  end
end

namespace :forest do
    get '/Book/:id/relationships/companies/count' , to: 'book_companies#count'
end

You can also disable the count request in a collection only in certain conditions. For instance, you can disable the count if you’re using a filter:

class Forest::BooksController < ForestLiana::ResourcesController
  def count
    if (params[:filters])
      params[:collection] = 'Book'
      super
    else
      deactivate_count_response
    end
  end
end

One more example: you may want to deactivate the pagination count request for a specific team:

class Forest::BooksController < ForestLiana::ResourcesController
  def count
    if forest_user['team'] == 'Operations'
      deactivate_count_response
    else
      params[:collection] = 'Book'
      super
    end
  end
end

Database Indexing

Indexes are a powerful tool used in the background of a database to speed up querying. It power queries by providing a method to quickly lookup the requested data. As Forest generates SQL queries to fetch your data, creating indexes can improve the query response time. 5. Index the Primary and Unique Key Columns
The syntax for creating an index will vary depending on the database. However, the syntax typically includes a CREATE keyword followed by the INDEX keyword and the name we’d like to use for the index. Next should come the ON keyword followed by the name of the table that has the data we’d like to quickly access. Finally, the last part of the statement should be the name(s) of the columns to be indexed.

CREATE INDEX <index_name>ON <table_name> (column1, column2, ...)

For example, if we would like to index phone numbers from a customers table, we could use the following statement:

CREATE INDEX customers_by_phoneON customers (phone_number)

The users cannot see the indexes, they are just used to speed up searches/queries. 6. Index the Foreign Key Columns Foreign key columns should be indexed if they are used intensively in Smart fields. In the table below, you can see how drastically it reduces the loading time of the page.

Updating a table with indexes takes more time than updating a table without (because the indexes also need an update). So, only create indexes on columns that will be frequently searched against.

Loading time benchmark

Below is the outcome of a performance test on page load time of the Table view. It highlights the importance of using indexes and limiting the number of columns and lines.

Overview

JavaScript Agents

Ruby Agent

Layout optimization

Optimize smart fields performance

Restrict search on specific fields

Rails

Database Indexing

Loading time benchmark

​Layout optimization

​Optimize smart fields performance

​Restrict search on specific fields

​Rails

​Disable pagination count

​Database Indexing

​Loading time benchmark

Layout optimization

Optimize smart fields performance

Restrict search on specific fields

Rails

Disable pagination count

Database Indexing

Loading time benchmark