Jak zwiększyć FPS w Minecraft bez shaderów? Java i Bedrock

Chcesz zwiększyć FPS w Minecraft, ale nie używasz shaderów? Zacznij od ustalenia, co właściwie widzisz na ekranie. Licznik FPS opisuje pracę Twojego klienta, a nie jakość połączenia i nie szybkość symulacji serwera. Gdy obraz klatkuje, przyczyną może być renderowanie bloków, generowanie nowych chunków, zapełniona pamięć, temperatura laptopa, mod, sterownik albo zwyczajnie serwer działający z wysokim MSPT. Obniżenie losowego suwaka czasem pomaga, lecz równie często maskuje problem i psuje widoczność świata.

Poniżej testujemy Minecraft Java i Bedrock bez shaderpacków. Najpierw rozdzielamy FPS, ping, TPS i MSPT, później budujemy powtarzalny benchmark. Dopiero na tej podstawie dobieramy ustawienia vanilla, Sodium, pamięć JVM, sterowniki i profil urządzenia. Każdy komputer, telefon i serwer ma inny limit, dlatego nie podajemy obietnicy „plus 200 FPS”. Wynikiem dobrej optymalizacji jest stabilna klatka, krótsze przycięcia i czytelna gra przy rozsądnej temperaturze — nie najwyższa liczba w pustym menu.

Szybka diagnoza niskiego FPS

Zanim zmienisz konfigurację, odpowiedz na cztery pytania. Czy problem występuje także w nowym, pustym świecie? Czy pojawia się po wejściu na konkretny serwer? Czy klatki spadają podczas obracania kamery, czy dopiero wtedy, gdy otwierasz dużą bazę z mobami i redstone? Czy po kilku minutach laptop robi się gorący, a wentylator zwalnia? Te obserwacje zawężają przyczynę szybciej niż instalowanie kolejnych „boosterów”.

Jeśli FPS jest niski już w menu lub przy obracaniu kamery w pustym świecie, zacznij od klienta i sterownika. Jeśli licznik pozostaje wysoki, lecz bloki cofają się, gracze teleportują, a moby reagują z opóźnieniem, przejdź do sekcji o ping, TPS i MSPT. Jeżeli problem występuje tylko przy doczytywaniu terenu, testuj render distance, pamięć i obciążenie CPU. Jedna instalacja może mieć kilka problemów naraz, ale każdy powinien dostać osobny test.

FPS, ping, TPS i MSPT – cztery różne wskaźniki

FPS (frames per second) to liczba klatek narysowanych w ciągu sekundy przez urządzenie gracza. Wysoki FPS daje płynny obraz i krótszy czas między próbkami sterowania, ale nie przyspiesza logiki serwera. Ping jest opóźnieniem wymiany pakietów między klientem a serwerem; rośnie przy słabym Wi‑Fi, odległym centrum danych lub przeciążeniu sieci. Możesz mieć 120 FPS i 180 ms pingu albo 45 FPS i świetne 25 ms.

TPS (ticks per second) opisuje tempo, w jakim serwer wykonuje ticki świata. Wartość docelowa to 20 TPS, czyli jeden tick co około 50 ms. MSPT (milliseconds per tick) pokazuje, ile czasu serwer potrzebuje na obliczenie jednego ticka: przy MSPT nieprzekraczającym około 50 ms może utrzymać 20 TPS, a gdy obliczenie trwa dłużej, TPS spada. MSPT nie jest FPS-em i nie mierzy karty graficznej gracza.

W praktyce wskaźniki mogą się nakładać. Serwer wysyłający bardzo dużo encji zwiększy pracę klienta i obniży FPS, ale jego wysoki MSPT nadal jest osobnym problemem. Zanim zgłosisz „lagi”, porównaj lokalny świat z tym samym profilem oraz sprawdź jak mierzyć ping i TPS. Przy podejrzeniu przeciążenia serwera przydatny będzie też poradnik diagnostyki spark.

Jak zmierzyć poprawę bez zgadywania

