Sito web lento: trovare sistematicamente le cause

Un sito web lento può avere molte cause. Grandi immagini, JavaScript complesso, query di database lente, servizi esterni, mancanza di caching o un'elaborazione lato server ritardata possono manifestarsi in modo simile.

Ecco perché raramente ha senso modificare le impostazioni a caso o installare vari plugin di ottimizzazione senza una diagnosi.

La via migliore è una ricerca sistematica degli errori: per prima cosa si determina, dove si verifica il ritardo. Successivamente viene circoscritta la causa tecnica e solo allora viene apportata una modifica mirata.

In questa guida ti mostriamo come procedere passo dopo passo in caso di un sito Web lento e come distinguere le cause tipiche.

Breve spiegazione: „Il sito web è lento“ è inizialmente solo un sintomo. Per un'ottimizzazione efficace devi scoprire se il ritardo si verifica sul server, nel browser, nelle singole risorse, nell'applicazione o in un servizio esterno.

Che cosa significa esattamente „sito web lento“? #

I visitatori possono percepire la velocità in modi diversi.

Ad esempio, una pagina può rimanere a lungo bianca prima che appaia qualcosa. In un altro sito, il contenuto diventa rapidamente visibile, ma un'immagine grande appare solo molto più tardi. Un'altra pagina ancora si carica visivamente in modo rapido, ma risponde con ritardo ai click.

Queste situazioni possono avere cause tecniche completamente diverse.

Caso A
→ Il server risponde tardi

Caso B
→ Il contenuto principale appare tardi

Caso C
→ Grandi risorse si caricano lentamente

Caso D
→ La pagina risponde lentamente alle interazioni

Caso E
→ Una funzione esterna è ritardata

Caso F
→ Il problema si verifica solo occasionalmente

Prima di ottimizzare, dovresti quindi essere in grado di descrivere il più precisamente possibile, ciò che è davvero lento.

Prima misurare, poi ottimizzare #

Il primo passo è una misurazione iniziale riproducibile.

Se lavori solo a sensazione, difficilmente in seguito potrai giudicare se un cambiamento ha davvero aiutato.

Testa quindi un URL specifico più volte e documenta i risultati principali.

Spiegheremo come eseguire utilmente tali misurazioni su Misurare e valutare correttamente il tempo di caricamento del sito web.

Consiglio pratico: Prima di una modifica, annota almeno l'URL testato, il tipo di dispositivo, lo strumento di misurazione utilizzato e i valori di misura anomali. Dopodiché potrai ripetere lo stesso test.

Non testare solo la pagina iniziale #

Una homepage veloce non significa automaticamente che l'intero sito web sia veloce.

Testa quindi la pagina in cui si verifica effettivamente il problema.

In un negozio online, ad esempio, la pagina del prodotto, il carrello e il checkout possono funzionare in modo tecnicamente molto diverso.

Pagina iniziale veloce
Pagina del prodotto lenta

→ Il problema probabilmente non è generale
  su tutto il sito web

Questo è già un indizio prezioso per la diagnosi successiva.

È lento l'intero sito web o solo una pagina? #

Apri più pagine diverse dello stesso sito web.

Se tutte le pagine sono ugualmente lente, sono probabili cause generali. Se invece è interessata solo una determinata URL o un determinato tipo di pagina, dovresti prima esaminarne le specificità.

Esempi:

tutte le pagine lente
→ elaborazione lato server?
→ script globali?
→ tema?
→ servizi esterni?
→ configurazione generale?

solo le pagine dei prodotti lente
→ funzioni del negozio?
→ immagini dei prodotti?
→ varianti?
→ query del database?
→ script aggiuntivi?

solo una singola pagina lenta
→ contenuto specifico?
→ video incorporato?
→ slider?
→ API esterna?
→ risorse insolitamente grandi?

Il sito web è sempre lento o solo a volte? #

Anche l'andamento temporale è importante.

Un sito web costantemente lento potrebbe avere una causa diversa rispetto a una pagina che è normalmente veloce e reagisce molto lentamente solo occasionalmente.

Nel caso di problemi sporadici, ad esempio, possono entrare in gioco servizi esterni, processi in background, picchi di carico o problemi di rete temporanei.

Esegui quindi diverse misurazioni in momenti diversi se il problema non si presenta costantemente.

Distinguere tra frontend e backend #

Per la risoluzione dei problemi è utile una netta distinzione tra elaborazione lato server ed elaborazione lato browser.

BACKEND / SERVER

Richiesta
   ↓
Server web
   ↓
PHP / Applicazione
   ↓
Database
   ↓
