Optimieren Sie Ihre Website mit dem dynamischen Google-PageSpeed-Modul für NGINX Plus

NGINX | 03. März 2017

Da die durchschnittliche Größe von Webseiten stetig zunimmt, wird es immer wichtiger, sämtliche Aspekte des Designs, der Entwicklung und der Bereitstellung Ihrer Website zu optimieren, um Ihren Nutzern unabhängig vom verwendeten Gerät ein gutes Erlebnis zu bieten. Es ist hinreichend belegt, dass sich die Ladezeit einer Seite auf das Nutzererlebnis und den Umsatz auswirkt.

Google PageSpeed ist eine Sammlung von Tools zur Messung und Optimierung der Performance Ihrer Website und steht seit mehreren Jahren als Drittanbietermodul zur Verfügung, das Sie in NGINX Open Source einkompilieren können. Mit der Einführung von dynamischen Modulen in NGINX Plus R11 können nun auch NGINX Plus-Benutzer die Vorteile von PageSpeed nutzen.

Wenn Sie PageSpeed als dynamisches Modul in NGINX Plus laden, schreibt es die Ressourcen auf Ihrer Website automatisch um und optimiert sie. In diesem Blogbeitrag erklären wir, wie Sie das dynamische Modul erstellen und konfigurieren. (Beachten Sie, dass PageSpeed als Drittanbietermodul nicht durch Ihren Supportvertrag für NGINX Plus abgedeckt ist.)

PageSpeed als dynamisches Modul für NGINX Plus erstellen und laden

Die folgenden Anweisungen basieren auf der Anleitung von Google zur manuellen Installation und wurden für die Binärkompatibilität mit NGINX Plus angepasst. (Sie können die Anleitung von Google unverändert verwenden, um ein dynamisches Modul zu erstellen, das mit NGINX Open Source funktioniert.)

Schritt 0: Vorbereiten der Build-Umgebung

Wir empfehlen dringend, dynamische Module auf einem separaten System zu kompilieren, das wir hier als „Build-Umgebung“ bezeichnen. Dadurch werden das Risiko und die Komplexität des Systems minimiert, auf dem Sie NGINX Plus mit dem PageSpeed-Modul ausführen möchten (dieses bezeichnen wir als „Produktivumgebung“). Die Build-Umgebung muss dasselbe Betriebssystem und dieselbe Version wie die Produktivumgebung aufweisen; außerdem müssen die folgenden Komponenten installiert sein:

  • UnZip-Dienstprogramm
  • Compiler und Make-Dienstprogramm
  • Bibliothek für Perl-kompatible reguläre Ausdrücke (Entwicklungsdateien)
  • Zlib-Komprimierungsbibliotheken (Entwicklungsdateien)

Führen Sie den folgenden Befehl aus, um sicherzustellen, dass diese Voraussetzungen in Ihrer Build-Umgebung installiert sind.

  • Für Ubuntu/Debian:
$ sudo apt-get install unzip gcc make libpcre3-dev zlib1g-dev
  • Für CentOS/RHEL/Oracle Linux:
$ sudo yum install unzip gcc make pcre-devel zlib-devel

Schritt 1: NGINX Open Source beziehen

  1. Führen Sie in der Produktionsumgebung den folgenden Befehl aus, um die Version von NGINX Open Source zu ermitteln, die der ausgeführten NGINX Plus-Version entspricht. In dieser Ausgabe ist sie orange hervorgehoben: NGINX 1.11.5, entsprechend NGINX Plus R11.
$ nginx -vnginx version: nginx/1.11.5 (nginx-plus-r11)
  1. Laden Sie in der Build-Umgebung die Quelldateien für die entsprechende Version von NGINX Open Source herunter.
$ wget -qO - http://nginx.org/download/nginx-1.11.5.tar.gz | tar zxfv -

Schritt 2: Herunterladen und Vorbereiten der PageSpeed-Quelldateien

Führen Sie diese Schritte in der Build-Umgebung aus.

  1. Ermitteln Sie die neueste Versionsnummer des PageSpeed-Moduls in den Versionshinweisen, oder führen Sie dazu diesen Befehl aus.
$ curl -sS https://modpagespeed.com/doc/release_notes | grep release_ | head -1 | sed -e "s/^.*release_([0-9.]*)-beta.*/1/"
  1. Die PageSpeed-Versionsnummer wird in den Build-Befehlen mehrfach verwendet. Legen Sie sie daher als Umgebungsvariable NPS_VERSION fest. Geben Sie nur den numerischen Teil der Versionszeichenfolge an, nicht das Suffix „‑stable“ oder „‑beta“.
$ NPS_VERSION=numeric-part-of-version-string
  1. Laden Sie die Quelldateien wie folgt herunter und entpacken Sie sie. Beachten Sie, dass diese Befehle nacheinander wie ein Skript ausgeführt werden müssen.
