Lightna Lane

Migration to Lightna might take lots of effort if a project is complex and heavily customized. Lightna Lane makes it possible to use Lightna without full migration. It allows to move only some features to Lightna and keep the rest on the existing solution.

Key possibilities:

• A project can keep using an existing design
• Rendering of any block on the website can be delegated to Lightna
• Smooth full-migration of a project to Lightna

You have total control on how deep optimization you need and can afford. Here is a step-by-step guide:

1. Equip by Lightna and start using it when implementing new features.
   • This way you will mitigate further performance degradation.
2. Migrate existing customizations to Lightna.
3. Migrate third-party customizations to Lightna.
   • On this stage you will get default website performance, like it hasn't been customized.
4. Migrate default features to Lightna.
   • You outplay the default performance.
5. Migrate Javascript to Lightna.
   • Performance gains on the client side can be substantial if the current JavaScript structure is suboptimal
6. Migrate design to Lightna.
   • Gains might vary depending on the project.
7. Switch page fully to Lightna.
   • Excellent server-side performance.
   • Excellent web vitals.

Using Lightna Lane in your development you prevent further performance degradation and create opportunities for future improvements while gradually progressing toward a fully optimized Lightna page.

Lightna block is attached to Magento 2 block by lightna_block_id argument:

<referenceContainer name="page.wrapper">
    <block name="lightna.header" before="main.content">
        <arguments>
            <argument name="lightna_block_id" xsi:type="string">header</argument>
        </arguments>
    </block>
    <block name="lightna.footer" before="before.body.end">
        <arguments>
            <argument name="lightna_block_id" xsi:type="string">footer</argument>
        </arguments>
    </block>
</referenceContainer>

Block Id is defined in Lightna's layout file:

.body:
  .header:
    id: header
  .footer:
    id: footer

Data in Lightna's block is requested from Data classes by PHPDoc:

<?php
/** @var Lightna\Magento\Data\Session $session */
$isLoggedIn = $session->user->groupId !== 0;
$iconClass = $isLoggedIn ? 'icon-user__filled' : 'icon-user__outline';
?>
<div class="icon-dropdown dropdown">
    <div class="header__icon header__icon--hover">
        <a href="/customer/account" class="icon <?= $iconClass ?>"></a>
    </div>
    <?php if ($isLoggedIn): ?>
        <?= block('customer') ?>
    <?php else: ?>
        <?= block('guest') ?>
    <?php endif; ?>
</div>

On Lightna Demo there are Lane pages - these pages are rendered by Magento 2 together with Lightna blocks. For example, Lane Login Page has header and footer rendered by Lightna.

Header and footer aren't "heavy" blocks in Magento 2 by default, so the difference in server time is 635ms vs 583ms in favor of Lightna Lane. To compare you can visit the same Login Page with "?disable_lane" GET parameter Magento Login Page.

Worth to mention that opcache on demo is disabled for Magento intentionally, to make it, at least, a bit closer to real/customized project performance.

On real projects, where server rendering takes more than a second, you can find way "juicier" blocks to replace.

Even by default there are better candidates to migrate to Lightna. For example, related products block takes 21% of rendering time. Empty upsell block takes 3ms which is enough for Lightna to render a complete page.

Lightna Lane might be very useful for uncachable private pages that require optimizations, such as account pages, checkout pages, etc.