Risposta HTML


FRONTEND / BROWSER

HTML
   ↓
CSS
   ↓
JavaScript
   ↓
Font
   ↓
Immagini
   ↓
Visualizzazione e interazione

Un sito web può essere generato rapidamente sul lato server e sembrare comunque lento nel browser.

Viceversa, un frontend molto leggero può attendere una risposta lato server che richiede molto tempo.

TTFB come primo indizio #

Il Time to First Byte, abbreviato in TTFB, può fornire un primo indizio su quanto tempo ci vuole per l'arrivo del primo byte della risposta.

Tuttavia, un TTFB elevato non significa automaticamente che solo il server web sia lento.

Il valore può essere influenzato, tra le altre cose, dalla rete, dalla connessione, dall'elaborazione lato server e da altri fattori.

Trattiamo il significato di tali misurazioni in modo più dettagliato alla voce Misurare e valutare correttamente il tempo di caricamento del sito web.

Se anche la risposta HTML richiede molto tempo #

Se il browser attende a lungo la risposta del documento vero e proprio, dovresti prima esaminare l'area lato server o lato applicazione.

Le possibili cause possono essere:

• complessa elaborazione PHP,
• interrogazioni del database lente,
• richieste API esterne,
• caching mancante o non efficace,
• estensioni difettose,
• processi di background a intensivo consumo di risorse.

Solo quando è chiaro quale settore richiede effettivamente tempo, si può continuare a lavorare in modo sensato.

Un TTFB elevato non significa automaticamente un cattivo hosting #

La causa di una lenta risposta lato server può risiedere all'interno dell'applicazione del sito web.

Un plugin WordPress può, ad esempio, eseguire complesse operazioni di database ad ogni caricamento di pagina o attendere un servizio esterno.

Una maggiore potenza del server può attenuare in determinate circostanze un comportamento inefficiente, ma non ne elimina automaticamente la causa.

Importante: Non valutare le prestazioni dell'hosting basandoti su un singolo valore TTFB. Per prima cosa bisogna chiarire quale parte della richiesta sta causando il ritardo.

Esaminare PHP e l'applicazione #

I siti web dinamici generano spesso contenuti con PHP o un'applicazione lato server comparabile.

In WordPress sono coinvolti, ad esempio, WordPress stesso, il tema, i plugin e il database.

Un lento trattamento in PHP può avere diverse cause:

codice di plugin complesso
troppe query o query inefficienti al database
richieste HTTP esterne
grandi quantità di dati
processi difettosi
configurazione inadeguata
software obsoleto
funzionalità avide di risorse

Il solo numero di plugin installati non è una misura affidabile della qualità.

Molti plugin non significano automaticamente un sito web lento #

L'affermazione „troppi plugin rallentano WordPress“ è troppo generica.

Un singolo plugin mal programmato o molto pesante per il rispettivo compito può causare più problemi di prestazioni rispetto a diverse estensioni leggere.

Perciò non è decisivo solo:

Quanti plugin sono installati?

Bensì:

Cosa fanno questi plugin durante il caricamento di una pagina?

Non disattivare i plugin in modo casuale sul sito live #

Se si sospetta che un plugin sia la causa, il controllo dovrebbe essere eseguito in modo controllato.

La disattivazione indiscriminata di estensioni su un sito web di produzione può compromettere funzionalità o rendere inutilizzabile un negozio online.

Per test più estesi, un ambiente di staging o di prova è quindi spesso la scelta migliore.

Attenzione: Crea un backup aggiornato prima di effettuare modifiche importanti. Nel caso di negozi online, aree membri o altri siti web dinamici, bisogna inoltre tenere conto del fatto che tra il backup e il ripristino potrebbero essere generati nuovi dati.

Database come possibile causa #

Molti siti web dinamici accedono a un database a ogni caricamento di pagina.

Ad esempio, interrogazioni molto complesse, grandi quantità di dati o estensioni sfavorevoli possono essere problematiche.

In WordPress possono essere attivate interrogazioni al database, tra l'altro, da plugin, temi o funzioni personalizzate.

Un problema di database dovrebbe tuttavia essere diagnosticato e non solo ipotizzato a causa delle dimensioni del database.

Un grande database non è automaticamente lento #

Da sola, la dimensione o quantità di dati di un database dice ben poco sulle reali prestazioni delle query.

Tra l'altro, è fondamentale quali dati vengono richiesti e quanto ciò avvenga in modo efficiente.

Ecco perché:

Database grande → database lento

nessuna conclusione affidabile.

Chiamate API esterne sul server #