Benchmark Minecraft nie musi być laboratoryjny, ale powinien być powtarzalny. Utwórz kopię świata albo nowy świat testowy, ustaw tę samą wersję i stań w miejscu, które potrafisz odtworzyć: na przykład przy wejściu do bazy, patrząc na farmę, lub na płaskim odcinku terenu. Nie porównuj widoku oceanu o świcie z gęstą dżunglą w deszczu. Światło, cząsteczki, liście, moby i doczytywanie chunków potrafią zmienić wynik bardziej niż drobna opcja graficzna.

1. Uruchom czysty profil bez shaderów, dodatkowych resource packów i nakładek nagrywania.
2. Odczekaj chwilę po wejściu do świata, aby pierwsze chunki i tekstury nie zafałszowały pomiaru.
3. Przez 60–120 sekund poruszaj kamerą według tej samej trasy; zanotuj średni FPS i momenty przycięć.
4. Zapisz użycie GPU, CPU, pamięci oraz temperaturę. Na Java użyj F3 lub profilu wydajności, a na systemie obserwuj monitor sprzętowy.
5. Zmień dokładnie jeden parametr, zrestartuj grę tylko wtedy, gdy jest to wymagane, i powtórz trasę.
6. Po trzech porównywalnych próbach wybierz ustawienie, które daje stabilny frametime, nie maksymalny pojedynczy odczyt.

Limit FPS ustaw tymczasowo na wartość, którą monitor i komputer mogą utrzymywać. Nieograniczony licznik może obciążać GPU do 100% w prostym widoku, zostawiając mniej zapasu na bazę, deszcz lub generowanie terenu. Jeśli masz monitor 60 Hz, stabilne 60 klatek może być lepsze niż skoki 45–140; dla szybszego monitora dobierz limit do realnej średniej i sprawdź, czy V-Sync albo VRR nie wprowadzają dodatkowego opóźnienia.

F3 jest narzędziem diagnostycznym, nie konkursem. Otwarty rozbudowany ekran debugowania może sam zwiększać koszt renderowania w niektórych wydaniach. Jeżeli wersja oferuje profil wydajności w opcjach debugowania, użyj go do krótkiego odczytu, a właściwy benchmark wykonaj z zamkniętym panelem. Zapisz wersję gry i ustawienia razem z wynikiem, aby za miesiąc wiedzieć, co naprawdę się zmieniło.

Ustawienia vanilla Java Edition

Najpierw zoptymalizuj profil bez modów. W Java największy koszt zwykle tworzą renderowane chunki, encje, efekty i generowanie terenu. Zmniejszaj opcje od tych, które ograniczają dużo pracy, a niewiele psują czytelność. Nie ustawiaj wszystkich suwaków na minimum w ciemno: zbyt mały dystans może utrudnić orientację i zwiększyć liczbę nagłych doczytań, gdy szybko przemieszczasz się Elytrą.

Rozdzielczość jest osobnym przełącznikiem. Jeśli GPU stale pracuje na granicy możliwości, zejście z 1440p do 1080p może pomóc bardziej niż zmiana kilku drobnych efektów, ale obraz i interfejs będą mniej ostre. Na laptopie wybierz tryb pełnoekranowy, podłącz zasilacz i sprawdź, czy system używa dedykowanej karty, a nie energooszczędnego układu zintegrowanego. Nie wyłączaj zabezpieczeń systemu ani nie instaluj nieznanych „driver updaterów”.

Java 26.2 ma w ustawieniach wideo wybór Graphics API: Default, Prefer Vulkan (Experimental) i Prefer OpenGL. Oficjalny changelog Java 26.2 ↗ (otwiera w nowej karcie) opisuje Vulkan jako eksperymentalny; domyślnie gra obecnie preferuje OpenGL, a przy problemie może wrócić do bezpieczniejszego ustawienia. Nie traktuj Vulkan jako gwarantowanego boostera. Zmierz oba tryby na tym samym profilu, a jeśli używasz modów renderujących, sprawdź ich dokumentację przed zmianą backendu.

Wysoki render distance nie naprawia serwerowego view-distance. Na multiplayerze klient otrzyma najwyżej tyle chunków, ile pozwala serwer, więc ustawienie 32 nie stworzy danych, których serwer nie wysyła. Z kolei ustawienie zbyt niskie może utrudnić nawigację i zwiększyć poczucie „doczytywania ściany”. Szukaj kompromisu, który jest stabilny w miejscu typowym dla Twojej gry, nie w pustym superpłaskim świecie.

