Pāriet uz saturu 
Es optimizēju WordPress ātrumu bez spraudņiem ar manuālām iejaukšanās darbībām, kas redzami samazina iekraušanas laiku un droši sasniedz galvenos tīmekļa vitālos rādītājus. Tas ir veids, kā es saglabāju kontroli pār Pieprasījumiresursus un blakusparādības, kā arī novērst balastu tā rašanās vietā.
Centrālie punkti
- Attēli Pirms augšupielādes konsekventi saspiest un konvertēt uz WebP formātu
- Lēna ielāde izmantojot HTML atribūtu, nevis pārslogotus paplašinājumus.
- Kešatmiņa izmantojot .htaccess/server un tīru galvenes stratēģiju.
- Kods Rādīšanas bloķētāju minimizēšana, apvienošana un izvairīšanās no tiem
- Balasts noņemt WordPress, datubāzes un tēmas
Kāpēc es optimizēju bez spraudņiem
Spraudņi šķiet ērti, taču tie pievieno pieprasījumus, skriptus un stilus, kas bloķē sākotnējos atveidošanas ceļus un padara manu TTFB pasliktinās. Katra papildu atkarība palielina kļūdu virsmu un apgrūtina veiktspējas krituma cēloņu analīzi. Es izmantoju manuālus pasākumus, lai samazinātu slodzes ķēdes un līdz minimumam samazinātu aktīvo komponentu skaitu. Tas ļauj man samazināt pieskaitāmās izmaksas, saglabāt elastību un ātrāk reaģēt uz jaunām prasībām. Šāda pieeja novērš blakusparādības, ko izraisa atjauninājumu ķēdes, un uzturēšanu samazina līdz minimumam. slim.
Veidojiet attēlus plānus: Formāti, izmēri, saspiešana
Lieli attēli nenogalina laiku līdz pirmajam baitam, bet tie dominē pār pārsūtīšanas laiku un LCP, tāpēc es samazinu katru aktīvu. iepriekš. Es eksportēju fotoattēlus kā JPEG vai WebP un izmantoju PNG tikai īstām caurspīdīgām bildēm. Es mērogošu izmērus precīzi atbilstoši nepieciešamajam skatloga platumam, nevis ielādēju 4000px, ja pietiek ar 800px. Pēc tam konsekventi saspiežu ar Squoosh, ImageOptim vai Photoshop un pārbaudu, vai nav redzamu artefaktu. Reaģējošiem variantiem es izmantoju srcset/sizes un labprāt izmantoju šo īso saīsinājumu. Atsaucīgu attēlu ceļvedislai pārlūkprogramma automātiski ielādētu mazāko nozīmīgo avotu un manu Datu pārsūtīšana samazinās.
Izmanto slinko iekraušanu dabiski
Es ielādēju attēlus un iFrame tikai tad, kad tie nonāk skatīšanās laukumā, izmantojot HTML5, nevis integrēju papildu skriptus, kas nozīmē. Galvenais pavediens slodze. Mūsdienu pārlūkprogrammās pilnīgi pietiek ar atribūtu loading="lazy". Šādā veidā es samazinu sākotnējo baitu skaitu un izlīdzinu kritisko atveidošanas fāzi. Tajā pašā laikā vadība paliek caurspīdīga, un es izlemju, kurus virs reizes elementus apzināti ielādēšu eagerly. Kritiskie varoņu attēli tiek ielādēti loading="eager", viss pārējais tiek ielādēts. ofsets.
<img src="beispiel.jpg" alt="Attēla piemērs" loading="lazy">
<iframe src="video.html" title="Video" loading="lazy"></iframe>Mērķtiecīgi paātrināt LCP: Prioritātes un aizvietotāji
Lai uzlabotu lielākās satura krāsas stabilitāti, es skaidri atzīmēju savu lielāko virs reizes elementu. Attēliem tiek piešķirta fetchpriority="high" un noteikti izmēri, lai pārlūkprogramma tiem dotu priekšroku un CLS izvairās no. Ja nepieciešams, es pievienoju iepriekšēju ielādi, ja ceļš ir skaidrs.
<!-- 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="Varonis">Attēliem un konteineriem iestatu platumu/augstumu vai aspekta attiecībalai izslēgtu izkārtojuma lēcienus. Nekritiskām jomām es izmantoju satura redzamība: auto un contain-intrinsic-sizelai vēlāk pārlūkprogramma atveidotu apgabalus ārpus skata laukuma, nepārvietojot izkārtojumu.
/* Rezervēt virs reizes */
.hero { aspect-ratio: 12 / 7; }
/* Vēlāk izkārtojiet neredzamās sadaļas */
.section { content-visibility: auto; contain-intrinsic-size: 1000px; }
Īpaša pārlūkprogrammas kešatmiņas konfigurēšana
Atkārtotiem apmeklētājiem ir jāielādē statiskie aktīvi no kešatmiņas, tāpēc es iestatīju derīguma termiņus tieši servera līmenī, izmantojot .htaccess vai vHost. Garie TTL attēliem, vidēji garie CSS/JS un īsie noklusējuma iestatījumi HTML nodrošina man savlaicīguma un ātruma līdzsvaru. Es pievēršu uzmanību konsekventai failu versiju veidošanai, lai atjauninājumi stātos spēkā nekavējoties, neraugoties uz garajiem TTL. Kombinācijā ar ETags vai Last-Modified galvenēm ievērojami samazinās datplūsma. Tas man ietaupa joslas platumu un saīsina uztveramo datplūsmu. Uzlādes laiks.
ExpiresActive On
ExpiresByType image/jpg "piekļuve plus 1 gads"
ExpiresByType image/jpeg "piekļuve plus 1 gads"
ExpiresByType image/gif "piekļuve plus 1 gads"
ExpiresByType image/png "piekļuve plus 1 gads"
ExpiresByType text/css "piekļuve plus 1 mēnesis"
ExpiresByType application/pdf "piekļuve plus 1 mēnesis"
ExpiresByType text/javascript "piekļuve plus 1 mēnesis"
ExpiresByType application/x-javascript "piekļuve plus 1 mēnesis".
ExpiresDefault "piekļuve plus 2 dienas"Kešatmiņas stratēģija, versiju veidošana un atkārtota apstiprināšana
Es apvienoju garus TTL ar faila nosaukuma hashing, lai klienti kešētu tikpat ilgi (style.9c2a.css), un atjauninājumi stājas spēkā nekavējoties. Bieži maināmiem komplektiem es iestatīju Cache-Control: public, max-age=31536000, immutablebet HTML īss no-cache-stratēģijas. Dinamiskām atbildēm es dodu priekšroku Nosacījuma pieprasījumi par ETag vai Pēdējo reizi rediģētslai klienti retāk veiktu atkārtotu validāciju:
Header set Cache-Control "public, max-age=31536000, immutable"
Header set Cache-Control "no-cache, no-store, must-revalidate"Attiecībā uz saturu ar formāta variantiem (piemēram, WebP pret JPEG) pārbaudu, vai Dažādi: Pieņemt ir pareizi iestatīts Edge; tas novērš nepareizu versiju nonākšanu kešatmiņā. Es uzturu konsekventu versiju noteikšanu, izmantojot izveides cauruļvadus, lai neviens aktīvs nekļūtu novecojis nekontrolētā veidā.
CSS un JavaScript racionalizēšana
Savā izveides procesā es vietēji minificēju CSS/JS un nokopēju komentārus, atstarpes un neizmantotās Selektori. Es iepakoju kritiski svarīgos virs locījuma ievietotos stilus, pārējos ielādēju asinhroni vai kā atlikto failu. Es pārvietoju renderēšanu bloķējošos skriptus uz beigām, pievienoju tiem defer/async un saglabāju nelielu ārējo bibliotēku skaitu. Attiecībā uz karkasiem pārbaudu koka kratīšanu un importa darbības jomu, lai neievietoju visu, ko izmantoju reti. Ja iespējams, apvienoju failus, lai samazinātu pieprasījumu skaitu, neizveidojot kešatmiņu aizmugurē. pasliktinās.
Uzlabot INP: Atbrīvojiet galveno pavedienu
Lai iegūtu zemu mijiedarbības līdz nākamajai krāsai, es sadalīju garus uzdevumus mazākos gabaliņos, izvairījos no izkārtojuma pārklāšanās un atdalīju sarežģītus apstrādātājus no mijiedarbības. Es izmantoju atlikt moduļiem, iestatīt pasīvos notikumu klausītājus un plānot nekritisku darbu dīkstāves laikā:
document.addEventListener('touchstart', onTouch, { passive: true });
const expensiveInit = () => { /* ... */ };
requestIdleCallback(expensiveInit, { timeout: 1500 });
// Sadalīt garus uzdevumus
funkcija chunkedWork(items) {
const batch = items.splice(0, 50);
// apstrādāt...
if (items.length) requestAnimationFrame(() => chunkedWork(items));
}Es mēra garus uzdevumus DevTools, likvidēju dublējošās bibliotēkas un aizvietoju jQuery utilities ar vietējiem API. Es apkopoju DOM atjauninājumus, izmantoju pārveidot nevis augšā/kreisajā pusē un līdz minimumam samazināt atkārtotas plūsmas.
Atbrīvojieties no WordPress balasta
Man produktīvās vietnēs nav nepieciešamas daudzas WP funkcijas, tāpēc es deaktivizēju emodži, oEmbeds un REST API daļas un ietaupu naudu. Pieprasījumi. Tas sašaurina galvu un mazāk skriptu bloķē Pirmā glezna. Es arī pārbaudu pingbacks, RSD saites un WLW manifest un izslēdzu tos. Es arī izslēdzu atpakaļsaites un XML-RPC, ja tām nav nozīmes. Šādā veidā es samazinu uzbrukuma virsmu un saglabāju sākuma fāzi. gaismas.
// Deaktivizēt emodži
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
// samazināt oEmbeds un REST API
remove_action( 'wp_head', 'wp_oembed_add_host_js' );
add_filter('rest_enabled', '_return_false');
add_filter('rest_jsonp_enabled', '_return_false');Trešo pušu skriptu pieradināšana
Trešo pušu kodi bieži vien ir lielākais bremžu klucis. Es inicializēju to ar kavēšanos, iekļauju tikai to, kas ir absolūti nepieciešams, un ielādēju to tikai pēc mijiedarbības vai piekrišanas. Analītika/izsekošana tuvojas async pēc Pirmā krāsa, Es aizstāt sociālo widgets ar statiskām saitēm. iRāmjiem es izmantoju loading="lazy" un smilšu kastelai ierobežotu blakusparādības. YouTube iestrādnes saņem priekšskatījuma attēlu un ielādē atskaņotāju tikai pēc klikšķa - tas ietaupa vairākus pieprasījumus sākuma laikā.
Datubāzes uzturēšana bez palīgiem
Es dzēšu liekās pārskatīšanas, tukšos pārejas un attīru surogātpasta komentārus, izmantojot phpMyAdmin, lai padarītu ātrākus pieprasījumus. atbildēt. Es pārbaudu, vai automātiski ielādētās opcijas nav pārāk lielas, jo tās tiek iekļautas katrā vaicājumā. Mazākās instalācijās pietiek ar dažiem mērķtiecīgiem SQL izteikumiem, lai optimizētu tabulas. Es pārbaudu, vai cron uzdevumi ir pakārti, un sakārtoju postmetus, ko atstājuši vecie spraudņi. Regulāra uzturēšana novērš to, ka pieprasījumi kļūst nekontrolējami un mana backend daļa kļūst pārblīvēta. lēnīgs vēlēšanās.
Sistēmas Cron nevis WP Cron
Lai nodrošinātu, ka cron uzdevumi darbojas droši un efektīvi, es tos atdalīju no lapas ielādes. Es deaktivizēju WP-Cron un ieplānoju reālus sistēmas uzdevumus, kas darbojas klusajā laikā.
// wp-config.php
define('DISABLE_WP_CRON', true);# crontab -e (ik pēc 5 minūtēm)
*/5 * * * * * * * /usr/bin/php -q /path/to/wp/wp-cron.php >/dev/null 2>&1Tas nozīmē, ka neviens cron nebloķē regulāra pieprasījuma atbildes laiku un var ieplānot periodiskus uzdevumus, piemēram, īslaicīgu tīrīšanu vai vietnes kartes ģenerēšanu.
Kritiski pārbaudiet tēmu, spraudņus un fontus
Es noņemu neaktīvās tēmas un visus paplašinājumus, kas dublē funkcijas vai reti sniedz kādu labumu, lai. Automātiskā iekrāvēja slodze ir mazāka. Attiecībā uz fontiem es samazinu variantus līdz parastajam/biezajam un diviem fontu stiliem, izvietoju tos lokāli un aktivizēju priekšlādēšanu galvenajam failam. Ja man tie patiešām ir vajadzīgi, es sagatavoju ārējos resursus ar DNS priekšpiegādi. Attiecībā uz YouTube iestrādnēm es izmantoju sīktēlus, lai vēlāk inicializētu iFrame rāmi. Šādā veidā es saglabāju kontroli pār atveidošanas ceļiem un saglabāju sākuma slodzi. mazs.
Fonti: iekraušanas uzvedība, apakškomplektēšana, atkāpšanās iespējas
Tīmekļa fonti būtiski ietekmē uztveramo ātrumu. Es izmantoju font-display: swap vai izvēleslai teksts būtu uzreiz redzams. Es kritiski pārbaudu mainīgos fontus un apakškopju Unicode apgabalus, lai ietaupītu baitus. Mērķtiecīga svarīgākā WOFF2 faila iepriekšēja ielāde samazina FOIT.
@font-face {
font-family: 'Brand';
src: url('/fonts/brand-regular.woff2') format('woff2');
font-weight: 400;
font-style: normal;
font-display: swap;
vienkoda diapazons: U+000-5FF; /* latīņu valodas bāzes kopa */
}Lai līdz minimumam samazinātu izkārtojuma lēcienus, fontu kaudzītē definēju tīrus sistēmas rezerves variantus (piemēram, Segoe UI, Roboto, SF Pro, Arial). Par pielāgot izmēru Es pielāgoju metriskās atšķirības tā, lai maiņa no rezerves uz tīmekļa fontu būtu tik tikko pamanāma.
Serveris, PHP un protokoli
Bez pareizas infrastruktūras jebkura optimizācija būs neveiksmīga, tāpēc es pievēršu uzmanību ātrajiem SSD diskiem, atjauninātiem. PHP-versijas un HTTP/2 atbalsts. OPcache, Brotli/Gzip un HTTP/2 multipleksēšana paātrina piegādi un samazina bloķēšanu. Ja iespējams, es apsveru HTTP/3/QUIC un rūpīgi pārbaudu iestatījumus un TLS konfigurāciju; šis īsais raksts par Īstenot HTTP/3. Slodzes un stresa testi parāda, kā lapa reaģē uz slodzi. Šādi es nodrošinu, ka mans kaudze atbalsta lietojumprogrammu. nes un mani pasākumi ir efektīvi.
| Hostinga pakalpojumu sniedzējs | Funkcijas | Power | Atbalsts | Cenas un veiktspējas attiecība |
|---|---|---|---|---|
| webhoster.de | SSD, PHP 8.*, HTTP/2 | ★★★★★ | ★★★★★ | ★★★★★ |
| Konkurents 1 | SSD, PHP 7.*, HTTP/2 | ★★★★☆ | ★★★★☆ | ★★★★☆ |
| Konkurents 2 | HDD, PHP 7.*, nav HTTP/2 | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
PHP-FPM, OPcache un transporta optimizēšana
Es iestatīju PHP-FPM tā, lai pieprasījumi nenonāktu rindās. pm, pm.max_children un pm.max_requests Es dimensiju uz slodzi. OPcache saņem pietiekami daudz atmiņas, lai izvairītos no pārkompilēšanas.
php.ini / www.conf
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
PHP-FPM (vērtību piemēri)
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500Transporta slānī es aktivizēju Brotli pirms Gzip, turu atvērtu Keep-Alive un pārbaudu TLS atsākšanu. Izmantojot HTTP/2, pārbaudu prioritāšu piešķiršanu, lai CSS/fontam un LCP attēlam būtu prioritāte. Izmantojot HTTP/3, es uzraugu pakešu zudumus un koriģēju tempu.
CDN, kešēšanas galvene un ģeogrāfija
Starptautiskajai datplūsmai izmantoju galējo tīklu, lai samazinātu latentumu un saglabātu statiskos resursus lietotāja tuvumā. piegādāt. Es pievēršu uzmanību tīrām kešatmiņas atslēgām, variantu galvenēm (piemēram, WebP) un konsekventai versiju veidošanai. Es rūpīgi kešēju kritiskās HTML lapas, API atbildes izlases veidā un attēlus agresīvi. Īss pārskats par CDN optimizācija man palīdz izvairīties no tādām kļūdām kā dubulta saspiešana. Šādi es apvienoju servera un malas kešatmiņu un samazinu izmaksas. Skatīt.
Formāti, pārrunas un deduplikācija uz robežas
Es atskaņoju attēlus mūsdienīgos formātos (WebP, pēc izvēles AVIF) un nodrošinu, lai CDN ievērotu sarunas par saturu. Svarīgi ir pareizi Pieņemt-varianti un kešatmiņas atslēgu unikalitāte. Es izvairos no dubultās-Gzip saspiešanas, saspiežot tikai vienu reizi (servera vai Edge) un deaktivizē karodziņu otrā galā. HTML iestatīju konservatīvu TTL un spēcīgus ETag, aktīvi paliek agresīvi kešēti.
Mērījumi, galvenie skaitļi un prioritāšu noteikšana
Es sāku ar skaidru veiktspējas budžetu un koncentrējos uz LCP, CLS un INP, nevis uz katru milisekundes vērtību. Izolēts apsvērt. Lauka dati ir augstāki par laboratorijas vērtībām, tāpēc es salīdzinu reālo lietotāju signālus ar testa rezultātiem. Ūdensteču diagrammas atklāj bloķējošus līdzekļus, pieprasījumu kartes parāda dublējošās bibliotēkas un nevajadzīgus fontu failus. Es mēra katru izmaiņu atsevišķi, lai ātri atpazītu regresijas. Tikai tad, kad rādītāji konsekventi uzlabojas, es tos ieviešu plašāk. no.
Darba metode: tīra izvietošana, ātra atiestatīšana
Savā izvietošanas procesā es iekļauju veiktspējas pārbaudes: Veidošanas darbi ģenerē artefaktus ar versijām, Lighthouse/DevTools testi tiek palaisti sagatavošanas posmā, un tikai pārbaudīti komplekti tiek palaisti. Funkciju karodziņi ļauj man kontrolēti ieviest riskantas izmaiņas un nepieciešamības gadījumā tās nekavējoties deaktivizēt. Tas ļauj man saglabāt stabilu veiktspēju, kamēr izstrādāju jaunas funkcijas.
Īss kopsavilkums: Kā es to īstenoju
Vispirms optimizēju saturu ar vislielāko ietekmi: samazinu attēlu izmēru, aktivizēju slinku ielādi, ieliku kritiskās CSS daļas un bloķēju skriptus. maiņa. Pēc tam es nodrošinu kešēšanas stratēģijas pārlūkprogrammā un servera pusē, sakārtoju WordPress funkcijas un datu bāzi un noņemu nevajadzīgus spraudņus. Es pārbaudu infrastruktūru, HTTP/2/3, Brotli un OPcache un nodrošinu tīrus izvietošanas procesus ar versiju veidošanu. Ja nepieciešams, pievienoju CDN un regulēju galvenes un variantus. Visbeidzot, iteratīvi pārbaudu galvenos rādītājus, līdz LCP, CLS un INP ir stabili un zaļi. Jomas gulēt.