Un sito web può contattare altri sistemi durante l'elaborazione lato server.

Gli esempi sono:

Servizi di pagamento
API esterne
Server di licenze
Sistemi CRM
Servizi di spedizione
Fonti di dati esterne

Se una tale richiesta deve essere attesa in modo sincrono e il servizio esterno risponde lentamente, ciò può ritardare anche la risposta del tuo sito web.

Il problema non deve quindi risiedere sul proprio server web.

Verifica la cache #

Il caching può ridurre notevolmente il lavoro lato server se è possibile riutilizzare contenuti o risultati già generati.

Quali tipi di cache siano utili dipende dal rispettivo sito web e applicazione.

In modo semplificato, possono essere coinvolti diversi livelli:

Cache del browser
Cache di pagina
Cache degli oggetti
Cache degli opcode
CDN / Edge Cache

Questi sistemi svolgono compiti diversi e non dovrebbero essere considerati semplicemente come un unico „cache“.

La cache non è adatta a qualsiasi tipo di contenuto #

Una pagina di contenuti statici pubblici può essere trattata diversamente rispetto a un'area clienti personalizzata o a un carrello.

Nei casi di intervalli dinamici, occorre pertanto definire con precisione quali contenuti possano essere memorizzati nella cache.

Un cache aggressivo può migliorare le prestazioni, ma se configurato in modo errato può anche fornire contenuti obsoleti o destinati all'utente sbagliato.

Svuotare la cache non è un'ottimizzazione permanente #

„Svuota la cache“ viene spesso consigliato come soluzione universale ai problemi.

Svuotare una cache può essere utile in caso di contenuti della cache obsoleti o errati. Tuttavia, non risolve automaticamente la causa di un sito web lento.

Dopo lo svuotamento, inoltre, determinati contenuti della cache devono essere prima ricostruiti.

Se il server risponde rapidamente ma la pagina sembra comunque lenta #

Allora dovresti esaminare più da vicino la parte lato browser.

I candidati tipici sono:

immagini grandi
troppi dati trasferiti
JavaScript
CSS
Webfont
video
servizi esterni
widget di terze parti
priorità di caricamento sfavorevoli

Google PageSpeed Insights può aiutare a identificare tali problemi. Spieghiamo il funzionamento e l'interpretazione su Usare correttamente Google PageSpeed Insights.

Immagini come causa di problemi di performance #

Le immagini sono spesso tra le risorse più pesanti trasferite da molti siti web.

Un errore tipico è, ad esempio, caricare una foto larga diverse migliaia di pixel, nonostante sul sito web venga visualizzata in dimensioni notevolmente inferiori.

Anche una compressione inadeguata o un formato di file non adatto possono causare file inutilmente grandi.

Spiegheremo come preparare opportunamente le immagini su Ottimizzare le immagini per il web: dimensione del file, formato e SEO.

Differenziazione tra dimensioni in pixel e dimensione del file #

Un'immagine possiede sia dimensioni che una dimensione del file.

Esempio:

Dimensioni:
4000 × 2667 pixel

Dimensione del file:
5,8 MB

Entrambe le proprietà possono essere rilevanti per le performance.

Utilizzare solo un formato di file moderno, senza ridurre le dimensioni eccessivamente grandi, non è quindi sempre sufficiente.

Utilizzare il formato di immagine corretto #

WebP e AVIF possono consentire una compressione notevolmente più efficiente rispetto ai formati più vecchi per le immagini adatte.

PNG rimane invece utile, ad esempio, quando sono necessarie determinate proprietà come la rappresentazione grafica senza perdita di dati o la trasparenza.

Spieghiamo quale formato è utile per quale scopo su WebP, AVIF, JPG e PNG: quale formato di immagine usare?.

Utilizzare correttamente il Lazy Loading #

Il lazy loading può impedire che le immagini molto al di fuori dell'area visibile vengano caricate immediatamente.

Ciò potrebbe eventualmente ridurre il trasferimento di dati non necessario al primo caricamento della pagina.

Nel caso di un'immagine importante nell'area immediatamente visibile, un lazy loading inadeguato può invece ritardare il momento in cui tale immagine viene visualizzata.

In particolare, nel caso di un'immagine LCP, si dovrebbe quindi verificare se il suo comportamento di caricamento sia configurato in modo sensato.

Puoi trovare maggiori informazioni su Core Web Vitals spiegati: LCP, INP e CLS.

JavaScript come possibile causa #

JavaScript consente funzioni interattive e dinamiche, ma deve essere caricato, elaborato ed eseguito dal browser.