GPU, CPU, chunki i frametime

Średni FPS nie mówi, które urządzenie jest wąskim gardłem. Gdy GPU jest blisko 95–100% użycia, pierwsze podejrzenia to rozdzielczość, render distance, cząsteczki, przezroczystości i resource pack. Zmniejszenie efektów powinno obniżyć użycie GPU i poprawić frametime. Gdy GPU jest wolne, a jeden rdzeń CPU pracuje wysoko, problemem może być generowanie chunków, dużo encji, redstone, wysoka symulacja albo mod. Wtedy obniżenie jakości tekstur niewiele zmieni.

Przy szybkim locie lub pierwszym wejściu do nowego terenu chwilowy spadek FPS jest często kosztem generowania i kompilacji chunków. Zatrzymaj się, pozwól światu doczytać, a potem powtórz benchmark. Jeśli przycięcia powtarzają się w tej samej bazie, policz moby, przedmioty, lejki, obrazy i armor standy. Wyczyść zbędne encje zgodnie z zasadami świata, zamiast podnosić RAM bez końca. Na serwerze zgłoś administratorowi lokalizację i czas spadku, aby mógł porównać go z MSPT.

„Stutter” to nierówny czas klatek. Możesz widzieć 100 FPS, lecz co kilka sekund czekać na jedną bardzo długą klatkę. Ograniczenie FPS do stabilnego poziomu, wyłączenie nakładek, zamknięcie przeglądarki z filmem i sprawdzenie temperatury często daje lepsze odczucie niż podbijanie maksymalnego licznika. Jeżeli stutter pojawia się tylko po alt-tabie, nagrywaniu albo zmianie okna, testuj te elementy osobno.

Sodium, Fabric i NeoForge – aktualny sposób użycia

Sodium jest modem klienckim, który zastępuje część renderera Java i ogranicza mikroprzycięcia. Nie instaluje się go w Bedrock, na serwerze Paper ani w przypadkowym profilu z innym loaderem. Bieżąca karta projektu na Modrinth ↗ (otwiera w nowej karcie) wymienia obsługiwane wydania Java, w tym 26.2 i 26.1.x, platformy Fabric, NeoForge oraz Quilt i środowisko client-side. Te informacje są zależne od konkretnego pliku; napis „działa na 1.21” nie oznacza automatycznie zgodności z każdą wersją 1.21.x.

Najbezpieczniejsza konfiguracja zaczyna się od osobnej instalacji gry. Zapisz kopię świata, utwórz profil dla jednej wersji, uruchom go raz bez modów i dopiero wtedy dodaj Sodium. Na Fabric sprawdź, czy projekt wymaga Fabric API; na NeoForge pobierz wydanie oznaczone tym loaderem. Nie wkładaj JAR-a Fabric do folderu NeoForge ani odwrotnie. Jeśli używasz launchera z instancjami, upewnij się, że folder mods należy do aktywnego profilu, a nie do globalnego .minecraft. Jeżeli dopiero tworzysz taki profil, pełną ścieżkę krok po kroku znajdziesz w poradniku instalacji modów Fabric i NeoForge.

Oficjalna instrukcja Fabric dotycząca instalacji modów ↗ (otwiera w nowej karcie) podkreśla zgodność wersji, loadera i edycji Java oraz umieszczenie plików JAR w folderze mods. Dokumentacja NeoForge dla klienta ↗ (otwiera w nowej karcie) zaleca osobny katalog gry i kopię świata przed aktualizacją. Traktuj te zalecenia jako część optymalizacji: profil, który można łatwo cofnąć, pozwala znaleźć winowajcę bez ryzyka dla głównego świata.

Sodium nie poprawia każdego rodzaju problemu. Zgodnie z opisem projektu skupia się na renderowaniu; obciążenie logiki, AI i ticków to inna warstwa. Dodatki takie jak Lithium mogą pomóc w określonych konfiguracjach, lecz ich zgodność z modpackiem, serwerem i wersją trzeba sprawdzić osobno. Nie instaluj paczki „FPS boost” z nieznanej strony, która wymaga wyłączenia antywirusa albo obiecuje stały wynik bez podania sprzętu. Najpierw zmierz vanilla, później Sodium, a na końcu każdy następny mod.

