Many optimization articles focus on how to speed up your WordPress site, such as optimizing your images or switching to a faster host. While these are all important, today we’d like to discuss with you the impact of third-party performance and the impact it has on your WordPress site. Basically everything that you call externally from your website has loading time sequences. What makes this problem worse is that some of them are only sporadically slow, which makes identifying the problem even more difficult. Today we’re going to explore ways we can identify and analyze third-party services and performance issues.
- What are third-party external services?
- Identification of external services
- Analysis of continuous third-party performance issues
- Analysis of intermittent third-party performance problems
What are third-party external services?
An external third party service could be viewed as anything that communicates with your WordPress site from outside of your own server. Here are some common examples we come across on a regular basis:
- Social media platforms such as Twitter, Facebook and Instagram ( widgets or conversion pixels)
- Third party advertising networks such as Google Adsense, Media.net, BuySellAds, Amazon Associates, etc.
- Website analyzes such as Google Analytics , Crazy Egg, Hotjar, etc.
- A / B testing tools like Optimizely, VWO, Unbounce, etc.
- WordPress comment systems like Disqus, Jetpack, Facebook comments
- Backup and security tools such as VaultPress, Sucuri, CodeGuard, etc.
- Social sharing tools like SumoMe, HelloBar and HelloBar
- CDN networks like KeyCDN, Amazon CloudFront, CDN77 and StackPath
- Externally hosted Javascript
How external services cause problems
External services typically pose two problems. One is caused by the sheer volume, the other has to do with waiting for them to load.
- If you have a lot of external services , you have to load all of them and wait for information from them every time you view a page. The more calls you have, the more you wait, the higher the load on your own server and the higher your chance of encountering the second problem.
- In some cases the page will wait for the data to be transferred between your website and the external service . If the service is called in the header and there is a service interruption, your page will simply refuse to load.
Of course, there are things that can be done to speed things up, like loading scripts asynchronously, but we’ll get into his later. In most cases, sheer volume is one of the biggest issues to deal with when debugging third-party performance issues.
Identification of external services
Die Identifizierung dieser Dienstleistungen ist nicht allzu schwierig. Eine der einfachsten Möglichkeiten ist es, ein Website-Geschwindigkeitstestwerkzeug zu öffnen, sei es Pingdom, GTmetrix, WebPageTest oder Chrome Devtools, und deine Website damit zu durchlaufen. Du solltest eine Liste der Ressourcen sehen, die geladen wurden. Bewege den Mauszeiger über eine Ressource und wenn sie am Anfang nicht deinen Domainnamen enthält, ist das entweder ein externer Dienst oder ein externes Asset, das du aufrufst.
Unten siehst du, dass die verkleinerte Version von jQuery von einer externen Quelle (https://ajax.googleapis.com) geladen wurde.
Wenn du nicht weißt, wofür der externe Service gedacht ist, kannst du jederzeit versuchen, die Hauptdomain aufzurufen oder nach ihrem Namen in Google zu suchen, wie es der Entwickler oder das zugehörige Unternehmen tun sollte. Dies ist eine gute Möglichkeit, um festzustellen, ob der Service legal ist. Wie du unten sehen kannst, führt die Suche nach der jQuery-Datei zu einigen bekannten Unternehmen wie jQuery und Google, die das Hosting dieser Datei beschreiben. Also bist du wahrscheinlich sicher.
Analyse kontinuierlicher Leistungsprobleme von Drittanbietern
Wenn deine Website immer langsam ist, musst du herausfinden, was sie verlangsamt. Wenn deine Website intermittierende Probleme hat, ist das etwas schwieriger. Beginnen wir mit einer kontinuierlichen Langsamkeit. Wir gehen hier davon aus, dass deine Website aufgrund von externen Diensten langsam ist. Während viele Geschwindigkeitsprobleme durch externe Dienste verursacht werden können, gibt es eine Vielzahl anderer Probleme, so dass dies möglicherweise deine Probleme nicht löst.
Zuerst musst du feststellen, ob es einen Dienst gibt, der eine lange Zeit zum Laden benötigt und wie er sich auf die Leistung deiner Website auswirkt. Deshalb haben wir eine Testseite eingerichtet, die auf Kinsta gehostet wird und die Folgendes enthält:
- 2 Google AdSense Anzeigen
- Facebook Like Box
- Instagram Widget
- Disqus Kommentare
- Facebook-Konvertierung Tracking-Pixel
- Google Analytics
Dies wird es uns ermöglichen, jeden Dienst einzeln zu entfernen und dir zu zeigen, wie sehr jeder einzelne Dienst deine gesamte Website-Last beeinflusst. Wir werden auch einige Strategien für alternative Ladeverfahren vorstellen. Du kannst dann die gleichen Strategien auf deine eigene WordPress-Seite anwenden. Wir haben die Testseite durch Pingdom laufen lassen und eines der ersten Dinge, die du dir ansehen kannst, ist die „Content Size by Domain“ und die „Requests by Domain“. Wenn du Anfragen siehst, nicht von deinem Domänennamen, sind dies höchstwahrscheinlich externe Dienste oder externe Assets. Das ist ein guter Anfang. Wie du unten sehen kannst, hat static.xx.fbcdn.net 37 Anfragen, was nicht gut ist!
Die Ladezeit der Website betrug ebenfalls 1,94 Sekunden, was wirklich nicht gut ist, denn wie du oben sehen kannst, hat die Testseite keinen Inhalt darauf. Dies ist ein kleinerer Test, der dir hilft, die Leistung von Drittanbietern besser zu analysieren. Je größer die WordPress-Seite, desto größer werden die Probleme. Aber im Grunde genommen können die meisten Probleme auf ähnliche Weise gelöst werden.
Bekämpfung von Google AdSense
Das allererste, was wir in Angriff nehmen wollen, ist Google Adsense. Typischerweise, wenn du einen Geschwindigkeitstest durchführst, kannst du mit der Maus über jeden Balken fahren, um zu sehen, wie lange jeder Teil des Ladevorgangs gedauert hat. Du solltest nach extra langen Stangen (im Vergleich zum Rest) und Orten suchen, an denen die Stangen erst dann geladen werden, wenn eine bestimmte Stange fertig ist – das sind deine Engpässe. Sobald du ein bestimmtes Element gefunden hast, das zu lange dauert oder andere Ressourcen am Laden hindert, musst du herausfinden, warum es da ist und woher es kommt.
Dies kann etwas schwierig sein, der Aufruf des Dienstes könnte innerhalb deines Themas kodiert sein, oder es könnte von einem Plugin kommen. Wie wir bereits erwähnt haben, gibt es jedoch auch die Frage des schieren Volumens. Wenn wir uns die folgenden Anfragen von pagead2.googlesyndication.com und tpc.googlesyndication.com ansehen, können wir sehen, dass die Balken ziemlich kurz sind, was bedeutet, dass sie nicht so viel Verzögerung verursachen. Einige von ihnen haben jedoch eine längere Empfangszeit (grüner Balken), was die Zeit ist, die der Webbrowser benötigt, um Daten vom Server zu empfangen. Das große Problem ist, wenn du alle Anfragen zusammengenommen hast.
Wir nennen Google AdSense gerne einen variablen Drittanbieter-Service. Das liegt daran, dass jedes Mal, wenn eine Seite geladen wird, eine andere Anzahl von Anfragen und Assets geladen werden. Dies macht es sehr schwierig festzustellen, was Leistungsprobleme verursacht, da es bei jedem Geschwindigkeitstest anders sein wird. Nachfolgend findest du einen Auszug aus einigen der Anfragen von Drittanbietern, die die Anzeigen generieren. Sie erzeugen auch Redirects, die ihre eigenen Delays haben.
Du denkst vielleicht, dass es verrückt ist, wenn nur zwei Anzeigen so viele Anfragen generieren, aber so funktionieren sie.
Option 1 – Asynchronisation laden
Deine erste Option ist, sicherzustellen, dass sie asynchron geladen werden. Das async-Attribut sagt dem Browser im Grunde genommen, dass er sofort mit dem Herunterladen der Ressource beginnen soll, ohne das HTML-Parsing zu verlangsamen. Sobald die Ressource verfügbar ist, wird das HTML-Parsing angehalten, damit die Ressource geladen werden kann. Neu generierter Code aus Google AdSense hat dieses Attribut standardmäßig, aber wenn du Code hast, der noch ein paar Jahre alt ist, empfehlen wir, ihn zu überprüfen.
<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- nogluten-top-right-page-300x250 -->
<ins class="adsbygoogle" style="display: block;" data-ad-client="ca-pub-xxxxxxxxxxx" data-ad-slot="9805695044" data-ad-format="auto"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>
Schau dir unseren anderen Beitrag über die Beseitigung von Render-Blocking von JavaScript und CSS an. Dies kann dir helfen, besser zu verstehen, wie Skripte auf deiner WordPress-Seite geladen und funktioniert.
Option 2 – Entferne sie
Deine andere Möglichkeit ist es, Google AdSense vollständig zu entfernen. Offensichtlich ist dies bei einigen Websites, die auf Werbeeinnahmen von Drittanbietern angewiesen sind, keine Option. Aber wir haben gesehen, wie E-Commerce-Websites eine AdSense-Anzeige auf ihre Website werfen und nur versuchen, einen schnellen Gewinn zu erzielen. Du solltest dir der Performance-Probleme bewusst sein. Wenn du Produkte oder Dienstleistungen verkaufst, kann eine Google AdSense-Anzeige mehr Schaden als Nutzen anrichten und deiner Haupteinnahmequelle schaden. Für Blogger kannst du auch in Affiliate-Werbung vs. AdSense schauen. Viele Male mit Affiliate-Anzeigen kannst du sie aus deinem CDN laden und es wird nur eine einzige Anfrage geben.
In this example, we’re going to remove the ads to show you how just two small ads can affect the overall performance of your WordPress site. So after removing it, we ran another speed test and as you can see, our load times dropped from 1.94 seconds to 909 ms! Our requests went down from 185 to 138 and our total page size was reduced from 2MB to 1.7MB.
That’s right! Two small displays added about a second to our total load time. For this reason, unless your income model revolves around third-party advertising, you shouldn’t be putting them on your WordPress site. If you have a problem with an ad network and you have a plugin that handles the ad network for you, chances are that disabling that plugin will eliminate the problem. If it’s coded within the topic, you’ll need to modify your topic files. We recommend doing both of the following if you’re a developer (if you’re not here, you can learn more about how to find a good WordPress developer ).
Attack the Facebook Like Box
The next thing to check out is the Facebook-like box that is causing all of these static.xx.fbcdn.net and scontent.xx.fbcdn.net requests. We can see that the bars are pretty short, which means that they don’t add that much lag. However, when you add them all together and that’s where the problem is. Again, there is a sheer volume problem.
We recommend every page owner to stay away from the Facebook-like box ! Not only does it generate a lot of queries to external JavaScript, it also loads a lot of images. Here are three recommendations to help you handle this better.
Option 1 – load asynchronization
Um die Facebook-ähnliche Box zu verwenden, hättest du oder ein Entwickler den folgenden Code in den Header deiner WordPress-Seite einfügen müssen. Es gibt auch einige WordPress Widgets, die die Box ebenfalls hinzufügen.
<script>(function(d, s, id) {
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
js = d.createElement(s); js.id = id;
js.src = "//connect.facebook.net/en_US/sdk.js#xfbml=1&version=v2.9&appId=1697897870426976";
fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>
Das Problem mit dem obigen Code ist, dass er nicht asynchron geladen wird. Das async-Attribut sagt dem Browser im Grunde genommen, dass er sofort mit dem Herunterladen der Ressource beginnen soll, ohne das HTML-Parsing zu verlangsamen. Sobald die Ressource verfügbar ist, wird das HTML-Parsing angehalten, damit die Ressource geladen werden kann. Wir sind uns nicht sicher, warum Facebook dieses Attribut nicht zum Skript hinzugefügt hat, aber du kannst die modifizierte Version unten sehen, die es asynchron lädt.
<script>(function(d, s, id) {
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
js = d.createElement(s); js.id = id;
js.async=true; js.src = "//connect.facebook.net/en_US/sdk.js#xfbml=1&version=v2.9&appId=1697897870426976";
fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>
Du wirst wahrscheinlich keinen großen Unterschied in den Ladezeiten bemerken, wenn du es in Pingdom überprüfst, aber deine Besucher werden es definitiv, da es sich darauf auswirkt, wie/wann die Skripte und Assets geladen werden.
Option 2 – Verwende stattdessen ein Bild-Banner
Die nächste Empfehlung ist, die Facebook-ähnliche Box durch ein Bannerbild zu ersetzen, das einfach auf deine Facebook-Seite verlinkt. Dies würde die Anforderungen von 40+ sofort auf 1 reduzieren und du hättest nicht mehr die externen Abhängigkeiten. Auf diese Weise kann man sehr kreativ werden und es ist eine gute Balance zwischen Design und Leistung.
Option 3 – Lass dich davon befreien
Und schließlich wäre die letzte Option, sie ganz loszuwerden. Wir haben das auf unserem Testgelände getan und wie du unten sehen kannst, hat es unsere Ladezeiten von 909 ms auf 786 ms reduziert. Es reduzierte das Gesamtgewicht der Seite von 1,7 MB auf 1,0 MB und die Gesamtzahl der Anfragen von 138 auf 78. Eine Sache, die man hier wirklich hervorheben sollte, ist die Gewichtsreduzierung der Seite. Die Facebook-ähnliche Box hat 700 KB hinzugefügt! Das ist ziemlich schlimm.
Das Instagram Widget in Angriff nehmen
Das nächste, was du dir ansehen solltest, ist das Instagram Widget. In unserem Beispiel verwenden wir das kostenlose Instagram Feed Plugin. Das Plugin ist eigentlich nicht das Problem, sondern die generierten Anfragen von scontent.cdninstagram.com. Wir können sehen, dass die Balken ziemlich kurz sind, was bedeutet, dass sie nicht zu einer so großen Verzögerung führen. Allerdings, wenn man sie alle zusammen addiert und das ist, wo das Problem ist. Auch hier handelt es sich um ein Problem der schieren Lautstärke. Du kannst wahrscheinlich sehen, wie sich hier ein Muster bildet. Viele Performance-Probleme von Drittanbietern auf WordPress-Sites sind nicht auf Verzögerungen bei einzelnen Anfragen zurückzuführen, sondern auf solche, die sich zunächst nicht um die Performance kümmern.
Wir empfehlen auch, sich vom Instagram-Widget fernzuhalten, wenn du es nicht wirklich brauchst, da es viele Anfragen generiert. Hier sind ein paar Empfehlungen, um dies besser zu handhaben.
Option 1 – Verwende stattdessen ein Bild-Banner
Genau wie bei der Facebook-ähnlichen Box, es sei denn, du brauchst wirklich ein dynamisches Instagram-Widget, erstelle stattdessen ein Banner, das auf deine Instagram-Seite verlinkt. Dies würde die 20+ Anfragen sofort auf 1 reduzieren und du hättest nicht mehr die externen Abhängigkeiten. Auf diese Weise kann man sehr kreativ werden und es ist eine gute Balance zwischen Design und Leistung.
Option 2 – Lass dich davon befreien
Und natürlich kannst du es einfach ganz loswerden. Wir haben das auf unserem Testgelände getan und wie du unten sehen kannst, hat es unsere Ladezeiten von 786 ms auf 690 ms reduziert. Es reduzierte das Gesamtgewicht der Seite von 1,0 MB auf 814,3 KB und die Gesamtzahl der Anfragen von 78 auf 57.
Umgang mit disqus Kommentaren
Das nächste, was man sich anschauen sollte, sind die Disqus-Kommentare. In unserem Beispiel verwenden wir das kostenlose Disqus Comment System Plugin. Das große Problem mit Disqus ist, dass es viele Anfragen generiert und den Gravatar für jede einzelne kommentierende Person laden muss. Wir haben in unseren Beiträgen ausführlich darauf eingegangen, wie man WordPress-Kommentare beschleunigen kann.
Vielleicht möchten Sie auch Kommentare in WordPress komplett deaktivieren.
Wenn du eine große kommerzielle Website bist, musst du vielleicht auch bezahlen, um Disqus-Anzeigen zu entfernen, und wenn du es nicht tust, würde das dazu führen, dass noch mehr Anfragen auf deiner Website generiert werden. Nachfolgend siehst du einen kleinen Ausschnitt aus nur einigen der Anfragen, die sie erzeugt.
Hier sind ein paar Empfehlungen, wenn es um den Umgang mit Kommentaren geht.
Option 1 – Lazy Load Disqus Kommentare
Lazy loading ist der Prozess des Nicht-Ladens der Assets und Skripte, bis die Person die Seite nach unten gescrollt hat. Dadurch wird sichergestellt, dass das Laden der ersten Seite schneller erfolgt. Du kannst Disqus-Kommentare mit dem kostenlosen Disqus Conditional Load-Plugin von Joel James einfach faul laden. Wir verwenden dies tatsächlich im Kinsta-Blog. Wir haben das Plugin auf unserem Testgelände installiert und wie du unten sehen kannst, hat es unsere Ladezeiten von 690 ms auf 603 ms reduziert. Es reduzierte das gesamte Seitengewicht von 814 KB auf 366,1 KB und die Gesamtzahl der Anfragen von 57 auf 24. Eine Sache, die man hervorheben sollte, ist die massive Gewichtsreduzierung der Seiten!
Option 2 – Lazy Load Native WordPress Kommentare
Deine andere beste Option wäre, die nativen WordPress-Kommentare faul zu laden. Joel James, der gleiche Entwickler des Lazy Load Disqus Plugins, hat auch ein kostenloses Plugin namens Lazy Load for Comments. Dies funktioniert in einer sehr ähnlichen Weise wie die obige. Wir haben das Plugin auf unserem Testgelände installiert und wie du unten sehen kannst, führte es zu einer fast gleichmäßigen Reduzierung der Ladezeit.
Auseinandersetzung mit dem Facebook Conversion Tracking Pixel
Und schließlich werfen wir einen Blick auf den Facebook-Konvertierungs-Tracking-Pixel. Offensichtlich verwenden meisten Menschen dies, um Daten über Personen zu sammeln, die ihre Website besuchen, oder um Konvertierungen zu verfolgen, wenn sie Facebook-Anzeigen schalten. Es ist also nicht immer möglich, dies zu entfernen, und es gibt wirklich nichts, was man tun kann, um die Leistung zu verbessern. Wie du unten sehen kannst, ist sie für das Erzeugen von 5 verschiedenen HTTP-Requests verantwortlich, und leider sind sie nicht die schnellsten.
Wir werden dies einfach entfernen, um dir zu zeigen, wie sehr es die Leistung deiner Website beeinflusst. Nachdem wir es von unserer Seite genommen hatten, sank unsere Ladezeit von 611 ms auf 429 ms. Es reduzierte das gesamte Seitengewicht von 367,5 KB auf 343,2 KB und die Gesamtzahl der Anfragen von 27 auf 22.
Die obigen Beispiele sind nur einige von Tausenden von externen Diensten, die du auf deiner WordPress-Seite ausführen kannst. Es ist wichtig, sich jeden einzelnen anzusehen und festzustellen, wie sehr er die Leistung deiner Website beeinflusst. Wie du sehen kannst, kann schon ein einziger fauler Apfel große Probleme verursachen!
Externe Dienstleistungen können die Performance verbessern
Während die meisten externen Dienste die Leistung deiner Website beeinträchtigen, gibt es diejenigen, die ihr ebenfalls helfen können. Ein CDN, wie KeyCDN oder Cloudflare, kann deine Website mit minimalem Einrichtungsaufwand drastisch beschleunigen. In unserem Tutorial erfährst du, wie man KeyCDN einrichtet und wie man Cloudflare installiert. In diesem Beispiel unten haben wir KeyCDN zu unserer Testseite hinzugefügt. Wie du sehen kannst, hat es unsere Ladezeit um weitere 100 ms verkürzt.
Weitere Optimierungen
Wir haben dann ein paar zusätzliche Optimierungen auf der WordPress-Seite vorgenommen, um uns zu einem Ergebnis von 100 Leistungsstufen und einer Ladezeit von 270 ms zu bringen. Diese Optimierungen umfassten unter anderem:
- Stelle sicher, dass alles vom CDN-Anbieter geladen wurde. Dies bedeutete, dass Google-Schriften lokal bereitgestellt werden mussten und zu einer einzigen HTTP/2-Anfrage führte.
- Entfernen zusätzlicher Assets, die unnötige HTTP-Anfragen erzeugen, wie Emojis, Embeds, jQuery-Migration, etc. Wir haben das Perfmatters Plugin verwendet.
Hier sind vertiefende Tutorials für einige der Optimierungen:
- Wie man Emojis deaktiviert
- Wie man Einbettungen deaktiviert
- So behebst du die Warnung zum Zwischenspeichern von Browsern mit Hebelwirkung
- Wie man Abfragezeichenketten aus statischen Ressourcen entfernt
- Wie man WordPress Performance-Engpässe mit New Relic findet
- 8 weniger bekannte (aber nützliche) WordPress Performance Plugins
- So deaktivierst du WordPress-Plugins (kein Zugriff auf WP-Admin)
Wie du sehen kannst, haben wir von 1,94 Sekunden auf 270 ms Ladezeiten abgesenkt! Natürlich benötigst du vielleicht einige externe Dienste, wie es jedes Unternehmen tut. Aber es ist wichtig, nicht zu vergessen, jeden einzelnen zu analysieren. Wenn du enorme Ladezeiten siehst, wende dich an den Entwickler oder die Firma, die dafür verantwortlich ist, und bringe das Problem zur Sprache.
Verhindern von blockierter Ladung
Das größere Problem ist, wenn ein Skript das Laden verhindert, während es das Laden selbst beendet. Wenn ein solches Skript im Header enthalten ist, kann es deine Website auf unbestimmte Zeit leer halten. Aus diesem Grund sollte alles, was nicht unbedingt in der Kopfzeile notwendig ist, in der Fußzeile platziert werden. Dies ermöglicht es deiner Website, vollständig zu laden, bevor das problematische Skript überhaupt mit dem Laden beginnt. Wenn du die Funktion wp_enqueue_script() verwendest (das solltest du), kannst du mit dem fünften Parameter angeben, dass er in der Fußzeile geladen werden soll.
Wenn du feststellst, dass ein Plugin ein Asset ohne Grund in den Header lädt, kannst du es mit wp_dequeue_script() aus dem Header entfernen und es dann mit wp_enqueue_script() auf die gleiche Weise registrieren, aber in der Fußzeile.
Verwendung von Google Tag Manager
Eine weitere Möglichkeit, bei der Lösung von Performance-Problemen von Drittanbietern zu helfen, ist die Verwendung eines kostenlosen Tools wie Google Tag Manager. So kannst du alle deine Skripte und Tags an einem Ort verwalten. Ein paar Vorteile davon sind, dass sie asynchron geladen werden, die Verwaltung wird einfacher, und du kannst Zündtrigger einrichten, für welche Seiten Skripte geladen werden.
Allerdings gibt es auch hier einige Nachteile:
Google Tag Manager reduziert nicht die Anzahl der Tags auf deiner Website oder App, aber es vereinfacht die Verwaltung der Tags. Für Websites wird Google Tag Manager asynchron ausgeführt und kann so konfiguriert werden, dass Tags nur dann ausgelöst werden, wenn sie benötigt werden, wodurch deine Seiten schneller geladen werden können. (Quelle)
Wenn du Google Tag Manager verwendest, hast du auch eine weitere HTTP-Anfrage und eine DNS-Suche bei googletagmanager.com, obwohl sie sehr vernachlässigbar ist.
Wir empfehlen, Google Tag Manager für große, nicht optimierte Websites mit vielen Diensten und Integrationen von Drittanbietern zu verwenden. Für kleinere Websites mit Entwicklern wirst du höchstwahrscheinlich nicht so viel von einer Leistungssteigerung durch den Einsatz von GTM sehen.
Analyse von zeitweiligen Performance-Problemen von Drittanbietern
The way you solve intermittent problems is the same as the way you solve continuous problems, but identifying the culprit is more difficult. Implementing the solutions above might already help, but it would be nice to know what is causing the problem anyway. One tool we love to use for this is New Relic and if you are a Kinsta user we can monitor this on your website or allow you to use your own New Relic license key . Below is an example of some third-party ad networks and the associated high loading times over a period of time.
Ironically, New Relic can also cause performance issues. In this case, we recommend using it for troubleshooting and sporadic monitoring, not for continuous operation. You can also use a tool like GTMetrix to schedule hourly speed checks on your website. After a few days you can look back and see the results in a nice little graph:
This will show you when your site was slower than average. We’d click on the far right tip first to get into the report generated at this point. We would then look at the waterfall to see which resource caused the problem. Check out our in-depth post on how to use GTmetrix to diagnose problems on your website .
There’s an advantage in this that seems to block subsequent ones, take a look at the green bar near the center. It turned out that this was from Google Recaptcha . 632ms may seem like a wink, but in reality it’s a lot . A page should really load in 2 seconds – say . More than a third of that is drawn from that one asset alone. The system should either be charged later or it should be discarded in favor of other verification methods.
Summary
As you can see, few outside services can have a huge impact. Third-party performance cannot be neglected and goes hand in hand with on-site and back-end optimizations. Fortunately, though, there is a lot to do, especially when involving a developer. Ditching services tweaking them to load in different ways like async, delivering the same thing in an alternate way like a banner, all can go a long way in making your site much faster!
Brian hat eine große Leidenschaft für WordPress, verwendet es seit über einem Jahrzehnt und entwickelt sogar einige Premium-Plugins. Brian liebt Blogging, Filme und Wandern. Verbinde dich mit Brian auf Twitter.
Schreibe einen Kommentar