Ad esempio, codice molto voluminoso o un lavoro prolungato sul thread principale possono essere problematici.

Possibili fonti sono:

Tema
Plugin
Page Builder
Tracciamento
Animazioni
Slider
Chat
Widget esterni
Script di marketing

La soluzione corretta non è rimuovere completamente JavaScript in automatico. Per prima cosa bisogna chiarire quale codice sia effettivamente rilevante.

Interpretare correttamente il JavaScript inutilizzato #

Gli strumenti di performance possono segnalare che parti di un file JavaScript non sono state utilizzate durante il caricamento della pagina esaminato.

Ciò non significa automaticamente che l'intero file possa essere eliminato.

Ad esempio, uno script potrebbe essere necessario solo dopo un'interazione dell'utente o su un'altra pagina secondaria.

Tali indicazioni sono punti di partenza per un'analisi, non istruzioni di cancellazione automatica.

Ritardare JavaScript: attenzione alle ottimizzazioni automatiche #

Alcune soluzioni di performance possono caricare o eseguire JavaScript in ritardo.

Questo può aiutare nei casi appropriati, ma può anche compromettere funzioni importanti.

Dopo tali modifiche, dovresti quindi testare in particolare:

Navigazione
Moduli
Banner dei cookie
Slider
Ricerca
Accesso
Carrello
Checkout
Funzioni di pagamento
Menu mobili

Il CSS può ritardare il rendering #

I CSS determinano la presentazione visiva di un sito web.

Alcuni fogli di stile potrebbero essere necessari per il rendering prima che il browser possa visualizzare correttamente la pagina.

Gli strumenti di performance possono quindi segnalare risorse CSS che bloccano il rendering.

Auch hier gilt: Eine angezeigte Datei darf nicht einfach entfernt werden. Ohne benötigtes CSS kann die Website falsch oder zunächst unformatiert dargestellt werden.

Ungenutztes CSS bedeutet nicht automatisch unnötige Datei #

Ein globales Stylesheet kann Regeln für zahlreiche Seitentypen enthalten.

Auf einer einzelnen getesteten URL werden möglicherweise nur einige davon benötigt.

Das Analysewerkzeug kann deshalb ungenutztes CSS melden, obwohl die entsprechenden Regeln auf anderen Seiten gebraucht werden.

Eine Optimierung sollte daher immer im Kontext der gesamten Website erfolgen.

Webfonts untersuchen #

Webfonts können zusätzliche Netzwerk-Anfragen und Rendering-Effekte verursachen.

Eine Website benötigt häufig nicht jede denkbare Schriftstärke und jeden Schriftschnitt.

Wenn beispielsweise zahlreiche Font-Dateien geladen werden, obwohl tatsächlich nur wenige Varianten verwendet werden, entsteht unnötiger Aufwand.

Prüfe deshalb, welche Schriftarten und Schriftschnitte wirklich benötigt werden.

Externe Schriftarten #

Werden Fonts von einem externen Anbieter geladen, kommt eine zusätzliche externe Verbindung hinzu.

Lokal bereitgestellte Schriftarten können in bestimmten Konfigurationen Vorteile bieten, müssen aber ebenfalls korrekt eingebunden und optimiert werden.

Die Entscheidung sollte nicht ausschließlich anhand der Anzahl der Requests getroffen werden.

Videos können erhebliche Datenmengen verursachen #

Direkt eingebundene oder automatisch startende Videos können große Datenmengen verursachen.

Auch eingebettete Videoplattformen können zusätzliche Scripts, Frames und externe Verbindungen laden.

Wenn Videos eine Seite ausbremsen, sollte geprüft werden, ob sie bereits beim ersten Seitenaufruf vollständig benötigt werden oder ob eine leichtere Vorschaulösung möglich ist.

Drittanbieter-Dienste untersuchen #

Viele moderne Websites laden Ressourcen von anderen Anbietern.

A ciò appartengono, ad esempio:

Analytics
Tag-Manager
Social-Media-Feeds
Maps
Videos
Chat-Systeme
Bewertungsdienste
Werbesysteme
Marketing-Tools

Diese Ressourcen liegen teilweise außerhalb deiner direkten Kontrolle.

Wenn ein Drittanbieter langsam reagiert oder umfangreichen Code ausführt, kann sich das auf die Website-Performance auswirken.

Den geschäftlichen Nutzen externer Dienste berücksichtigen #

Die technische Optimierung darf nicht isoliert von der Funktion der Website betrachtet werden.

Ein notwendiger Zahlungsdienst kann beispielsweise nicht entfernt werden, nur weil er zusätzliche Ressourcen benötigt.