Jeśli planujesz shadery, nie dokładaj ich do tego testu. Iris i shaderpack zmieniają koszt renderowania zupełnie inną ścieżką; zgodność tych elementów opisuje sąsiedni poradnik Iris i shaderów. Dzięki temu ten artykuł pozostaje punktem odniesienia dla czystej, wydajnej gry.

RAM, JVM, sterowniki i temperatury

Przydzielona pamięć nie jest suwakiem FPS. Gdy heap jest zbyt mały, gra może często sprzątać obiekty i doczytywać dane; gdy ustawisz go ogromny, garbage collector może zatrzymywać grę dłużej, a systemowi zabraknie miejsca dla sterownika, przeglądarki i zintegrowanej grafiki. Jako punkt startowy dla czystej vanilla Java wiele komputerów potrzebuje około 2–4 GB przydzielonego maksimum, podczas gdy ciężki modpack wymaga więcej. To heurystyka, nie gwarancja: obserwuj użycie pamięci, logi i stabilność, a nie samą liczbę w launcherze.

Nie oddawaj grze całej pamięci fizycznej. Zostaw zapas dla systemu, karty zintegrowanej i innych aplikacji. Zamiast kopiować „magiczne JVM flags” z filmu, zacznij od runtime dostarczonego przez launcher, poprawnego profilu i jednego parametru maksymalnego heapu ustawionego w jego interfejsie. Własne flagi dodawaj tylko z dokumentacją konkretnego launchera; trudny do odtworzenia zestaw utrudnia zgłoszenie crasha i porównanie wyników.

Gdy log lub F3 rzeczywiście wskazuje presję pamięci, użyj instrukcji zwiększania RAM w Minecraft Launcherze, Prism i CurseForge. Zawiera dobór Xmx do fizycznej pamięci i powtarzalny test; nie zwiększaj limitu dalej, jeśli GPU, CPU albo serwer pozostaje rzeczywistym ograniczeniem.

Oficjalne wymagania Java Edition ↗ (otwiera w nowej karcie) zostały zaktualizowane w 2026 roku: Mojang opisuje cel minimum jako 1080p/30 FPS na ustawieniu Fast, a cel zalecany jako 1080p/60 FPS na Fancy. To cele dla określonej klasy sprzętu, nie obietnica dla każdej mapy i odległości. Starszy komputer może nadal uruchomić grę, lecz poniżej minimum wydajność i jakość nie są gwarantowane. Przy zakupie sprzętu sprawdź aktualną stronę, zamiast kierować się dawnymi tabelami. Wszystkie progi CPU, GPU, RAM, VRAM i Vulkan 1.3 wraz z instrukcją sprawdzenia komputera zebraliśmy w aktualnych wymaganiach sprzętowych Minecraft.

Aktualny sterownik pobieraj bezpośrednio od producenta GPU. Po instalacji wykonaj jeden test w tym samym profilu; jeśli problem zaczął się dopiero po aktualizacji, zachowaj numer wersji i porównaj poprzedni stabilny sterownik. Na Windows wybierz profil wysokiej wydajności dla launchera, a na laptopie testuj z podłączonym zasilaczem. Monitoruj temperaturę CPU i GPU: po kilku minutach przegrzewanie może obniżyć taktowanie i stworzyć spadki, których nie widać w pierwszych 30 sekundach. Czyste chłodzenie i odpowiedni przepływ powietrza bywają skuteczniejsze niż kolejny mod.

Jeśli masz kartę zintegrowaną, część pamięci systemowej jest współdzielona z GPU. Duży resource pack, wysoka rozdzielczość i wiele otwartych aplikacji zmniejszają zapas. Wyłącz paczkę 256× lub 512× na czas diagnostyki, zamknij nagrywanie i porównaj tryb okienkowy z pełnym ekranem. Nie usuwaj folderu świata ani całego .minecraft w ramach „czyszczenia” — najpierw wykonaj kopię ustawień i przenieś tylko testową instancję.

Bedrock: render distance, simulation distance i Vibrant Visuals

