Po migracji do Divi 5 wiele stron działa poprawnie, ale nadal pozostaje w Backward Compatibility Mode. Dla wielu użytkowników to moment niepewności: skoro wszystko wygląda dobrze, to po co w ogóle przejmować się tym komunikatem?
Odpowiedź jest prosta: Backward Compatibility Mode nie oznacza awarii, ale oznacza, że projekt nadal opiera się częściowo na starszej warstwie Divi 4. Elegant Themes opisuje ten mechanizm jako sposób na uruchamianie legacy modules i niezgodnych dodatków przy użyciu frameworka Divi 4, tak aby strona mogła dalej działać po migracji.
To prowadzi do ważniejszego pytania. Nie: czy strona działa, tylko: co realnie zyskuję, kiedy przestaje już polegać na compatibility mode i działa natywnie na Divi 5?
Czym właściwie jest Backward Compatibility Mode
Backward Compatibility Mode to warstwa przejściowa. Jej zadaniem jest utrzymanie działania starszych modułów Divi 4 i niektórych dodatków firm trzecich po migracji do Divi 5. Gdy Divi wykrywa legacy modules albo nieprzystosowane jeszcze third-party modules, uruchamia dla nich starszy framework Divi 4 zamiast natywnej architektury Divi 5.
To oznacza, że strona może działać poprawnie, ale technicznie nie jest jeszcze „w pełni na Divi 5”. Ona raczej działa na Divi 5 z włączonym pomostem do Divi 4.
Co naprawdę daje wyjście z Backward Compatibility Mode
1. Mniej narzutu legacy
Najbardziej oczywista korzyść jest techniczna: gdy projekt wychodzi z compatibility mode, przestaje ładować starszy framework Divi 4 dla tych elementów, które wcześniej go wymagały. Elegant Themes pisze wprost, że legacy modules i niezgodne third-party modules działające w backward compatibility wiążą się z kosztem wydajnościowym.
W praktyce oznacza to, że projekt ma mniej starego balastu technicznego i lepsze warunki do korzystania z nowego silnika Divi 5.
2. Pełniejsze wykorzystanie natywnej architektury Divi 5
Divi 5 nie jest zwykłą aktualizacją wizualną. ET opisuje je jako przebudowę kodu od podstaw, z nowym API i nowocześniejszym fundamentem technologicznym. Gdy projekt wychodzi z compatibility mode, przestaje polegać na warstwie przejściowej i zaczyna działać bardziej zgodnie z tym, jak Divi 5 zostało zaprojektowane.
To ważne, bo dopiero wtedy naprawdę wchodzisz w nowy update path Divi 5, zamiast tylko uruchamiać stary projekt przez warstwę zgodności.
3. Lepsze warunki pracy w builderze
ET podkreśla, że strony natywne dla Divi 5 dają najlepsze doświadczenie pracy, podczas gdy legacy modules działające przez compatibility mode mogą wprowadzać dodatkowe tarcie i nie korzystają z pełnych usprawnień nowego buildera.
W praktyce nie chodzi tylko o szybkość strony na froncie, ale też o to, jak pracuje się w samym builderze:
-
jak szybko reaguje interfejs,
-
czy edycja jest spójna,
-
czy nie wchodzisz stale w zachowania charakterystyczne dla starszej warstwy.
4. Mniej zależności od niegotowych dodatków i starszych modułów
Jeśli projekt nadal siedzi w compatibility mode, to zwykle znaczy, że w środku nadal są:
-
legacy modules,
-
stare layouty,
-
dodatki firm trzecich bez pełnej zgodności,
-
elementy utrzymujące zależność od frameworka Divi 4.
Wyjście z Backward Compatibility Mode oznacza więc również mniejszy dług technologiczny. Projekt staje się prostszy do utrzymania, bardziej przewidywalny i mniej zależny od tymczasowych pomostów.
5. Prawdziwe przejście do Divi 5
To chyba najważniejsza korzyść, choć najmniej spektakularna wizualnie.
Strona może działać na Divi 5 i jednocześnie nadal polegać na compatibility mode. ET opisuje to wprost: istniejące treści i third-party legacy modules mogą dalej działać, ale dopóki ładują framework Divi 4, nie korzystasz jeszcze z pełnych ulepszeń wydajności i stabilności Divi 5.
Czyli wyjście z compatibility mode to nie kosmetyka. To moment, w którym projekt naprawdę przechodzi na nowy fundament.
Czego wyjście z Backward Compatibility Mode nie gwarantuje
To bardzo ważne i warto napisać to wprost.
Wyjście z Backward Compatibility Mode nie gwarantuje automatycznie:
-
spektakularnego skoku wyników PageSpeed,
-
natychmiastowego przyspieszenia każdej strony,
-
poprawy SEO samo z siebie,
-
rozwiązania wszystkich problemów projektu,
-
automatycznej poprawy jakości layoutu lub semantyki.
ET pisze, że compatibility mode niesie ze sobą koszt wydajnościowy, ale nie oznacza to jeszcze, że samo wyjście z tego trybu zawsze przełoży się na ogromny wzrost wyników. Skala efektu zależy od konkretnej strony, liczby modułów, dodatków, hostingu, obrazów i ogólnego stanu projektu.
To ważne, bo bardzo zmienia sposób myślenia o migracji. Wyjście z compatibility mode nie jest magicznym boosterem. To raczej usunięcie starej warstwy technicznej, które daje projektowi lepsze warunki do działania i rozwoju.
Kiedy naprawdę warto do tego dążyć
W praktyce warto walczyć o wyjście z compatibility mode szczególnie wtedy, gdy:
-
rozwijasz nowy projekt i chcesz budować już natywnie w Divi 5,
-
planujesz długoterminowe utrzymanie strony,
-
przebudowujesz Theme Builder lub ważne szablony,
-
korzystasz z wielu elementów, które da się już zastąpić natywnymi rozwiązaniami,
-
chcesz ograniczyć zależność od starszych dodatków i warstwy Divi 4.
Jeśli natomiast masz działającą stronę z dodatkami firm trzecich, które nie są jeszcze gotowe, compatibility mode może przez pewien czas być po prostu etapem przejściowym. ET wskazuje, że to normalny element migracji i że third-party modules będą stopniowo aktualizowane przez autorów.
Najważniejsze w 30 sekund
Wyjście z Backward Compatibility Mode w Divi 5 nie daje stronie nowego wyglądu. Daje jej nowy fundament. Oznacza mniej zależności od frameworka Divi 4, pełniejsze korzystanie z natywnej architektury Divi 5 i lepsze warunki do dalszego rozwoju projektu. Nie gwarantuje jednak automatycznie ogromnego wzrostu wydajności ani natychmiastowej poprawy wszystkich wyników.
Podsumowanie
Najlepiej patrzeć na Backward Compatibility Mode nie jak na błąd, ale jak na etap przejściowy. Strona może działać poprawnie, builder może się otwierać, a front może wyglądać dobrze — i mimo to projekt może nadal nie korzystać w pełni z tego, co oferuje Divi 5.
To właśnie dlatego wyjście z compatibility mode ma znaczenie.
Nie dlatego, że wszystko nagle stanie się szybsze i lepsze.
Tylko dlatego, że projekt przestaje opierać się na starszej warstwie Divi 4 i zaczyna działać naprawdę natywnie na nowej architekturze Divi 5.