Bei einem kaum genutzten Social-Media-Widget kann die Abwägung dagegen anders aussehen.

Eine sinnvolle Frage lautet:

Ist der Nutzen dieser Funktion groß genug für die zusätzlichen technischen Kosten?

Browser-Entwicklerwerkzeuge verwenden #

Die Entwicklerwerkzeuge moderner Browser können zeigen, welche Ressourcen eine Website lädt und wie lange einzelne Anfragen benötigen.

Besonders hilfreich ist die Netzwerkansicht.

Dort kannst du beispielsweise erkennen:

HTML-Dokument
CSS-Dateien
JavaScript
Bilder
Fonts
API-Anfragen
externe Ressourcen
HTTP-Statuscodes
übertragene Datenmengen
Ladezeiten einzelner Requests

Eine Waterfall-Ansicht lesen #

Eine Wasserfallansicht zeigt die zeitliche Abfolge der geladenen Ressourcen.

In sintesi:

HTML        ███████
CSS            █████
JavaScript      █████████
Font              ██████
Hero-Bild            ███████████
API                       █████████

Damit kannst du erkennen, ob beispielsweise eine wichtige Ressource erst spät entdeckt wird oder eine externe Anfrage ungewöhnlich lange benötigt.

Nicht nur auf die Anzahl der Requests schauen #

Eine Seite mit 100 HTTP-Anfragen ist nicht automatisch langsamer als eine Seite mit 50.

Tra gli elementi decisivi vi sono:

Größe der Ressourcen
Caching
Ladepriorität
Abhängigkeiten
Übertragungsprotokoll
Verarbeitung im Browser
Antwortzeit der Quellen

Die Anzahl der Requests ist deshalb nur ein Teil der Analyse.

Gesamtgröße der Seite prüfen #

Die übertragene Datenmenge kann insbesondere bei mobilen Verbindungen relevant sein.

Wenn eine einfache Inhaltsseite beispielsweise viele Megabyte überträgt, lohnt sich eine Untersuchung der größten Ressourcen.

Häufig sind Bilder, Videos, Fonts oder umfangreiche JavaScript-Dateien beteiligt.

Die Gesamtgröße sollte jedoch im Kontext des Seitentyps beurteilt werden. Eine Bildergalerie benötigt naturgemäß mehr Daten als eine reine Textseite.

Core Web Vitals als Diagnosehinweis verwenden #

Die Core Web Vitals können helfen, die Art eines Performance-Problems einzugrenzen.

Auffälliger Wert	Erste Fragestellung
LCP	Warum erscheint der wichtige Hauptinhalt so spät?
INP	Warum reagiert die Seite langsam auf Interaktionen?
CLS	Warum verschieben sich Seitenelemente unerwartet?

Die genaue Bedeutung und Diagnose dieser Werte behandeln wir unter Core Web Vitals spiegati: LCP, INP e CLS.

Desktop schnell, Mobil langsam #

Wenn eine Website auf dem Desktop gut funktioniert, auf mobilen Geräten aber deutlich schlechter abschneidet, solltest du nicht automatisch von einem Messfehler ausgehen.

Mobile Geräte können weniger Rechenleistung besitzen und über langsamere oder instabilere Netzwerkverbindungen zugreifen.

Besonders umfangreiches JavaScript und große Datenmengen können sich unter solchen Bedingungen stärker bemerkbar machen.

Die Website auf einem echten Smartphone testen #

Neben synthetischen Messungen lohnt sich deshalb immer ein praktischer Test.

Öffne wichtige Seiten auf einem Smartphone und benutze sie tatsächlich.

Achte beispielsweise auf:

Erscheint der Hauptinhalt schnell?

Funktioniert das Menü unmittelbar?

Reagieren Buttons?

Springt das Layout?

Laden Bilder auffällig spät?

Reagieren Formulare schnell?

Funktioniert der Checkout?

Ein technischer Score ersetzt nicht die tatsächliche Benutzung der Website.

Eingeloggte und ausgeloggte Besucher unterscheiden #

Bei Content-Management-Systemen kann sich die Website für einen angemeldeten Administrator anders verhalten als für normale Besucher.

Bestimmte Cache-Mechanismen werden beispielsweise für eingeloggte Benutzer nicht verwendet.

Teste die öffentliche Website deshalb zusätzlich in einem privaten Browserfenster, in dem du nicht angemeldet bist.

Ist nur der WordPress-Adminbereich langsam? #

Wenn die öffentliche Website schnell ist, aber der Administrationsbereich langsam reagiert, handelt es sich um ein anderes Fehlerbild.