W Bedrock nie instalujesz Sodium ani Java loadera. Zaczynasz od ustawień wideo właściwych dla urządzenia: Windowsa, konsoli, telefonu lub tabletu. Najważniejsze są render distance i simulation distance. Pierwsza określa, ile chunków klient rysuje; druga określa obszar wykonywania mechanik — między innymi zachowanie encji, spawn mobów, wzrost roślin i ruch płynów. Obniżenie render distance zwykle odciąża renderowanie, a obniżenie simulation distance może zmniejszyć pracę CPU, lecz zmienia działanie świata.

Aktualny przewodnik Microsoftu o render distance, simulation distance i ticking areas ↗ (otwiera w nowej karcie) wyjaśnia, że simulation distance jest zawsze nie większa od render distance i kosztuje również serwer. Na urządzeniu z krótkim zasięgiem zacznij od umiarkowanego render distance, wyłącz zbędne cząsteczki i sprawdź, czy texture pack nie podnosi rozdzielczości. Na Realmie lub serwerze klient może być dodatkowo ograniczony wartością wysyłaną przez operatora; lokalny suwak nie stworzy chunków, których serwer nie udostępnia.

Vibrant Visuals to lokalna, kosmetyczna aktualizacja renderera Bedrock, nie wspólny wymóg serwera. Oficjalna strona Vibrant Visuals Minecraft ↗ (otwiera w nowej karcie) wymienia kompatybilne urządzenia i przełącznik w Ustawieniach → Wideo. Tryb dodaje między innymi kierunkowe światło, odbicia i atmosferę, więc na słabszym sprzęcie może obniżyć FPS. Wybierz priorytet wydajności, rozwiń opcje trybu i wyłącz go, jeśli nadal występują skoki frametime. To efekt klienta: znajomi mogą grać bez niego, a mechanika świata pozostaje taka sama.

Na telefonie ogranicz także temperaturę i procesy w tle. Długie granie na ładowarce może uruchomić ochronne obniżenie taktowania; sprawdź wynik po schłodzeniu urządzenia, nie tylko zaraz po uruchomieniu. Wyłącz nagrywanie ekranu, zamknij komunikatory z nakładką i ustaw stały limit klatek, który telefon utrzymuje. Jeśli opcja Vibrant Visuals nie występuje, nie twórz ręcznie folderu ani nie instaluj pliku Java — brak przełącznika zwykle oznacza niezgodność sprzętu lub wersji.

Simulation distance nie jest zamiennikiem render distance. Możesz widzieć odległy teren, który nie jest symulowany, albo mieć działającą ticking area bez wyświetlania wszystkich chunków. Przy farmach sprawdź, czy obniżenie symulacji nie zatrzymało mobów i roślin; przy multiplayerze zapytaj operatora o jego view-distance i limity encji.

Kiedy problem leży po stronie serwera

Wchodząc na serwer, wykonaj ten sam test, który działał w świecie lokalnym. Jeżeli FPS spada wyłącznie w jednej bazie, przyczyną mogą być setki mobów, itemów, hopperów, map lub cząsteczek wysyłanych do klienta. Jeżeli wszyscy gracze odczuwają opóźnienie, a TPS spada, klientowy Sodium nie naprawi ticków. Administrator powinien sprawdzić MSPT, profil spark, liczbę encji, generowanie chunków i pluginy; gracz może dostarczyć godzinę, lokalizację i nagranie z wartościami FPS/pingu.

Wysoki ping objawia się inaczej niż niski FPS: blok może postawić się z opóźnieniem, gracz cofa się po ruchu, a czat przychodzi później. Zmiana render distance albo RAM-u nie skróci trasy pakietu. Spróbuj kabla, innego Wi‑Fi, serwera bliżej regionu i testu bez VPN, ale nie obwiniaj hostingu bez porównania. Na serwerze Java sprawdź też, czy klient ma dokładną wersję i czy regulamin dopuszcza mody wyłącznie klienckie.

Farmy i duże bazy łączą oba rodzaje obciążenia. Serwer liczy encje, a klient je renderuje. Zmniejszenie entity distance może poprawić FPS bez usuwania mobów, natomiast ograniczenie simulation distance może zmienić działanie farmy. Zapisz ustawienie przed zmianą i poinformuj innych graczy, jeśli testujesz je na wspólnym świecie.