wget https://github.com/pagespeed/ngx_pagespeed/archive/v${NPS_VERSION}-beta.zip unzip v${NPS_VERSION}-beta.zip cd ngx_pagespeed-${NPS_VERSION}-beta/ psol_url=https://dl.google.com/dl/page-speed/psol/${NPS_VERSION}.tar.gz [ -e scripts/format_binary_url.sh ] && psol_url=$(scripts/format_binary_url.sh PSOL_BINARY_URL) wget ${psol_url} tar -xzvf $(basename ${psol_url}) # extracts to psol/

Schritt 3: Kompilieren des dynamischen PageSpeed-Moduls

  1. Kompilieren Sie in der Build-Umgebung das dynamische PageSpeed-Modul, indem Sie zunächst das NGINX-Skript configure mit dem Argument --with-compat ausführen, um das dynamische Modul binärkompatibel mit NGINX Plus zu machen. Führen Sie anschließend make modules aus, um nur das Modul zu kompilieren.
$ cd ../nginx-1.11.5$ ./configure --add-dynamic-module=../ngx_pagespeed-${NPS_VERSION}-beta --with-compat
$ make modules
  1. Beim Build-Prozess wird das dynamische Modul unter objs/ngx_pagespeed.so erstellt. Kopieren Sie die .so-Datei aus der Build-Umgebung in das Modulverzeichnis /etc/nginx/modules der Produktionsumgebung. Wir empfehlen, die Datei beim Kopieren so umzubenennen, dass der Versionsnummer von NGINX Open Source enthalten ist (der folgende Schritt setzt dies voraus), zum Beispiel ngx_pagespeed_1.11.5.so.
  2. Erstellen Sie in der Produktionsumgebung einen symbolischen Link zwischen dem Dateinamen mit Versionsnummer und dem allgemeinen (ursprünglichen) Dateinamen.
$ cd /etc/nginx/modules$ sudo ln -s ngx_pagespeed_1.11.5.so ngx_pagespeed.so
$ ls -gG
-rw-r--r-- 1 11924784 Feb  6 11:52 ngx_pagespeed_1.11.5.so
lrwxrwxrwx 1       23 Feb  6 11:52 ngx_pagespeed.so -> ngx_pagespeed_1.11.5.so

Schritt 4: Laden des dynamischen PageSpeed-Moduls

Führen Sie diese Schritte in der Produktionsumgebung aus.

  1. Fügen Sie die Direktive „load_module“ ein, um PageSpeed als dynamisches Modul zu laden. Die Direktive muss im übergeordneten Kontext („main“) der Konfigurationsdatei nginx.conf stehen (also nicht in den Kontexten http oder stream).
load_module modules/ngx_pagespeed.so;
  1. PageSpeed selbst wird im http-Kontext konfiguriert. Fügen Sie diese Direktiven daher in eine neue Konfigurationsdatei namens pagespeed.conf im Verzeichnis /etc/nginx/conf.d ein. PageSpeed wird für die Website aktiviert, die in der Direktive proxy_pass angegeben ist, hier http://www.example.com.
pagespeed MessageBufferSize 10240;
pagespeed FileCachePath /var/ngx_pagespeed_cache;

server {
    listen 80;
    location / {
        proxy_pass http://www.example.com; 
    }
    pagespeed on;
}
  1. Laden Sie NGINX Plus neu, um das PageSpeed-Modul in die laufende Instanz zu laden.
$ sudo nginx -s reload

Testen des NGINX Plus PageSpeed-Moduls mit PageSpeed Insights

PageSpeed Insights ist ein eigenständiges Tool von Google, mit dem sich der Optimierungsgrad einer Webseite sowohl für Mobilgeräte als auch für Desktop-Computer messen lässt. Es vergibt für beide Gerätetypen eine Bewertung und gibt Empfehlungen, wie sich die Ladezeit der Seite verkürzen lässt. Das Tool eignet sich zur Bewertung Ihrer Website und zur Veranschaulichung der Wirksamkeit des PageSpeed-Moduls.

Mit PageSpeed Insights können Sie die Bewertung Ihrer Website und die Optimierungsvorschläge mit und ohne aktiviertem PageSpeed vergleichen. Wechseln Sie zwischen den Direktiven „pagespeed on;“ und „pagespeed off;“, um die Wirksamkeit des PageSpeed-Moduls auf Ihrer Website zu messen.

PageSpeed wendet seine Optimierungen ohne weitere Konfiguration oder Feinabstimmung an. Wenn Sie jedoch mehr Kontrolle darüber haben möchten, welche Optimierungen auf Ihrer Website durchgeführt werden, lesen Sie die PageSpeed-Dokumentation.

Testen Sie PageSpeed mit NGINX Plus selbst – starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.


Teilen

Über den Autor

Liam Crilly
Liam CrillySenior Director, Produktmanagement

Weitere Blogbeiträge von Liam Crilly

Ähnliche Blogbeiträge

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
NGINX | 23.08.2022

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln

Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
NGINX | 08.09.2021

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen

Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
NGINX | 16.08.2021

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet

Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
NGINX | 12.12.2018

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77

Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.

Ankündigung von NGINX Plus R16
NGINX | 05.09.2018

Ankündigung von NGINX Plus R16

NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
NGINX | 13.10.2016

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing

Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.