Dann solltest du nicht primär Bilder oder Frontend-Caching untersuchen.

Mögliche Ursachen können beispielsweise Plugins, externe API-Aufrufe, Datenbankoperationen oder Hintergrundprozesse innerhalb der Anwendung sein.

Die Diagnose sollte sich in diesem Fall auf den Administrationsbereich konzentrieren.

WooCommerce und dynamische Seiten #

Online-Shops besitzen Bereiche, die sich nicht wie gewöhnliche öffentliche Inhaltsseiten behandeln lassen.

Warenkorb, Kundenkonto und Checkout enthalten dynamische beziehungsweise benutzerspezifische Informationen.

Eine Cache-Konfiguration, die für einen Blogartikel funktioniert, kann für solche Seiten ungeeignet sein.

Attenzione: Ändere Cache- und JavaScript-Einstellungen bei einem produktiven Online-Shop nur kontrolliert. Teste anschließend Warenkorb, Login, Checkout und Zahlungsablauf vollständig.

Hintergrundprozesse berücksichtigen #

Backups, Imports, Exporte, Cronjobs, Bildverarbeitung oder andere Hintergrundaufgaben können Ressourcen beanspruchen.

Wenn Performance-Probleme immer zu bestimmten Zeiten auftreten, sollte deshalb geprüft werden, ob parallel wiederkehrende Prozesse laufen.

Ein einzelner Test während eines umfangreichen Imports ist möglicherweise nicht repräsentativ für den normalen Betrieb.

Fehlerprotokolle prüfen #

Bei ungewöhnlichem Verhalten können Fehlerprotokolle wichtige Hinweise liefern.

Wiederkehrende PHP-Fehler, Timeouts oder andere Meldungen können auf ein konkretes Problem hinweisen.

Ein Log sollte jedoch nicht allein nach der Anzahl der Einträge beurteilt werden. Entscheidend sind Zeitpunkt, Art und Zusammenhang mit dem beobachteten Performance-Problem.

HTTP-Fehler sind nicht dasselbe wie langsame Performance #

Wenn eine Ressource mit einem Fehlerstatus antwortet, handelt es sich nicht mehr ausschließlich um eine Performance-Frage.

Esempi:

403 → Zugriff verweigert
404 → Ressource nicht gefunden
500 → interner Serverfehler

Die wichtigsten Statuscodes erklären wir unter Codici di stato HTTP spiegati: 200, 301, 404, 403 e 500.

DNS-Probleme von Performance-Problemen unterscheiden #

Wenn eine Domain überhaupt nicht korrekt aufgelöst wird, handelt es sich zunächst um ein DNS- beziehungsweise Erreichbarkeitsproblem und nicht um eine gewöhnliche langsame Website.

Auch solche Fehler können für Besucher subjektiv wie „die Website lädt nicht“ wirken.

Deshalb ist eine genaue Fehlerbeschreibung wichtig.

HTTPS-Probleme können ebenfalls anders aussehen #

Fehlerhafte Zertifikate, Mixed Content oder andere HTTPS-Probleme sind ebenfalls von einer reinen Performance-Störung zu unterscheiden.

Die entsprechende Diagnose behandeln wir später unter Controllo del certificato SSL e HTTPS: individuare gli errori comuni.

Serverressourcen und Limits #

Webanwendungen benötigen Rechenzeit, Arbeitsspeicher und weitere Ressourcen.

Werden verfügbare Ressourcen oder definierte Limits erreicht, kann sich dies auf die Verarbeitung auswirken.

Allerdings sollte auch hier die Ursache untersucht werden.

Wenn beispielsweise ein fehlerhaftes Plugin extrem viele Ressourcen benötigt, ist eine Erhöhung des Limits möglicherweise nur eine kurzfristige Symptombehandlung.

Mehr Leistung ist nicht immer die Lösung #

Ein leistungsfähigerer Tarif oder Server kann bei einem tatsächlichen Ressourcenengpass sinnvoll sein.

Er sollte aber nicht als erste Standardantwort auf jedes Performance-Problem verwendet werden.

Website langsam
      ↓
Ursache feststellen
      ↓
tatsächlicher Ressourcenengpass?
      ↓
JA → Ressourcenbedarf bewerten

NEIN → technische Ursache beheben

CDN: sinnvoll, aber kein Allheilmittel #

Ein Content Delivery Network kann bestimmte statische Ressourcen über geografisch verteilte Systeme bereitstellen und dadurch insbesondere für räumlich weit verteilte Zielgruppen Vorteile bieten.

