Сышышь ты, выходи сюда,
поговорим !

Usuń AMP i nie wpływa na ocenę SEO, Organic Traffic, Performance

  1. Usuwanie AMP
  2. SEO i organiczne wyniki ruchu związane z usuwaniem AMP
  3. Wstępnie pobieraj strony internetowe, aby uzyskać natychmiastowe wrażenia podczas przeglądania
  4. Testowanie doświadczenia użytkowników mobilnych
  5. Ustaw HSTS
  6. Buforuj wszystko za pomocą Cloudflare CDN
  7. Zoptymalizuj ładowanie obrazów
  8. Wstępnie załadowana wersja o niskiej rozdzielczości
  9. Ponownie rozważ zależności
  10. Wartość a cena
  11. streszczenie

Kiedyś polecałem Strony Google AMP jako niezawodny sposób na zwiększenie oceny SEO witryny i organicznych użytkowników ruchu. Ostatnio usunąłem AMP z mojej strony. W tym wpisie na blogu opiszę, jak wpłynęło to na mój blog i kilka bardziej zaawansowanych technik optymalizacji wydajności sieci, których używam zamiast zastrzeżonego standardu, takiego jak Accelerated Mobile Pages.

Usuwanie AMP

Jak to zrobić

Nie będę wyjaśniać, dlaczego zdecydowałem się usunąć AMP z tego bloga. Krótko mówiąc, oferowali mobilnym użytkownikom zdegradowane doświadczenie i wymuszali zbyt wiele ograniczeń. Możesz sprawdzić Hacker News znaleźć całą nienawiść AMP, o której mogłeś myśleć.

Usunięcie AMP z twojej strony internetowej nie jest natychmiastowe i musi być wykonane ostrożnie, aby niczego nie zepsuć.

Musisz zacząć od skonfigurowania przekierowania z wersji AMP strony na standardową. W moim przypadku zostało to zrobione przy użyciu prostej dyrektywy NGINX:

lokalizacja ~ ^ / amp /(.*)$ {return 301 / $ 1; }

Upewnij się również, że masz poprawny rel = „kanoniczny” wskazujący na wersję strony AMP na oryginalną. Kiedy to działa, możesz usunąć rel = "amphtml" i zażądać ponownego indeksowania w konsoli wyszukiwania Google.

Po kilku dniach Twoje strony AMP zaczną znikać z mobilnego SERP.

SEO i organiczne wyniki ruchu związane z usuwaniem AMP

Strony AMP zostały usunięte z mojego bloga przez około miesiąc w momencie pisania tego postu. Powinno być wystarczająco dużo czasu, aby zobaczyć pewne skutki dla ruchu.

Nie zauważyłem negatywnego wpływu na pozycję SERP i organiczne liczby ruchu.

Czerwona kropka wskazuje datę usunięcia wsparcia AMP z tego bloga

Być może na blogu publikującym nowy artykuł co tydzień, potencjalne najlepsze miejsce na karuzelę nie ma większego znaczenia.

Pozwólcie, że opiszę kilka zmian, które wprowadziłem do tego bloga, aby zaoferować odwiedzającym równie płynne i przyjemne przeżycia, jak te reklamowane przez zwolenników AMP.

Wstępnie pobieraj strony internetowe, aby uzyskać natychmiastowe wrażenia podczas przeglądania

AMP są znane z szybkiego reagowania. Możesz zaimplementować podobny interfejs użytkownika na swojej stronie, używając dobrych znaczników HTML.

Każdy post na tym blogu prowadzi do poprzedniego i następnego. Używam następujących tagów linków do wstępnego ładowania zawartości HTML sąsiednich postów:

<link rel = "prefetch" href = "/ previous-post-url"> <link rel = "prefetch" href = "/ next-post-url">

Każda strona HTML waży około ~ 10 KB, więc nawet na urządzeniach mobilnych jest to znikoma przepustowość.

