Vai al contenuto 
Ottimizzo la velocità di wordpress senza plugin con interventi manuali che riducono visibilmente i tempi di caricamento e colpiscono in modo affidabile i parametri fondamentali del web. In questo modo mantengo il controllo su Richiesterisorse ed effetti collaterali ed eliminare la zavorra alla fonte.
Punti centrali
- immagini Comprimere in modo coerente prima del caricamento e convertire in formato WebP
- Caricamento pigro nativamente tramite attributi HTML invece di estensioni sovraccariche
- Caching tramite .htaccess/server e strategia di intestazione pulita
- Codice Ridurre al minimo, raggruppare ed evitare i blocchi di rendering
- Zavorra rimuovere in WordPress, database e temi
Perché ottimizzo senza plugin
I plugin sembrano convenienti, ma aggiungono richieste, script e stili che bloccano i percorsi di rendering iniziali e rendono il mio TTFB peggiorano. Ogni dipendenza aggiuntiva aumenta la superficie di errore e rende più difficile l'analisi delle cause dei cali di prestazioni. Uso misure manuali per ridurre le catene di carico e minimizzare il numero di componenti attivi. Questo mi permette di ridurre le spese generali, di rimanere flessibile e di reagire più rapidamente ai nuovi requisiti. Questo approccio evita gli effetti collaterali causati dalle catene di aggiornamento e riduce al minimo la manutenzione. sottile.
Rendere le immagini sottili: Formati, dimensioni, compressione
Le immagini di grandi dimensioni non uccidono il time-to-first-byte, ma dominano il tempo di trasferimento e l'LCP, per cui riduco ogni asset in anticipo. Esporto le foto come JPEG o WebP e uso PNG solo per le trasparenze reali. Ridimensiono le dimensioni esattamente alla larghezza della finestra di visualizzazione richiesta, invece di caricare 4000px quando 800px sono sufficienti. Poi comprimo in modo coerente con Squoosh, ImageOptim o Photoshop e controllo che non vi siano artefatti visibili. Per le varianti responsive, mi affido a srcset/sizes e mi piace usare questo breve Guida alle immagini reattivein modo che il browser carichi automaticamente il sorgente più piccolo e significativo e il mio Trasferimento dati diminuisce.
Utilizzare il caricamento pigro in modo nativo
Carico le immagini e gli iFrame solo quando entrano nella viewport, in modo nativo tramite HTML5, invece di integrare script aggiuntivi che significano Filo conduttore load. L'attributo loading="lazy" è del tutto sufficiente nei browser moderni. In questo modo, riduco il numero di byte iniziali e pareggio la fase critica del rendering. Allo stesso tempo, il controllo rimane trasparente e sono io a decidere quali elementi above-the-fold caricare deliberatamente eager. Le immagini critiche dell'eroe hanno loading="eager", tutto il resto viene caricato offset.
<img src="beispiel.jpg" alt="Immagine di esempio" loading="lazy">
<iframe src="video.html" title="Video" loading="lazy"></iframe>Accelerare l'LCP in modo mirato: Priorità e segnaposto
Per migliorare la stabilità del Largest Contentful Paint, contrassegno esplicitamente il mio elemento più grande above-the-fold. Alle immagini viene assegnato fetchpriority="high" e dimensioni definite, in modo che il browser le preferisca e CLS evita. Se necessario, aggiungo un precarico se il percorso è chiaro.
<!-- 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="Eroe">Per le immagini e i contenitori, imposto larghezza/altezza o rapporto d'aspettoper escludere i salti di layout. Per le aree non critiche uso visibilità del contenuto: auto e contenere dimensioni intrinsechein modo che il browser esegua il rendering delle aree al di fuori della finestra di visualizzazione senza spostare il layout.
/* Riserva above-the-fold */
.hero { aspect-ratio: 12 / 7; }
/* Impaginare le sezioni non visibili in un secondo momento */
.section { content-visibility: auto; contain-intrinsic-size: 1000px; }
Configurare in modo specifico la cache del browser
I visitatori ricorrenti dovrebbero caricare le risorse statiche dalla cache, quindi ho impostato i tempi di scadenza direttamente a livello del server tramite .htaccess o nel vHost. I TTL lunghi per le immagini, moderati per CSS/JS e brevi per l'HTML mi permettono di trovare un equilibrio tra tempestività e velocità. Presto attenzione a una versione coerente dei file, in modo che gli aggiornamenti abbiano effetto immediato nonostante i TTL lunghi. In combinazione con gli ETag o le intestazioni Last-Modified, il traffico si riduce drasticamente. Questo mi fa risparmiare larghezza di banda e accorcia il tempo di percezione del TTL. Tempo di caricamento.
ScadenzaAttiva On
ExpiresByType image/jpg "accesso più 1 anno".
ExpiresByType image/jpeg "accesso più 1 anno"
ExpiresByType image/gif "accesso più 1 anno
ExpiresByType image/png "accesso più 1 anno
ExpiresByType text/css "accesso più 1 mese
ExpiresByType application/pdf "accesso più 1 mese"
ExpiresByType text/javascript "accesso più 1 mese
ExpiresByType application/x-javascript "accesso più 1 mese"
ExpiresDefault "accesso più 2 giorni".Strategia di cache, versioning e riconvalida
Combino i TTL lunghi con l'hashing dei nomi dei file, in modo che i client abbiano una cache per lo stesso periodo di tempo (style.9c2a.css) e gli aggiornamenti hanno effetto immediato. Per i bundle modificati di frequente, ho impostato Cache-Control: pubblico, max-age=31536000, immutabilementre l'HTML breve no-cache-strategie. Per le risposte dinamiche preferisco Richieste condizionate tramite ETag oppure Ultima modificain modo che i clienti rivalutino con parsimonia:
.
Set di intestazioni Cache-Control "public, max-age=31536000, immutable".
Header set Cache-Control "no-cache, no-store, must-revalidate".Per i contenuti con varianti di formato (ad es. WebP vs. JPEG), verifico che Vario: Accetta sia impostato correttamente su Edge; questo impedisce che le versioni sbagliate finiscano nella cache. Mantengo il versioning coerente tramite le pipeline di compilazione, in modo che nessuna risorsa diventi obsoleta in modo incontrollato.
Semplificare CSS e JavaScript
Minimizzo i CSS/JS localmente nel mio processo di compilazione e rimuovo commenti, spazi e non utilizzati. Selezionatori. Impacchetto gli stili critici per la parte superiore della pagina in linea, il resto lo carico in modo asincrono o come file differito. Sposto gli script che bloccano il rendering alla fine, aggiungo defer/async e mantengo il numero di librerie esterne ridotto. Per i framework, controllo gli scuotimenti dell'albero e gli ambiti di importazione, in modo da non caricare tutto ciò che si usa raramente. Ove possibile, raggruppo i file per ridurre le richieste senza memorizzare nella cache il back-end. deteriorarsi.
Migliorare l'INP: Alleggerire il thread principale
Per una verniciatura a basso livello di interazione, suddivido i compiti più lunghi in parti più piccole, evito la manipolazione del layout e disaccoppio i gestori complessi dalle interazioni. Uso rinviare per i moduli, impostare ascoltatori di eventi passivi e programmare il lavoro non critico nei tempi morti:
document.addEventListener('touchstart', onTouch, { passive: true });
const expensiveInit = () => { /* ... */ };
requestIdleCallback(expensiveInit, { timeout: 1500 });
// Dividere compiti lunghi
function chunkedWork(items) {
const batch = items.splice(0, 50);
// elabora...
if (items.length) requestAnimationFrame(() => chunkedWork(items));
}Misuro i compiti più lunghi in DevTools, rimuovo le librerie duplicate e sostituisco le utility jQuery con API native. Riassumo gli aggiornamenti del DOM, uso trasformare invece di in alto a sinistra e ridurre al minimo i riflussi.
Sbarazzarsi della zavorra WordPress
Non ho bisogno di molte funzioni di WP sui siti produttivi, quindi disattivo emoji, oEmbed e parti dell'API REST e risparmio. Richieste. In questo modo la testata si restringe e un minor numero di script blocca First Paint. Controllo anche i pingback, i link RSD e il manifesto WLW e li disattivo. Disattivo anche i trackback e XML-RPC se non svolgono un ruolo importante. In questo modo, riduco la superficie di attacco e mantengo la fase iniziale luce.
// Disattivare le emoji
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
// ridurre gli oEmbed e l'API REST
remove_action( 'wp_head', 'wp_oembed_add_host_js' );
add_filter('rest_enabled', '_return_false');
add_filter('rest_jsonp_enabled', '_return_false');Addomesticare gli script di terze parti
Il codice di terze parti è spesso il freno più grande. Lo inizializzo con un certo ritardo, includo solo lo stretto necessario e lo carico solo dopo l'interazione o il consenso. L'analisi/tracciamento è in arrivo asincrono dopo il First Paint, sostituisco i widget sociali con link statici. Per gli iFrame uso loading="pigro" e sandboxper limitare gli effetti collaterali. Gli embed di YouTube ricevono un'immagine di anteprima e caricano il player solo quando viene cliccato: ciò consente di risparmiare diverse richieste all'avvio.
Manutenzione del database senza aiutanti
Elimino le revisioni superflue, svuoto i transitori e pulisco i commenti di spam tramite phpMyAdmin per rendere le query più veloci. risposta. Controllo che le opzioni autocaricate non siano di dimensioni eccessive, perché finiscono in ogni query. Nelle installazioni più piccole, sono sufficienti alcune istruzioni SQL mirate per ottimizzare le tabelle. Controllo se i cron job sono sospesi e riordino i postmeta lasciati da vecchi plugin. Una manutenzione regolare evita che le query sfuggano di mano e che il mio backend diventi ingombro. fiacco volontà.
Cron di sistema invece di Cron di WP
Per garantire che i lavori di cron vengano eseguiti in modo affidabile ed efficiente, li disaccoppio dal caricamento della pagina. Disattivo WP-Cron e pianifico veri lavori di sistema che funzionano nei momenti di calma.
// in wp-config.php
define('DISABLE_WP_CRON', true);# crontab -e (ogni 5 minuti)
*/5 * * * * * /usr/bin/php -q /path/to/wp/wp-cron.php >/dev/null 2>&1Ciò significa che nessun cron blocca il tempo di risposta di una richiesta regolare e che è possibile programmare attività ricorrenti come la pulizia transitoria o la generazione di sitemap.
Controllare in modo critico il tema, i plugin e i font
Rimuovo i temi inattivi e tutte le estensioni che duplicano le funzioni o che raramente apportano benefici, in modo che il sito Caricatore automatico carica meno. Per i font, riduco le varianti a regular/bold e a due stili di font, li ospito localmente e attivo il precaricamento per il file principale. Preparo le risorse esterne con il prefetch DNS se ne ho davvero bisogno. Per gli embed di YouTube, uso le miniature per inizializzare successivamente gli iFrame. In questo modo mantengo il controllo sui percorsi di rendering e conservo il payload iniziale. piccolo.
Caratteri: comportamento di caricamento, sottoinsiemi, fallback
I font web influenzano fortemente la velocità percepita. Io uso visualizzazione dei caratteri: swap oppure opzionalein modo che il testo sia immediatamente visibile. Controllo in modo critico i font variabili e sottoinsieme delle aree Unicode per risparmiare byte. Un precaricamento mirato del file WOFF2 più importante riduce il 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; /* set di base latina */
}Definisco fallback di sistema puliti (ad esempio Segoe UI, Roboto, SF Pro, Arial) nello stack di caratteri per ridurre al minimo i salti di layout. Circa Regolazione della taglia Regolo le differenze metriche in modo che il passaggio dal font di fallback a quello web sia appena visibile.
Server, PHP e protocolli
Senza la giusta infrastruttura, qualsiasi ottimizzazione fallirà, per questo motivo presto attenzione alle unità SSD veloci e aggiornate. PHP-e il supporto di HTTP/2. OPcache, Brotli/Gzip e il multiplexing HTTP/2 accelerano la consegna e riducono i blocchi. Se possibile, prendo in considerazione HTTP/3/QUIC e verifico attentamente la configurazione e il TLS; questo breve articolo su Implementare HTTP/3. I test di carico e di stress mi mostrano come reagisce la pagina sotto carico. In questo modo mi assicuro che il mio stack supporti l'applicazione. porta e le mie misure sono efficaci.
| Provider di hosting | Caratteristiche | Prestazioni | Supporto | Rapporto prezzo-prestazioni |
|---|---|---|---|---|
| webhoster.de | SSD, PHP 8.*, HTTP/2 | ★★★★★ | ★★★★★ | ★★★★★ |
| Concorrente 1 | SSD, PHP 7.*, HTTP/2 | ★★★★☆ | ★★★★☆ | ★★★★☆ |
| Concorrente 2 | HDD, PHP 7.*, no HTTP/2 | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
Ottimizzare PHP-FPM, OPcache e il trasporto
Ho impostato PHP-FPM in modo che le richieste non finiscano in coda. pm, pm.max_children e pm.max_requests Dimensiono il carico. OPcache ottiene abbastanza memoria per evitare ricompilazioni.
php.ini / www.conf
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
PHP-FPM (valori di esempio)
pm = dinamico
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500A livello di trasporto, attivo Brotli prima di Gzip, mantengo Keep-Alive aperto e controllo la ripresa di TLS. Con HTTP/2, controllo la priorità in modo che CSS/font e l'immagine LCP abbiano la priorità. Con HTTP/3, monitoro la perdita di pacchetti e regolo il ritmo.
CDN, header di caching e geografia
Per il traffico internazionale, utilizzo una rete edge per ridurre la latenza e mantenere le risorse statiche vicino all'utente. consegnare. Presto attenzione alle chiavi di cache pulite, alle intestazioni variabili (ad esempio per WebP) e al versioning coerente. Metto in cache le pagine HTML critiche con attenzione, le risposte API in modo selettivo e le immagini in modo aggressivo. Una breve panoramica della Ottimizzazione CDN mi aiuta a evitare insidie come la doppia compressione. In questo modo combino la cache del server e del bordo e mantengo i costi bassi. Vista.
Formati, negoziazione e deduplicazione ai margini
Riproduco le immagini in formati moderni (WebP, AVIF opzionale) e mi assicuro che il CDN rispetti la negoziazione dei contenuti. Importante è la correttezza Accettare-e l'unicità delle chiavi della cache. Evito il doppio Gzip comprimendo una sola volta (server oppure Edge) e disattivare il flag all'altra estremità. Per l'HTML ho impostato TTL conservativi e ETag forti, le risorse rimangono nella cache in modo aggressivo.
Misurazione, cifre chiave e priorità
Inizio con un chiaro budget di prestazioni e mi concentro su LCP, CLS e INP invece che su ogni valore al millisecondo. isolato da considerare. I dati sul campo sono superiori ai valori di laboratorio, quindi confronto i segnali degli utenti reali con quelli dei test. I diagrammi a cascata rivelano le risorse bloccanti, le mappe delle richieste mostrano librerie duplicate e file di font non necessari. Misuro ogni cambiamento singolarmente per riconoscere rapidamente le regressioni. Solo quando i dati migliorano in modo consistente, li diffondo in modo più ampio. da.
Metodo di lavoro: distribuzione pulita, rollback rapido
Incorporo i controlli delle prestazioni nel mio processo di deploy: Le build generano artefatti versionati, i test di Lighthouse/DevTools vengono eseguiti in fase di staging e solo i bundle controllati vengono pubblicati. I flag delle funzionalità mi consentono di introdurre modifiche rischiose in modo controllato e di disattivarle immediatamente, se necessario. Questo mi permette di mantenere stabili le prestazioni mentre sviluppo nuove funzioni.
Brevemente riassunto: Come lo realizzo
Ottimizzo innanzitutto i contenuti con la maggiore leva: riduco le dimensioni delle immagini, attivo il caricamento pigro, metto in linea le parti critiche del CSS e blocco gli script. turno. Assicuro quindi le strategie di caching sul lato del browser e del server, riordino le funzioni di WordPress e il database e rimuovo i plugin non necessari. Controllo l'infrastruttura, HTTP/2/3, Brotli e OPcache e garantisco processi di distribuzione puliti con il versioning. Se necessario, aggiungo un CDN e regolo intestazioni e varianti. Infine, controllo iterativamente le cifre chiave finché LCP, CLS e INP sono stabili e verdi. Aree bugia.