Ein CDN repariert jedoch keinen ineffizienten PHP-Code und keine langsame Datenbankabfrage.

Auch hier muss die Maßnahme zum tatsächlichen Engpass passen.

Standort der Besucher berücksichtigen #

Netzwerklatenz hängt unter anderem davon ab, über welche Strecke und Route Daten übertragen werden.

Wenn die Zielgruppe einer Website überwiegend in der Schweiz und Mitteleuropa liegt, sollte die Performance nicht ausschließlich anhand eines Teststandorts auf einem anderen Kontinent beurteilt werden.

Für reproduzierbare Vergleiche sollten möglichst ähnliche Testbedingungen verwendet werden.

Ist die Website wirklich langsam oder nur dein Anschluss? #

Auch die lokale Internetverbindung, ein VPN, WLAN-Probleme, Browser-Erweiterungen oder ein einzelnes Gerät können das Ergebnis beeinflussen.

Wenn nur du ein Problem bemerkst, solltest du deshalb gegenprüfen.

Per esempio:

anderer Browser
privates Browserfenster
anderes Gerät
Mobilfunk statt WLAN
VPN testweise deaktivieren
anderer Internetanschluss

Ändert sich das Verhalten deutlich, liegt möglicherweise kein allgemeines Website-Problem vor.

Performance und Verfügbarkeit unterscheiden #

Eine Website, die zeitweise überhaupt nicht erreichbar ist, besitzt nicht einfach nur ein Ladezeitproblem.

Wenn ein Fehler sporadisch auftritt, kann kontinuierliches Monitoring helfen festzustellen, wann und wie häufig die Website tatsächlich nicht erreichbar war.

Das behandeln wir unter Monitoraggio di siti web: monitorare la disponibilità e le interruzioni.

Nicht fünf Optimierungs-Plugins gleichzeitig einsetzen #

Mehrere Performance-Plugins mit überlappenden Funktionen können zu schwer nachvollziehbaren Wechselwirkungen führen.

Wenn beispielsweise mehrere Systeme gleichzeitig Caching, Minifizierung, Lazy Loading und JavaScript-Optimierung übernehmen, wird die Fehlersuche unnötig kompliziert.

Eine klar dokumentierte Konfiguration ist besser als möglichst viele gleichzeitig aktive Optimierungen.

Nicht gleichzeitig zehn Dinge ändern #

Für eine systematische Diagnose solltest du Änderungen nachvollziehbar durchführen.

Wenn du gleichzeitig Plugins deaktivierst, Bilder ersetzt, Caching umstellst, PHP änderst und JavaScript verzögerst, weißt du anschließend nicht, welche Maßnahme welchen Effekt hatte.

Besser:

messen
  ↓
Hypothese bilden
  ↓
eine gezielte Änderung
  ↓
testen
  ↓
erneut messen
  ↓
Ergebnis dokumentieren

Nach Performance-Änderungen Funktionen testen #

Eine Website ist nicht optimiert, wenn sie zwar schneller lädt, aber wichtige Funktionen nicht mehr korrekt arbeiten.

Nach technischen Änderungen solltest du deshalb neben den Messwerten auch die tatsächliche Funktion prüfen.

Bei einer normalen Unternehmenswebsite beispielsweise:

Navigation
Kontaktformular
Suche
mobile Ansicht
Cookie-Banner
interaktive Elemente

Bei einem Shop zusätzlich:

Produktvarianten
Warenkorb
Gutscheine
Kundenkonto
Checkout
Zahlung

Wann solltest du professionelle Hilfe einbeziehen? #

Wenn sich die Ursache mit normalen Messwerkzeugen nicht eindeutig eingrenzen lässt, kann eine tiefergehende technische Analyse notwendig sein.

Das gilt besonders bei:

sporadisch extrem langen Antwortzeiten
wiederkehrenden Timeouts
>500-Fehlern
hoher Datenbanklast
komplexen Shop-Problemen
externen API-Abhängigkeiten
Problemen nur unter höherer Last
schwer reproduzierbaren Fehlern

In solchen Fällen können Server- und Anwendungslogs, Profiling oder weitere Diagnosewerkzeuge erforderlich sein.

Ein sinnvoller Diagnoseweg #

Website wirkt langsam
        ↓
Problem reproduzieren
        ↓
betroffene URL bestimmen
        ↓
nur eine oder alle Seiten?
        ↓
dauerhaft oder sporadisch?
        ↓
mehrfach messen
        ↓
serverseitige Antwort auffällig?
        ↓
JA
→ PHP / Anwendung / Datenbank
→ externe APIs
→ Cache
→ Hintergrundprozesse
→ Ressourcen prüfen

