Przejdź do treści 
Optymalizuję szybkość wordpressa bez wtyczek za pomocą ręcznych interwencji, które w widoczny sposób skracają czas ładowania i niezawodnie wpływają na podstawowe parametry sieci. W ten sposób zachowuję kontrolę nad Żądaniazasobów i skutków ubocznych oraz wyeliminować balast u źródła.
Punkty centralne
- Zdjęcia Kompresja przed przesłaniem i konwersja do formatu WebP
- Leniwe ładowanie natywnie za pomocą atrybutu HTML zamiast przeciążonych rozszerzeń
- Buforowanie poprzez .htaccess/server i strategię czystego nagłówka
- Kod Minimalizowanie, łączenie i unikanie blokad renderowania
- Balast usuwanie w WordPress, bazie danych i motywach
Dlaczego optymalizuję bez wtyczek
Wtyczki wydają się wygodne, ale dodają żądania, skrypty i style, które blokują początkowe ścieżki renderowania i sprawiają, że moje TTFB pogarszać. Każda dodatkowa zależność zwiększa powierzchnię błędu i utrudnia analizę przyczyn spadków wydajności. Używam ręcznych środków, aby zmniejszyć łańcuchy obciążeń i zminimalizować liczbę aktywnych komponentów. Pozwala mi to zmniejszyć koszty ogólne, zachować elastyczność i szybciej reagować na nowe wymagania. Takie podejście zapobiega efektom ubocznym powodowanym przez łańcuchy aktualizacji i ogranicza konserwację do minimum. szczupły.
Odchudzanie obrazów: Formaty, rozmiary, kompresja
Duże obrazy nie zabijają czasu do pierwszego bajtu, ale dominują czas transferu i LCP, więc zmniejszam każdy zasób z góry. Eksportuję zdjęcia jako JPEG lub WebP i używam PNG tylko do prawdziwych przezroczystości. Skaluję wymiary dokładnie do wymaganych szerokości rzutni, zamiast ładować 4000 pikseli, gdy wystarczy 800 pikseli. Następnie konsekwentnie kompresuję za pomocą Squoosh, ImageOptim lub Photoshop i sprawdzam, czy nie ma widocznych artefaktów. W przypadku wariantów responsywnych polegam na srcset/sizes i lubię używać tego skrótu Przewodnik po obrazach responsywnychtak, aby przeglądarka automatycznie ładowała najmniejsze znaczące źródło i moje Transfer danych spadki.
Używaj leniwego ładowania natywnie
Ładuję obrazy i ramki iFrame tylko wtedy, gdy pojawiają się one w widoku, natywnie przez HTML5, zamiast integrować dodatkowe skrypty, które oznaczają Główny wątek load. Atrybut loading="lazy" jest całkowicie wystarczający w nowoczesnych przeglądarkach. W ten sposób zmniejszam liczbę początkowych bajtów i wyrównuję krytyczną fazę renderowania. Jednocześnie kontrolka pozostaje przezroczysta, a ja decyduję, które elementy powyżej złożenia celowo ładuję z niecierpliwością. Krytyczne obrazy bohaterów otrzymują loading="eager", wszystko inne się ładuje offset.
<img src="beispiel.jpg" alt="Przykładowy obraz" loading="lazy">
<iframe src="video.html" title="Wideo" loading="lazy"></iframe>Przyspieszenie LCP w ukierunkowany sposób: Priorytety i zastępcze rozwiązania
Aby poprawić stabilność Largest Contentful Paint, wyraźnie zaznaczam mój największy element above-the-fold. Obrazy otrzymują fetchpriority="high" i zdefiniowane wymiary, dzięki czemu przeglądarka preferuje je i CLS unika. W razie potrzeby dodaję obciążenie wstępne, jeśli ścieżka jest wolna.
<!-- LCP-Image priorisieren -->
<link rel="preload" as="image" href="/assets/hero.webp" imagesrcset="/assets/hero-800.webp 800w, /assets/hero-1200.webp 1200w" imagesizes="(min-width: 800px) 1200px, 100vw">
<img src="/assets/hero-800.webp"
srcset="/assets/hero-800.webp 800w, /assets/hero-1200.webp 1200w"
sizes="(min-width: 800px) 1200px, 100vw"
width="1200" height="700"
fetchpriority="high"
loading="eager"
decoding="async"
alt="Bohater">Dla obrazów i kontenerów ustawiam szerokość/wysokość lub współczynnik kształtuaby wykluczyć skoki układu. Dla obszarów niekrytycznych używam content-visibility: auto oraz contain-intrinsic-sizeaby przeglądarka mogła później renderować obszary poza rzutnią bez przesuwania układu.
/* Rezerwa above-the-fold */
.hero { aspect-ratio: 12/7; }
/* Układ niewidocznych sekcji później */
.section { content-visibility: auto; contain-intrinsic-size: 1000px; }
Konfiguracja buforowania przeglądarki
Powtarzający się odwiedzający powinni ładować statyczne zasoby z pamięci podręcznej, więc ustawiam czasy wygaśnięcia bezpośrednio na poziomie serwera poprzez htaccess lub w vHost. Długie TTL dla obrazów, umiarkowane dla CSS/JS i krótkie domyślne dla HTML zapewniają mi równowagę między terminowością a szybkością. Zwracam uwagę na spójne wersjonowanie plików, dzięki czemu aktualizacje wchodzą w życie natychmiast pomimo długich TTL. W połączeniu z nagłówkami ETags lub Last-Modified, ruch jest drastycznie zmniejszony. Oszczędza to przepustowość i skraca postrzegany czas oczekiwania. Czas załadunku.
ExpiresActive On
ExpiresByType image/jpg "dostęp plus 1 rok"
ExpiresByType image/jpeg "dostęp plus 1 rok"
ExpiresByType image/gif "dostęp plus 1 rok"
ExpiresByType image/png "dostęp plus 1 rok"
ExpiresByType text/css "dostęp plus 1 miesiąc"
ExpiresByType application/pdf "dostęp plus 1 miesiąc"
ExpiresByType text/javascript "dostęp plus 1 miesiąc"
ExpiresByType application/x-javascript "dostęp plus 1 miesiąc"
ExpiresDefault "dostęp plus 2 dni"Strategia pamięci podręcznej, wersjonowanie i ponowna walidacja
Łączę długie TTL z haszowaniem nazw plików, aby klienci buforowali je przez taki sam czas (style.9c2a.css), a aktualizacje wchodzą w życie natychmiast. Dla często zmienianych pakietów ustawiam Cache-Control: public, max-age=31536000, immutablepodczas gdy skrót HTML no-cache-strategie. Dla dynamicznych odpowiedzi preferuję Żądania warunkowe poprzez ETag lub Ostatnio zmodyfikowanytak, aby klienci dokonywali ponownej walidacji oszczędnie:
Header set Cache-Control "public, max-age=31536000, immutable"
Header set Cache-Control "no-cache, no-store, must-revalidate"W przypadku treści z wariantami formatów (np. WebP vs. JPEG) sprawdzam, czy Vary: Accept jest poprawnie ustawiona na Edge'u; zapobiega to umieszczaniu niewłaściwych wersji w pamięci podręcznej. Utrzymuję spójne wersjonowanie za pomocą potoków kompilacji, aby żaden zasób nie stał się przestarzały w niekontrolowany sposób.
Usprawnienie CSS i JavaScript
Minimalizuję CSS/JS lokalnie w moim procesie kompilacji i usuwam komentarze, spacje i nieużywane elementy. Selektory. Pakuję krytyczne style dla above-the-fold inline, resztę ładuję asynchronicznie lub jako plik odroczony. Skrypty blokujące renderowanie przenoszę na koniec, dodaję do nich defer/async i utrzymuję liczbę zewnętrznych bibliotek na niskim poziomie. W przypadku frameworków sprawdzam potrząsanie drzewem i zakresy importu, aby nie ładować wszystkiego, czego rzadko używam. Tam, gdzie to możliwe, łączę pliki w pakiety, aby zmniejszyć liczbę żądań bez buforowania zaplecza. pogorszyć się.
Poprawa INP: Odciążenie głównego wątku
Aby uzyskać niską interakcję z następną farbą, dzielę długie zadania na mniejsze fragmenty, unikam rozrzucania układów i oddzielam złożone programy obsługi od interakcji. Używam odroczenie dla modułów, ustaw pasywne detektory zdarzeń i zaplanuj niekrytyczną pracę w czasie bezczynności:
.
document.addEventListener('touchstart', onTouch, { passive: true });
const expensiveInit = () => { /* ... */ };
requestIdleCallback(expensiveInit, { timeout: 1500 });
// Dzielenie długich zadań
function chunkedWork(items) {
const batch = items.splice(0, 50);
// przetwarzanie...
if (items.length) requestAnimationFrame(() => chunkedWork(items));
}Mierzę długie zadania w DevTools, usuwam zduplikowane biblioteki i zastępuję narzędzia jQuery natywnymi API. Podsumowuję aktualizacje DOM, używam przekształcenie zamiast góra/lewo i ograniczyć ponowne przepływy do minimum.
Pozbądź się balastu WordPress
Nie potrzebuję wielu funkcji WP na produktywnych stronach, więc dezaktywuję emoji, oEmbeds i części REST API i oszczędzam pieniądze. Żądania. To zmniejsza głowę i mniej skryptów blokuje First Paint. Sprawdzam również pingbacki, linki RSD i manifest WLW i wyłączam je. Wyłączam również trackbacki i XML-RPC, jeśli nie odgrywają one żadnej roli. W ten sposób zmniejszam powierzchnię ataku i utrzymuję fazę startową światło.
// Wyłącz emoji
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
// redukcja oEmbeds i REST API
remove_action( 'wp_head', 'wp_oembed_add_host_js' );
add_filter('rest_enabled', '_return_false');
add_filter('rest_jsonp_enabled', '_return_false');Oswajanie skryptów innych firm
Kod firm trzecich jest często największym hamulcem. Inicjalizuję go z opóźnieniem, dołączam tylko to, co jest absolutnie konieczne i ładuję dopiero po interakcji lub uzyskaniu zgody. Analityka/śledzenie nadchodzi asynchroniczny Po pierwszym malowaniu zastępuję widżety społecznościowe statycznymi linkami. Dla iFrames używam loading="lazy" oraz piaskownicaaby ograniczyć efekty uboczne. Osadzenia YouTube otrzymują obraz podglądu i ładują odtwarzacz dopiero po kliknięciu - oszczędza to kilka żądań podczas uruchamiania.
Utrzymanie bazy danych bez pomocników
Usuwam zbędne rewizje, puste stany przejściowe i czyszczę komentarze spamowe za pośrednictwem phpMyAdmin, aby przyspieszyć zapytania. odpowiedź. Sprawdzam automatycznie ładowane opcje pod kątem nadmiernego rozmiaru, ponieważ trafiają one do każdego zapytania. W mniejszych instalacjach wystarczy kilka ukierunkowanych instrukcji SQL, aby zoptymalizować tabele. Sprawdzam, czy zadania cron nie są zawieszone i porządkuję postmety pozostawione przez stare wtyczki. Regularna konserwacja zapobiega wymykaniu się zapytań spod kontroli i zaśmiecaniu backendu. powolny wola.
System Cron zamiast WP Cron
Aby zapewnić niezawodne i wydajne działanie zadań cron, oddzielam je od ładowania strony. Dezaktywuję WP-Cron i planuję prawdziwe zadania systemowe, które działają w spokojnych godzinach.
// w wp-config.php
define('DISABLE_WP_CRON', true);# crontab -e (co 5 minut)
*/5 * * * * * /usr/bin/php -q /path/to/wp/wp-cron.php >/dev/null 2>&1Oznacza to, że żaden cron nie blokuje czasu odpowiedzi zwykłego żądania, a powtarzające się zadania, takie jak przejściowe czyszczenie lub generowanie map witryn, mogą być zaplanowane.
Krytyczne sprawdzenie motywu, wtyczek i czcionek
Usuwam nieaktywne motywy i wszystkie rozszerzenia, które powielają funkcje lub rzadko przynoszą jakiekolwiek korzyści, tak aby Autoloader ładuje mniej. W przypadku czcionek redukuję warianty do zwykłych/pogrubionych i dwóch stylów czcionek, hostuję je lokalnie i aktywuję wstępne ładowanie dla głównego pliku. Przygotowuję zewnętrzne zasoby z DNS prefetch, jeśli naprawdę ich potrzebuję. W przypadku embedów YouTube używam miniatur do późniejszej inicjalizacji iFrame. W ten sposób zachowuję kontrolę nad ścieżkami renderowania i utrzymuję początkowy ładunek mały.
Czcionki: zachowanie podczas ładowania, podzbiory, zwroty awaryjne
Czcionki internetowe silnie wpływają na postrzeganą szybkość. Używam font-display: swap lub opcjonalnydzięki czemu tekst jest natychmiast widoczny. Krytycznie sprawdzam zmienne czcionki i podzestawy obszarów Unicode, aby zaoszczędzić bajty. Ukierunkowane wstępne ładowanie najważniejszego pliku WOFF2 zmniejsza liczbę FOIT.
@font-face {
font-family: 'Brand';
src: url('/fonts/brand-regular.woff2') format('woff2');
font-weight: 400;
font-style: normal;
font-display: swap;
unicode-range: U+000-5FF; /* latin base set */
}Definiuję czyste systemowe czcionki rezerwowe (np. Segoe UI, Roboto, SF Pro, Arial) w stosie czcionek, aby zminimalizować skoki układu. O regulacja rozmiaru Dostosowuję różnice metryczne tak, aby zmiana z czcionki awaryjnej na czcionkę internetową była ledwo widoczna.
Serwer, PHP i protokoły
Bez odpowiedniej infrastruktury, każda optymalizacja zawiedzie, dlatego zwracam uwagę na szybkie dyski SSD, które są aktualne PHP-wersje i obsługa HTTP/2. OPcache, Brotli/Gzip i multipleksowanie HTTP/2 przyspieszają dostarczanie i zmniejszają blokady. Jeśli to możliwe, rozważam HTTP/3/QUIC i dokładnie sprawdzam konfigurację i konfigurację TLS; ten krótki artykuł na temat Wdrożenie protokołu HTTP/3. Testy obciążeniowe i obciążeniowe pokazują mi, jak strona reaguje pod obciążeniem. W ten sposób upewniam się, że mój stos obsługuje aplikację nośniki a moje środki są skuteczne.
| Dostawca hostingu | Cechy | Wydajność | Wsparcie | Stosunek ceny do wydajności |
|---|---|---|---|---|
| webhoster.de | SSD, PHP 8.*, HTTP/2 | ★★★★★ | ★★★★★ | ★★★★★ |
| Zawodnik 1 | SSD, PHP 7.*, HTTP/2 | ★★★★☆ | ★★★★☆ | ★★★★☆ |
| Zawodnik 2 | HDD, PHP 7.*, bez HTTP/2 | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
Optymalizacja PHP-FPM, OPcache i transportu
Ustawiłem PHP-FPM tak, aby żądania nie trafiały do kolejek. pm, pm.max_children oraz pm.max_requests Zmierzam do obciążenia. OPcache otrzymuje wystarczającą ilość pamięci, aby uniknąć rekompilacji.
php.ini / www.conf
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
PHP-FPM (przykładowe wartości)
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500W warstwie transportowej aktywuję Brotli przed Gzip, utrzymuję Keep-Alive otwarte i sprawdzam wznowienie TLS. W przypadku HTTP/2 sprawdzam priorytetyzację, aby CSS/czcionka i obraz LCP miały priorytet. W przypadku HTTP/3 monitoruję utratę pakietów i dostosowuję tempo.
CDN, buforowanie nagłówka i geografia
W przypadku ruchu międzynarodowego używam sieci brzegowej, aby zmniejszyć opóźnienia i utrzymać zasoby statyczne blisko użytkownika. dostarczyć. Zwracam uwagę na czyste klucze pamięci podręcznej, różne nagłówki (np. dla WebP) i spójne wersjonowanie. Ostrożnie cache'uję krytyczne strony HTML, selektywnie odpowiedzi API i agresywnie obrazy. Krótki przegląd Optymalizacja CDN pomaga mi uniknąć pułapek, takich jak podwójna kompresja. W ten sposób łączę buforowanie serwerowe i brzegowe i utrzymuję koszty na niskim poziomie. Widok.
Formaty, negocjacje i deduplikacja na brzegu sieci
Odtwarzam obrazy w nowoczesnych formatach (WebP, opcjonalnie AVIF) i upewniam się, że CDN przestrzega negocjacji treści. Ważne są poprawne Akceptuj-warianty i unikalność kluczy pamięci podręcznej. Unikam podwójnego Gzipa, kompresując tylko raz (serwer lub Edge) i dezaktywować flagę na drugim końcu. Dla HTML ustawiam konserwatywne TTL i silne ETagi, zasoby pozostają agresywnie buforowane.
Pomiar, kluczowe dane liczbowe i ustalanie priorytetów
Zaczynam od jasnego budżetu wydajności i skupiam się na LCP, CLS i INP zamiast na każdej wartości milisekundowej izolowany do rozważenia. Dane terenowe są powyżej wartości laboratoryjnych, więc porównuję rzeczywiste sygnały użytkowników z przebiegami testowymi. Diagramy wodospadowe ujawniają blokujące zasoby, mapy żądań pokazują zduplikowane biblioteki i niepotrzebne pliki czcionek. Mierzę każdą zmianę indywidualnie, aby szybko rozpoznać regresje. Dopiero gdy dane liczbowe konsekwentnie się poprawiają, wprowadzam je szerzej z.
Metoda pracy: czyste wdrożenie, szybkie wycofanie
Włączam kontrole wydajności do mojego procesu wdrażania: Kompilacje generują wersjonowane artefakty, testy Lighthouse/DevTools są uruchamiane na etapie przejściowym, a tylko sprawdzone pakiety są uruchamiane. Flagi funkcji pozwalają mi wdrażać ryzykowne zmiany w kontrolowany sposób i w razie potrzeby natychmiast je dezaktywować. Pozwala mi to utrzymać stabilną wydajność podczas opracowywania nowych funkcji.
Krótkie podsumowanie: Jak to wdrażam
W pierwszej kolejności optymalizuję treści o największym wpływie: zmniejszam rozmiar obrazu, aktywuję leniwe ładowanie, wbudowuję krytyczne części CSS i blokuję skrypty zmiana. Następnie zabezpieczam strategie buforowania po stronie przeglądarki i serwera, porządkuję funkcje WordPress i bazę danych oraz usuwam niepotrzebne wtyczki. Sprawdzam infrastrukturę, HTTP/2/3, Brotli i OPcache oraz zapewniam czyste procesy wdrażania z wersjonowaniem. W razie potrzeby dodaję CDN i reguluję nagłówki i warianty. Na koniec iteracyjnie sprawdzam kluczowe dane, aż LCP, CLS i INP będą stabilne i zielone. Obszary kłamstwo.