Diagnostyka spadków i stutteringu

Poniższa tabela pomaga przejść od objawu do małego, odwracalnego testu. Nie wykonuj wszystkich kroków jednocześnie; inaczej nie będzie wiadomo, co pomogło. Po każdej zmianie wróć do tej samej trasy benchmarku i zachowaj wynik.

Przy crashu zachowaj latest.log i plik z crash-reports. Zapisz wersję gry, loadera, Sodium, systemu, GPU, sterownika i aktywnych paczek. Pierwszy błąd zależności jest zwykle bardziej użyteczny niż ostatnia linia „game crashed”. Na Fabric skorzystaj z dokumentacji logów, na NeoForge przywróć kopię świata zgodnie z jego instrukcją. Gdy winny jest mod, dodawaj pliki metodą połowy: wyłącz połowę, sprawdź wynik, a potem zawężaj zestaw.

Nie kasuj całego katalogu .minecraft jako uniwersalnej porady. Możesz stracić światy, zrzuty ekranu, ustawienia i resource packi. Najpierw skopiuj saves, screenshots oraz konfigurację, a testową instancję wskaż w osobnym katalogu. Jeśli problem zniknie, przywracaj pliki etapami.

Gdy diagnostyka wskazuje serwer, przekaż administratorowi dane zamiast instalować klientowy mod na serwerze. Opis lagów i niskiego TPS pomaga rozdzielić ticki, pamięć i pluginy, a server.properties wyjaśnia różnicę między serwerowym view-distance a lokalnym render distance.

Profile dla słabszego sprzętu

Nie każdy potrzebuje tego samego kompromisu. Dla starego laptopa ważniejszy jest stabilny limit i niska temperatura; dla komputera z mocnym GPU, ale słabym CPU, kluczowe będą chunki, encje i simulation distance. Na telefonie lub konsoli zacznij od trybu wydajności i krótszego dystansu, a dopiero potem podnoś jakość. Trzy gotowe profile ułatwiają start, lecz nadal zmierz je w swojej bazie.

Profil „wydajność” nie musi wyglądać brzydko. Zachowaj czytelne tekstury, rozsądny dystans i stabilne oświetlenie, a ogranicz najdroższe elementy: cząsteczki, chmury, cienie encji, wysoką rozdzielczość paczek i niepotrzebne nakładki. Płynna kamera pomaga w walce i budowaniu bardziej niż chwilowy pik FPS w pustym niebie.

Końcowa checklista optymalizacji

Przejdź przez listę od góry do dołu i zatrzymaj się, gdy problem znika. Zachowaj notatkę z działającym profilem — ułatwi powrót po aktualizacji Minecrafta, sterownika albo modów.

1. Rozróżnij FPS klienta od pingu, TPS i MSPT; nie zgłaszaj ich jako jednego „lagu”.
2. Wykonaj powtarzalny benchmark w tym samym świecie, miejscu i rozdzielczości.
3. Wyłącz shaderpack, ciężki resource pack, nagrywanie i nakładki na czas pomiaru.
4. Obniżaj po jednej opcji vanilla: render distance, entity distance, cząsteczki, chmury i jakość grafiki.
5. Sprawdź użycie GPU/CPU, frametime, pamięć, temperaturę, tryb zasilania i sterownik.
6. W Java dobierz Sodium do dokładnej wersji oraz jednego loadera; trzymaj instancję i świat w kopii.
7. W Bedrock ustaw osobno render distance, simulation distance i Vibrant Visuals, pamiętając o ograniczeniach urządzenia i serwera.
8. Po zmianie powtórz test i wybierz ustawienie, które jest stabilne przez całą sesję, nie tylko przez pierwsze sekundy.

Jeśli po tych krokach lokalny świat działa płynnie, a konkretny serwer nadal reaguje z opóźnieniem, masz mocny dowód, że trzeba sprawdzić sieć albo serwer, nie kolejną paczkę FPS. Jeżeli spadki występują wszędzie, wróć do monitorowania GPU, CPU, pamięci i temperatur. Mała, odwracalna zmiana z pomiarem jest bezpieczniejsza niż „optymalizator” bez źródła i bez możliwości cofnięcia.