NEIN
→ Browser / Frontend untersuchen
→ Bilder
→ CSS
→ JavaScript
→ Fonts
→ externe Ressourcen
        ↓
Core Web Vitals prüfen
        ↓
konkreten Engpass identifizieren
        ↓
eine gezielte Änderung durchführen
        ↓
Funktion der Website testen
        ↓
unter vergleichbaren Bedingungen erneut messen

Diagnose nach Symptom #

Symptom	Erster Prüfbereich
Seite bleibt zunächst lange leer	HTML-Antwort, TTFB, serverseitige Verarbeitung
Hauptinhalt erscheint sehr spät	LCP-Element, Bilder, Fonts, blockierende Ressourcen
Klicks reagieren verzögert	INP, JavaScript, Main Thread
Elemente springen beim Laden	CLS, Bilder, Fonts, dynamische Inhalte
Nur eine Seite ist langsam	seitenspezifische Ressourcen und Funktionen
Nur Shop-Seiten sind langsam	dynamische Shop-Prozesse, Datenbank, Plugins
Nur gelegentlich langsam	Monitoring, externe Dienste, Hintergrundprozesse, Last
Nur für dich langsam	Gerät, Browser, Netzwerk, VPN

Häufige Fehler bei der Performance-Fehlersuche #

sofort das Hosting verantwortlich machen

nur einen einzigen Test durchführen

nur die Startseite testen

Performance-Score mit Ladezeit gleichsetzen

alle Plugins gleichzeitig deaktivieren

mehrere Cache-Systeme übereinander installieren

Cache leeren als dauerhafte Lösung betrachten

jede PageSpeed-Empfehlung blind umsetzen

JavaScript ungeprüft verzögern

alle Bilder pauschal lazy laden

Datenbankgröße mit Datenbankgeschwindigkeit gleichsetzen

nur Desktop testen

externe Dienste ignorieren

mehrere Änderungen gleichzeitig durchführen

nach Änderungen nur den Score prüfen
und nicht die Website selbst

Checkliste: Langsame Website systematisch untersuchen #

Welche URL ist langsam?
        ↓
Sind weitere Seiten betroffen?
        ↓
Problem dauerhaft oder sporadisch?
        ↓
Mobil und Desktop getestet?
        ↓
mehrere Messungen durchgeführt?
        ↓
HTML-Antwort / TTFB auffällig?
        ↓
PHP / Anwendung prüfen
        ↓
Datenbank prüfen
        ↓
externe APIs prüfen
        ↓
Caching prüfen
        ↓
Bilder und Datenmenge prüfen
        ↓
JavaScript prüfen
        ↓
CSS prüfen
        ↓
Fonts prüfen
        ↓
Drittanbieter-Ressourcen prüfen
        ↓
Core Web Vitals betrachten
        ↓
konkrete Ursache eingrenzen
        ↓
eine Änderung durchführen
        ↓
Website vollständig testen
        ↓
erneut messen
        ↓
Ergebnis dokumentieren

Riepilogo #

Eine langsame Website kann viele unterschiedliche Ursachen haben. Deshalb ist „Website schneller machen“ keine einzelne technische Maßnahme, sondern zunächst eine Diagnoseaufgabe.

Stelle zuerst fest, ob das Problem die gesamte Website oder nur bestimmte Seiten betrifft und ob es dauerhaft oder nur sporadisch auftritt. Anschließend solltest du zwischen serverseitiger Verarbeitung und browserseitiger Performance unterscheiden.

Bei einer langsamen serverseitigen Antwort kommen unter anderem PHP, Anwendung, Datenbank, externe APIs, Caching und Hintergrundprozesse infrage. Antwortet der Server schnell, solltest du verstärkt Bilder, JavaScript, CSS, Fonts und externe Ressourcen untersuchen.

Messwerkzeuge wie PageSpeed Insights, die Browser-Entwicklerwerkzeuge und die Core Web Vitals helfen dabei, einen Engpass einzugrenzen. Ihre Hinweise sollten jedoch nicht ungeprüft als automatische Optimierungsanweisungen verstanden werden.

Führe Änderungen kontrolliert durch, teste anschließend die tatsächliche Funktion der Website und miss unter vergleichbaren Bedingungen erneut.

Die wichtigste Regel bei einer langsamen Website lautet deshalb nicht „mehr optimieren“, sondern: Erst das Problem reproduzieren, dann den Engpass identifizieren und anschließend genau die Ursache beheben, die tatsächlich für die Verzögerung verantwortlich ist.