Na stronie głównej ze stronicowanym indeksem wszystkich moich postów domyślnie ładuję dwa pierwsze artykuły. Jeśli użytkownik zacznie przewijać w dół, dynamicznie wczytuję posty na blogu, gdy ich linki tytułowe stają się widoczne w rzutni i mogą zostać potencjalnie kliknięte. Można to osiągnąć, używając odrobiny wanilii JS zmieszanej z szablonami Jekyll:

(function () {var urls = [...] // URL załadowane przy użyciu szablonów Jekyll var preloadedUrls = [] preloadedUrls. push (urls [0]) preloadedUrls. push (urls [1]) var preload = function (url) {if (url === undefined) {return;} if (preloadedUrls. includes (url)) {return;} var preloadLink = dokument. createElement ("link"); preloadLink. setAttribute ("rel", "prefetch") ; preloadLink. setAttribute ("href", url); document. getElementsByTagName ("head") [0]. appendChild (preloadLink); preloadedUrls. push (url);} window. onscroll = function () {var preloadIndex = parseInt ( window. scrollY / 300) preload (urls [preloadIndex]);}}) ();

Zauważyłem, że wstępne ładowanie działa niezawodnie na przeglądarkach Chrome na komputery stacjonarne i Android. Oferuje natychmiastową nawigację, nawet jeśli połączenie jest złe. Niestety, nie wydaje się, aby miało to wpływ na iPhone, desktop Safari lub Firefox. Chrome jest najpopularniejszą przeglądarką, więc i tak jest to dobra wygrana.

Testowanie doświadczenia użytkowników mobilnych

Jeśli korzystasz z szybkiej sieci WIFI, możesz nie zauważyć poprawy oferowanej przez wstępne ładowanie. Możesz myśleć, że Twoja strona jest szybka, jeśli tylko uzyskasz do niej dostęp na komputerze stacjonarnym. Obecnie większość ruchu jest urządzeniami mobilnymi, a twórca strony internetowej powinien skupić się na oferowaniu im najlepszego doświadczenia podczas przeglądania.

używam Network Link Conditioner sprawdzić, jak moje witryny działają w złych warunkach sieciowych:

Jeśli chcesz budować szybkie strony internetowe, korzystaj z wolnego internetu

Ustaw HSTS

Z narzędziami takimi jak Szyfrujmy i Cloudflare oferując bezpłatne certyfikaty SSL / TLS nie ma powodu, dla którego jakakolwiek część witryny powinna być obsługiwana przez zwykły HTTP.

Dodanie nagłówka HSTS (HTTP Strict Transport Security) jest prostym sposobem uniknięcia niepotrzebnych przekierowań po stronie serwera, gdy użytkownik wprowadza adres URL Twojej witryny bezpośrednio do przeglądarki.

Bez nagłówka HSTS przekierowanie zostanie wykonane przy użyciu kodu HTTP 301, przekierowując wersję HTTP do HTTPS. Jeśli masz nagłówek HSTS na miejscu, przekierowanie zostanie wykonane po stronie klienta, zmniejszając jeden pełny obieg sieci, a tym samym poprawiając początkowe wrażenia użytkownika.

Dodatkowo możesz przesłać swoją stronę do Lista wstępnego ładowania HSTS aby użytkownicy byli domyślnie przekierowywani do wersji HTTPS, nawet jeśli nie odwiedzili jeszcze Twojej witryny.

Przeczytaj uważnie o konsekwencjach dodania nagłówka HSTS, ponieważ jest to podróż w jedną stronę i nie można go cofnąć.

Buforuj wszystko za pomocą Cloudflare CDN

Używam Cloudflare jako CDN dla tego bloga. Domyślnie buforuje tylko statyczne zasoby .

W takim przypadku każdy użytkownik musiałby pobrać stronę HTML z serwera VPS znajdującego się w USA. Oznacza to pełną podróż w obie strony do Stanów Zjednoczonych, niezależnie od ich położenia geograficznego, aby zobaczyć wszystko, co jest wyświetlane na ekranie.

Ten blog jest statyczną stroną internetową, więc prosta zmiana konfiguracji Cloudflare może znacznie poprawić wydajność sieci. Korzystając z tak zwanych reguł strony, możesz skonfigurować Cloudflare, aby buforował wszystko, w tym strony HTML, z uwzględnieniem odpowiadających im nagłówków wygaśnięcia pamięci podręcznej.

Nagłówki pamięci podręcznej Cloudflare i konfiguracja reguł strony

Aby to działało, używam następującej konfiguracji NGINX:

lokalizacja ~ * (?: ico | css | js | gif | jpe? g | png) $ {wygasa 8d; add_header Cache-Control „public”; try_files $ uri = 404; } location / {wygasa 15m; add_header Cache-Control „public”; try_files $ uri $ uri .html $ uri / /404.html; }

Mogę buforować statyczne zasoby przez 8 dni Statystyki strony Google szczęśliwy. używam jekyll-assets aby dodać skrót md5 do nazwy pliku na podstawie zawartości, więc nieaktualna pamięć podręczna nie stanowi problemu.

Po każdym wdrożeniu uruchamiam następujący skrypt Ruby, który usuwa bufory Cloudflare dla statycznych stron HTML:

require 'sitemap-parser' wymaga odpowiedzi „http” = HTTP. nagłówki („X-Auth-Email” => ENV. fetch („CLOUDFLARE_EMAIL”), „X-Auth-Key” => ENV. fetch („CLOUDFLARE_API_KEY”), „Content-Type” => „application / json” ). post ("https://api.cloudflare.com/client/v4/zones/ # {ENV. fetch ('CLOUDFLARE_ZONE_ID')} / purge_cache", json: {pliki: SitemapParser. new ("./docs/sitemap. xml "). to_a})

Oznacza to, że każdy użytkownik zachowa kopię stron HTML w swojej lokalnej pamięci podręcznej przez maksymalnie 15 minut, a następnie zażąda aktualnej wersji z węzła serwera Cloudflare CDN.

Może to być mniej krytyczne w przypadku całkowicie statycznej strony internetowej. Zmniejszenie odległości w obie strony jest kluczowe, jeśli zawartość witryny jest dynamiczna.

Większość użytkowników tego bloga, botów lub nie, pochodzi ze Stanów Zjednoczonych

Niedawno przeprowadziłem migrację serwera VPS mojego projektu pobocznego Abot Slack Bot Do Stanów Zjednoczonych. Podczas gdy użytkownicy Abota są rozproszeni po całym świecie, sam bot się łączy Slack API Serwery oparte na USA dla każdego pojedynczego polecenia. Skrócenie odległości w obie strony po stronie zaplecza znacznie poprawiło czasy odpowiedzi.

Zoptymalizuj ładowanie obrazów

Wyświetl symbol zastępczy

Dodaję obraz na górze każdego posta na blogu. W wolniejszych sieciach wysokiej jakości wersja obrazu może zająć dużo czasu, aby załadować i zepsuć wrażenia.

Jeśli znasz proporcje swoich zdjęć, możesz użyć prostej sztuczki CSS, aby zapobiec „przeskakiwaniu” otaczającej zawartości, gdy obraz zostanie ostatecznie załadowany:

<div class = "main-image-placeholder"> <img src = "/images/image.jpg"> </div> .main-image-placeholder {position: relative; padding-bottom: 61%; / * stosunek wysokości obrazu do szerokości * / wysokość: 0; przepełnienie: ukryte; kolor: #eee; kolor tła: #eee; } .main-image-placeholder img {position: absolute; top: 0; po lewej: 0; szerokość: 100%; }

Wyświetli pusty szary symbol zastępczy o prawidłowym rozmiarze, niezależnie od rzutni odwiedzającego przed załadowaniem obrazu.

Wstępnie załadowana wersja o niskiej rozdzielczości

Kolejną optymalizacją, którą możesz zastosować, jest wyświetlenie wersji obrazu w niskiej rozdzielczości przed pobraniem oryginalnej wersji. Można to osiągnąć za pomocą odrobiny waniliowego kodu JavaScript.

(function () {Array. prototype. slice. call (document. getElementsByClassName ('js-async-img')). forEach (funkcja (asyncImgNode) {var fullImg = new Image () fullImg. src = asyncImgNode. dataset. src ; fullImg. onload = function () {asyncImgNode. classList. remove ('js-async-img') asyncImgNode. src = asyncImgNode. dataset. src};});}) ();

Odpowiadający węzeł HTML img:

<img class = "js-async-img" data-src = "https://example.com/assets/high-res-image.png" src = "https://example.com/assets/low-res -image.png ">

45 kb Elk vs 4 kb Elk

Ponownie rozważ zależności

Przedawkowanie zewnętrznych bibliotek JavaScript innych firm jest najprostszym sposobem na zniszczenie wydajności witryny. Standard AMP nie pozwala na ich uwzględnienie. Chciałbym zaproponować podejście pośrednie.

Wpadnięcie w kolejny <skrypt src = "..."> może nie wydawać się wielką sprawą. Łatwo zapomnieć, że jeden znacznik skryptu może spowodować kaskadę żądań, w tym więcej skryptów i zasobów. Spójrzmy na koszt osadzania przykładowych bibliotek JavaScript innych firm:

Jak widać SUMO jest zaskakująco ciężkie. Używałem go przez jakiś czas, ponieważ naprawdę podobał mi się ich responsywny plugin społecznościowy. Później zaimplementowałem go od nowa.

3 MB i 16 żądań vs. dwie tuziny linii HTML + CSS

W końcu zdecydowałem, że Disqus jest jedyną ciężką biblioteką JavaScript dla firm zewnętrznych, która oferuje wystarczającą wartość, aby umieścić ją na tym blogu. Może gdybym używał pełnoekranowych wyskakujących okienek SUMO i innych narzędzi do konwersji, warto dodać te 3 MB przepustowości.

[Aktualizacja] Przeprowadziłem migrację mojego systemu komentarzy na lekki Commento .

Wartość a cena

Chodzi mi o to, że bardzo łatwo jest przeoczyć cenę wydajności obejmującą zależności JavaScriptu, a tym samym psuć wrażenia użytkownika podczas przeglądania.

Myślę, że chodzi o to, ile wartości oferuje narzędzie w porównaniu z kosztami żądań i przepustowości. Na przykład postanowiłem osadzić Ostry czat na Abot landing page . Obsługa czatu na miejscu znacznie poprawia wrażenia użytkowników / klientów Abot i nie kosztuje wiele pod względem wydajności.

Przeciwstawienie 8 dodatkowych żądań i prawie 200 kb interaktywnego przycisku śledzenia na Twitterze nie wydaje się dobrym kompromisem.

Wnioski wydawane po włączeniu biblioteki JavaScript Sumo

Upewnij się, że wyłączasz śledzenie plików cookie i linki afiliacyjne w panelu administracyjnym Disqus, aby zmniejszyć liczbę żądań:

streszczenie

Nie sądzę, by golenie się przez kilkaset milisekund od czasu załadowania strony internetowej mogło spowodować lub przerwać działalność w Internecie, ale zbyt wiele stron internetowych jest nadęty z niepotrzebnym JavaScriptem i zasobami. Oferowanie użytkownikom płynniejszego przeglądania może być przewagą konkurencyjną.

Zaimplementowałem wszystkie optymalizacje opisane powyżej w moim Szablon SEO Jekyll . Możesz pobrać to za darmo. Jest to standardowa uczta dla sub-maila.

Nadal jestem w trakcie tworzenia tego bloga jako najbardziej wydajnego. Jeśli zauważysz jakieś ulepszenia, które mogą zostać tutaj zastosowane, zostaw komentarz. BTW mogę bardzo polecić czytanie Wysokowydajna sieć przeglądarek Ilya Grigorik, która była inspiracją dla wielu optymalizacji, o których piszę. Możesz również sprawdzić mój poprzedni post, aby uzyskać więcej Optymalizacja SEO i wskazówki dotyczące wydajności sieci .

Ico | css | js | gif | jpe?