image

AMP — наверняка, вы уже слышали об этой технологии, продвигаемой Google. Казалось бы, еще одна модная технология для хипстеров, о которой скоро все забудут. Однако, в реальности эта фича уже работает в продакшне значительного числа новостных сайтов, среди которых такие гиганты, как the Guardian, Times, Washington Post, и прочая, прочая, прочая. Краткий рассказ о плюшках AMP уже был на страницах “Хабра”, а я хотел бы чуть более подробно сфокусироваться на том, как внедрять это в проект, и какой профит в действительности можно получить.


Очень кратко об том, как это работает


AMP — это технология, которая позволяет ускорить загрузку мобильных страниц. По своей сути это тот же самый HTML, но не просто HTML, а хитро оформленный по специальным правилам. Отрисовка страницы осуществляется при помощи специального скрипта (AMP runtime), который берёт на себя оптимизацию рендеринга.

Выполнение прочих скриптов на странице запрещено, чтобы своими изменениями DOM’а они не мешали нам оптимизировать. Это не значит, что на ваших страницах не будет интерактивности. Её можно сделать, но опять-таки по специальным правилам (наприме, в специальном компоненте).
Кроме того, гугл бот при парсинге обнаруживает AMP страницы, кеширует их содержимое и в дальнейшем будет отдавать их быстрее.

В выдаче Google AMP-ресурсы видны в специальной карусели в верхней части страницы.



Если же говорить об автоматическом редиректе на amp-версию при прямом заходе по ссылке, то поддержка браузерами amp-страниц и автоматический переход на них пока еще не реализована, а только ожидается. AMP хорош именно для контентных страниц, где нет значительного количества поведенческих скриптов (впрочем, различную интерактивную инфографику, мини-игры и т.п. мы можем реализовать внутри iframe).

Всё вышеперечисленное привело нас к намерению сделать AMP у себя. И вот как это было:

Шаг 1 — создаем новые шаблоны


На бэкенде мы используем Rails, в качестве шаблонизатора — Slim. Первым делом мы создаем новые пути в routes.rb для интересующих нас сущностей (в данном случае это будут новость и статья — основной контент нашего сайта). Принципиально не важно, какой именно адрес будет у amp — версии страниц — это может быть как поддомен amp.youpage.com/article, так и, например, youpage.com/article/amp, лишь бы схема была единообразной.

Затем мы создаем новые шаблоны для рендеринга AMP- версии наших страниц, и смело удаляем из них все лишнее.

Под лишним подразумеваются следующие вещи:
— Javascript-код
— Inline-стили
— Запрещенные в amp-html теги, как-то: object, frame, embed, select, form, input, option, textarea (впрочем, насчёт input спецификация еще может поменяться — следите за развитием проекта.)

В общем, надо выпилить всё, что усложняет рендеринг страницы или же может его блокировать.

def amp_strip_tags(text = '')
    text
      .gsub(%r{<img(.+?)\/>}, '')
      .gsub(%r{<iframe.+?\/iframe>}m, '')
      .gsub(%r{<script.+?<\/script>}m, '')
end


Особое внимание хотелось бы уделить head наших страничек. Он должен иметь достаточно явно определенную структуру, вот такую:

Простыня html
  <meta charset="utf-8">
  <title>...</title>
  <meta name=“viewport" content=”width=device-width,minimum-scale=1,initial-scale=1”
  <link rel="canonical" href="{ссылка на полную версию}" />
  <style amp-custom>{пользовательские стили}</style>
  <!-- Микроразметка -->
  <script type="application/ld+json">{...}</script>
  <!-- Предотвращение FOUC -->
  <style amp-boilerplate>
    body{
      -webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;
      -moz-animation: -amp-start 8s steps(1,end) 0s 1 normal both;
      -ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;
      animation:-amp-start 8s steps(1,end) 0s 1 normal both;
    }

    @-webkit-keyframes -amp-start{
      from{
        visibility:hidden
      }to{
        visibility:visible
      }
    }

    @-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}

    @-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}

    @-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}

    @keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}

  </style>
  <noscript>
    <style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style>
  </noscript>
  <script async src="https://cdn.ampproject.org/v0.js"></script>

  {amp-components scripts}
 


Обратите внимание, что все скрипты подключаются с атрибутом async.

Шаг 2 — Перелопачиваем стили


В зависимости от реализации, мы можем сделать AMP-версию максимально похожей на обычную мобильную, или же полностью редизайнить её. Мы выбрали первый путь. Итак, для процессинга CSS мы используем Stylus, и БЭМ-style нэйминг. На мобильной версии мы имеем примерно такой набор файлов:

Длинный список


Очевидно, что часть из них нам не потребуется. Поэтому в таблицу стилей для AMP войдут не все, а кроме того, вероятно, нам потребуются кое-какие исправления.
В частности, внутри стилей нельзя применять:
— Универсальный селектор * и :not()
— overflow: scroll, overflow: auto (нельзя делать скроллящиеся блоки)
— filter
— !important

Такой у нас получается корневой amp.styl:
@import 'reset'
@import 'variables'
@import 'mixins'
@import 'fonts'
@import 'general'
@import 'amp/icons'
@import 'amp/blocks/**/*.styl'
@import 'elements/button'
_apply_media_cache()

Избавившись от вышеперечисленного, и подправив стилевое оформление нужным образом, получившиеся стили надо вывести внутри получившейся страницы. Сборщик у нас webpack, и получившийся css — файл мы вставляем в шаблоне через такой хелпер:

def amp_stylesheet_content
    css_file_path = Rails.root.join('public').to_s + URI(stylesheet_path('amp.css')).path
    File.read(css_file_path)
end


Внутри head:

<style amp-custom>
  =amp_stylesheet_content.html_safe
</style>


(В данном случае мы используем raw html, так как slim не умеет при стандартных настройках создавать атрибуты без значения)

При этом важно, чтобы размер стилевого файла не превысил 50 кБ. В общем-то этого достаточно, к тому же не забываем о минификации. У нас стили заняли 35 кБ.

Шаг 3 — Медиа-контент должен быть внутри AMP-компонентов


В основном медиаконтент новостного сайта можно разделить на 4 категории:
— Изображения (возможно, серии изображений — галереи)
— Видео
— Виджеты социальных сетей
— Специальные интерактивы (например, мини-игры, инфографика и тому подобное)

Для того, чтобы выводить всё это, в AMP предусмотрены различные компоненты.

Итак: для изображений у нас есть очень похожий на HTML5 picture amp-img:

<amp-img alt="Екатерина Проничева" width="420px" height="280px" src="http://icdn.lenta.ru/images/2016/02/11/12/20160211121428311/pic_8dc2c0121a05e635e509d1981d4fda63.jpg" layout="responsive"></amp-img>


А также amp-carousel (годится не только для изображений, но и для прочего контента)

<amp-carousel width=300 height=400>
  <amp-img src="my-img1.png" width=300 height=400></amp-img>
  <amp-img src="my-img2.png" width=300 height=400></amp-img>
  <amp-img src="my-img3.png" width=300 height=400></amp-img>
</amp-carousel>


и amp-lightbox (обычный лайтбокс)

<button on="tap:my-lightbox">Хочу увидеть всё!</button>

<amp-lightbox id="my-lightbox" layout="nodisplay">
  <div class="lightbox">
    <amp-img src="my-full-image.jpg" width=300 height=800 on="tap:my-lightbox.close">
  </div>
</amp-lightbox>


Для видео — amp-video

<amp-video width=400 height=300 src="https://supervideo.com/videos/myvideo.mp4"
    poster="fallback-poster.jpg">
  <div fallback>
    <p>Ooops! Sorry, your browser doesn’t support HTML5 video!</p>
  </div>
  <source type="video/mp4" src="foo.mp4">
  <source type="video/webm" src="foo.webm">
</amp-video>


И разнокалиберный набор виджетов для популярных социальных сетей ( к сожалению, среди них пока отсутствует VK.)

Для замены удобно использовать свой хелпер:

def amp_img(cloud_unit, version, params={})
    if cloud_unit.versions.present? && cloud_unit.versions[version.to_s].present?
      version = cloud_unit.versions[version.to_s]

      if cloud_unit.caption.present?
        alt = cloud_unit.caption
      elsif cloud_unit.alt.present?
        alt = cloud_unit.alt
      else
        alt = ''
      end

      attrs = {
        alt:  strip_tags(alt),
        width: version.width.to_s + 'px',
        height: version.height.to_s + 'px',
        src: cloud_url(version.rel_url),
        class: params[:addclass],
        layout: params[:layout]
        #sizes: "(min-width: 650px) 50vw, 90vw"
      }
      content_tag('amp-img', nil, attrs)
    end
  end


Для того, чтобы редактору было удобно работать с контентом, в админке имеются т.н. “виджеты” — боксы, куда можно вставлять по выбору различный контент. Например, для вставки -instagram или -facebook поста редактору достаточно вставить ссылку на него, из которой затем формируется полноценный код виджета. Нам необходимы новые view для виджетов amp-версии, что достаточно просто — вытащенные регуляркой значения (например, код youtube-ролика) подставляются в шаблон соответствующего amp-компонента, который затем выводится на странице.

Кроме того, необходимо подключить библиотеки требуемых компонентов внутри head.

Важный момент, на котором стоит заострить внимание — для ускорения рендеринга размеры медийных элементов должны быть определены заранее, поэтому мы устанавливаем явно ширину и высоту (реальную) для изображений и виджетов.

Если мы хотим внедрить в страницу какой-то совсем специальный контент, то мы можем воспользоваться amp-iframe и реализовать в нём любое, самое причудливое поведение, не будучи ограниченными в использовании js.

Есть ряд ограничений на его использование — например, контент внутри amp-iframe может сервиться только через https, кроме того, amp-iframe не должен располагаться, в первом экране. Ну, и конечно, содержимое не может обращаться к DOM страницы, и тем более как-то его изменять. Все, что происходит в песочнице — останется в песочнице.
Загрузка элементов происходит асинхронно, так что, скорее всего, при плохом коннекте вы сначала не увидите их содержимого, а только placeholder (который, кстати можно кастомизировать или же вообще отключить). Зато после того, как контент загрузится, он станет виден безо всякого FOUC!
Вместо виджетов социальных кнопок приходится применить обычный noscript-вариант. Вот, например, для VK:

.b-socials__button
        a.b-socials__image.b-socials__image-vk href="http://vk.com/share.php?url=#{extlink}" target='_blank' title=("Поделиться ссылкой во Вконтакте")


Шаг 4 — Микроразметка


Для AMP-страниц Google настоятельно требует введение микроразметки. На самом деле, значительная часть сайтов уже использует такую разметку, если же у вас ее пока нет — то самое время начать!
В качестве словаря используется schema.org, в данном случае — под наши цели отлично подходит сущность NewsArticle. Вставить разметку в страницу можно при помощи JSON-LD (на мой взгляд, наиболее удобный способ) или используя microdata — специальные атрибуты, устанавливающиеся для тегов с определённым контентом. Все необходимые данные для этого, скорее всего, у вас уже есть, и остается только подставить их в шаблон.

Шаг 5 — Аналитика и реклама


Как вы, вероятно, замечали, любой крупный проект начинает обрастать различными счетчиками и метриками, как корабль — морскими ракушками, с аналогичным действием — замедляет его. Для того, чтобы как-то бороться с этим нежелательным явлением, мы можем применить компонент amp-pixel, который, как ясно из названия, предоставляет функционал обычного счетчика — отправляет запрос на указанный адрес при показе страницы.

<amp-pixel src="https://foo.com/pixel?RANDOM"></amp-pixel>


Очень удобно — вместо RANDOM будет подставляться рандомное число.
Также есть нативный компонент Google Analytics — amp-analytics

<amp-analytics id="analytics1" type="googleanalytics"><script type="application/json">{
  "vars": {
    "account": "UA-*******"
  },
  "triggers": {
    "trackPageview": {
      "on": "visible",
      "request": "pageview"
    }
  }
}</script></amp-analytics>


В принципе, мы решили, что стоит заменить гору счетчиков одним Google Analytics, однако если для вас этот вариант непозволителен, то возможности есть.

Что касается рекламы, то в текущий момент поддерживаются в основном системы доставки рекламного контента, распространенные в США. Чтобы подружиться, например, с adFox, можно сделать вот что: получить ссылку на содержимое баннера и разместить ее внутри amp-iframe заданного размера. Таким образом, реклама придет асинхронно и никогда не сможет помешать загрузке странички.

В рамках нашего проекта рекламу в AMP мы пока не внедряли. Наслаждайтесь свободой :)

Шаг 6 — Проверяем, все ли у нас хорошо


После того, как вы успешно собрали ваши AMP-версии страниц, необходимо проверить, все ли соответствует спецификации, чтобы поисковый бот Google обрабатывал их и включал в поисковую выдачу.

Во-первых, прямо на локальной машине или dev-сервере можно открыть проверяемую страничку с хэш-параметром #development=1, а затем заглянуть в developer console.

Если все OK, вы увидите примерно такое сообщение:



Если же нет, встроенный валидатор покажет, где обнаружены ошибки, и даже приведёт ссылки на документацию:



После того, как вы выкатились в production, загляните сюда, и проверьте, что microdata парсится нормально и имеет необходимые поля.

Кроме того, в инструментах вебмастера Google вы можете найти вкладку “Страницы для мобильных устройств”, где собирается статистика по проиндексированным страницам, там вы сможете найти в удобном виде статистику и информацию об ошибках по всему сайту, если таковые появятся, но будьте внимательны — индексирование происходит довольно нечасто (раз в несколько дней), так что после внесения изменений придется подождать.

Замеры скорости


Скорость загрузки amp-версий страниц значительно выше, притом, чем хуже качество соединения, тем более заметна разница. В целом, можно говорить о как минимум 2х-кратном росте скорости загрузки. Сравним при помощи tools.pingdom.com показатели обычной мобильной странички:



и amp-версии:



Разница, как говорится, налицо. Особенно интересно рассмотреть waterfall загрузки ресурсов и сравнить (эту задачу оставлю для интересующихся читателей).

Для подробностей в нюансах рекомендую посмотреть официальный github проекта и документацию.

Комментарии (52)


  1. SerafimArts
    31.03.2016 14:37

    Я так понимаю — это тот доклад, что ещё предстоит вам рассказывать через 4 часа на MoscowJS? Эх, всю интригу попортили =(
    Но всё равно спасибо.


    1. ianbrode
      31.03.2016 14:50

      доклад будет читать Максим Фролов, и контент его доклада будет отличаться)


  1. achekalin
    31.03.2016 15:06
    +12

    Скажите, а нельзя ли на мобильной Ленте сделать заранее заданными размеры рекламы вверху страниц? Мало того, что реклама бывает навязчивой, так она грузится после страницы, и вот вроде страница прогрузилась, и только ты думаешь тыкнуть в ссылку на экране — в этот момент контент прыгает вниз на неизвестное расстояние (высота баннера), и ты попадаешь пальцем в баннер или в другую ссылку.

    После такого невольно начинаешь искать способы баннеры не грузить, поскольку они серьезно мешают основной функцией Ленты пользоваться.


    1. andvgal
      31.03.2016 19:29
      +2

      Я всегда считал это гениальным способом увеличения дохода, т.к. большое количество пользователей тыкает во внезапно появившийся баннер вместо одной из последних новостей. Даже не удивлюсь, если да задержка искусственная.


      1. achekalin
        31.03.2016 23:04
        +2

        Увы, но вы, думаю, правы: уж очень у команды Ленты, судя по рассказу в посте, все продумано, чтобы забыть такую «мелочь».

        Кстати, Хабр ведет себя точно так же, притом и в мобильной версии, и в десктопной. На мобилке в центре списка постов «внезапно» появляется баннер на полэкрана, у настольной постоянно вверху прыгают глоки с рекламой.

        P.S. Наверное, нет нужды говорить, что adblock воспринимается после такого вовсе не как «грабитель обездоленных владельцев сайтов», а просто как что-то, что дает сайты читать, не пребывая в постоянном стрессе от боязни не туда нажать или не то выбрать? )

        P.P.S. А за «клюкву» в стиле «показывать только хорошие новости» хочется маркетологам руки оборвать. Маму или не маму за деньги продать — не знаю, что они готовы, но на новостном сайте в угоду рекламе изменять подачу материала… Это непрофессионально, минимум. Конечно adblock-чить такое!


        1. muon
          04.04.2016 13:23

          Вот чего я не могу понять: неужели браузер считает, что клик по элементу через 50 мс после его отображения — это то, что я действительно имел в виду? Почему бы разработчикам не сделать элемент некликабельным некоторое время после его отображения или перемещения?


          1. achekalin
            04.04.2016 13:30

            Ну мы тут доходим до того, чтобы железка за нас считала, что нам надо :)

            Но, правда, при таком размахе применения adblock-ов, и при такой конкуренции СМИ, даже странно, что баннеры так глупо лепят — ведь пара таких «промашек мимо ссылки», и человек думает. что делать с рекламой.


  1. mrsum
    31.03.2016 15:25
    +34

    У нас было 2 версии сайта, 75 сторонних рекламных скриптов, 5 скриптов метрик, пол-солонки БЭМа и целое множество запросов от бизнеса всех сортов и расцветок, а также легаси, рефакторинг, ящик ошибок, пинта чистого энтузиазма и безрезультатные усилия. Не то что бы это был необходимый запас для проекта. Но если начал собирать проект, становится трудно остановиться. Единственное что вызывало у меня опасение — это легаси. Нет ничего более беспомощного, безответственного и испорченного, чем легаси. Я знал, что рано или поздно мы перейдем и на эту дрянь.


  1. Gorky
    31.03.2016 15:42
    +8

    Ну так это… я видимо чего-то не понимаю. Если из стандартной версии убрать все скрипты, стили, картинки и тд, как вы сделали с АМР — то и получится то же самое. И без всякого АМР. Нет?


    1. ianbrode
      31.03.2016 15:50

      полностью убрали только скрипты. стили и картинки были переоформлены и урезаны по правилам amp. по сути amp — это набор правил + конструктор, состоящий из готовых оптимизированных виджетов. плюс кеширование, скорость отдачи и приоритет в выдаче гугла.


      1. MrGobus
        31.03.2016 17:44
        +3

        goto Gorky; // infinty loop here

        Признаться честно, читая первые абзацы статьи тоже думал, что amp загрузит быстрее мою страницу а не предложит делать рефакторинг кода. Но как оказалось, чудес не бывает.


    1. Lockal
      31.03.2016 23:28
      +1

      А теперь разгадка. При переходе по AMP-ссылке с мобильного устройства гугл загружает (и предзагружает) всю информацию не с лента.ру, а со своего cdn. Пример ссылки: https://www.google.ru/amp/s/m.lenta.ru/news/2016/03/31/twentymillions/amp/. Ссылка открывается только с юзерагентом мобильного устройства, а на десктопе перенаправляется на лента.ру.

      Плюсы:

      1. не надо открывать http(s)-соединение
      2. этот cdn очень быстрый
      3. сервера гугла могут пересжимать шрифты, скрипты и картинки
      4. привет роскомнадзору

      Минус: фактически, сайты на amp дарят весь контент гуглу. Это чем-то напоминает ситуацию с новостными агрегаторами, но последние обычно показывают только часть контента и дают ссылку на оригинал, а с amp 100% запросов идут на гугл.


      1. Methos
        04.04.2016 22:10

        По сути, AMP — это просто как кеширующий прокси.
        Ничего волшебного.


  1. ReZOH
    31.03.2016 16:30

    Хотелось бы узнать, как это повлияет на посещаемость, показатель отказов и другие метрики (помимо скорости). Стоила ли игра свеч, так сказать.
    Планируется ли в будущем пост с аналитикой?


    1. ianbrode
      31.03.2016 16:34
      +1

      Да, в ближайшем будущем соберём данные и сопоставим изменения в посещаемости.


  1. roodz
    31.03.2016 16:46
    +3

    А можно с обычной ленты выкинуть криворукие баннеры, которые вешают Firefox?


  1. TimsTims
    31.03.2016 17:06
    +6

    > Page size: 8.8mb
    > Page size: 0.9mb
    1) Очень больно смотреть на страничку на 9мбайт…
    2) Сраниваются две версии страницы — одна на 8 мбайт и 438(!) запроса против 23 запросов на 900кбайт.
    А не очевидно ли, что если бы вы просто сократили бы количество подключаемого контента также в 20 раз, то у вас также выросла бы скорость загрузки страниц?

    Или это первоначальная прогрузка странички, и основной рендеринг всего остального происходит уже после 1.43s?

    Еще вопрос:
    Иногда бывает так, что выходишь в интернет из публичного места, например популярного кафе, и его IP много где забанен. И в таких неприятных случаях случается такое, что из-за подтягивания виджетов соц.сетей — загрузка страницы просто не происходит, т.к. ожидается загрузка скриптов с facebook, это не происходит, случается какая-то ошибка, сайт встает белым экраном и никакого тебе контента из-за твоего IP. Вы как-то прорабатываете такой кейс, когда тупо не отвечает соц.сеть? Ведь даже facebook раз в год падает…


    1. DenimTornado
      31.03.2016 17:34
      +1

      семь бед, один async


  1. crawlingroof
    31.03.2016 17:29

    Единственное что меня заставляет на телефоне использовать полную версию сайта на телефоне так это отсутствие кнопки «обсудить».
    Хотя раздел на сайте есть m.lenta.ru / comments*, а ссылки из новости на него нет.


  1. Denai
    31.03.2016 18:10
    +4

    Увидел как из страницы убрали мусор, не увидел где польза от AMP!
    Обычная мобильная страничка весом 8,8МБ это странновато, вам так не кажется?


    1. Per_Ardua
      01.04.2016 11:45

      Суть AMP не в сокращении веса и уменьшении количества запросов. За это отвечает оптимизация. Суть AMP — кеширование, и главное — выдача в Google. Одного этого достаточно для применения технологии.


      1. Denai
        01.04.2016 12:32

        Кеширование где?


        1. Per_Ardua
          02.04.2016 09:20

          Google кеширует AMP страницы, и после выдает их.
          Держи: https://www.ampproject.org/docs/get_started/about-amp.html#google-amp-cache
          https://support.google.com/webmasters/answer/6340290?hl=en


          1. Denai
            02.04.2016 15:22
            -3

            Спасибо, это будет интересней этой статьи почитать


            1. Denai
              02.04.2016 15:30

              Хотя нет, там никаких подробностей или я читаю не очень внимательно. Как можно в AMP влиять на кеширование? Что делать, если гугл закешировал что-то не то? Гугл кеширует только превьюшку, которую сам показывает, верно? Вот эту:
              image


              1. Lockal
                03.04.2016 14:14
                +1

                Гугл кэширует весь контент, включая скрипты, изображения и шрифты. Когда пользователь мобильного устройства нажимает на ссылку (как на вашем скриншоте), вопреки ожиданиям пользователя открывается кэшированная страница https://www.google.ru/amp/s/..., а не lenta.ru. Эдакий cloudflare поверх очень сильно прокачанного rss.


                1. Denai
                  03.04.2016 16:58

                  т.е. из выдачи гугла попадёте туда, из яндекса/бинга/напрямую — на обычную страницу, где кешированием управляете самостоятельно, из мобильных приложений — зависит от того кто их и как делал, верно? Или это какой-то стандарт и тот же твиттер тоже будет посылать на кешированную гуглом версию? Я не вижу подробного описания этой фичи, подскажите где оно.


  1. sefus
    31.03.2016 18:23
    +1

    У меня PageSpeed Insights Показывает 59/100 для главной страницы. Не похоже на скорость света


    1. ianbrode
      31.03.2016 18:30

      Главную не трогали, потому что контент динамически меняется. Amp хорош именно для контентных страницы.



    1. Denai
      31.03.2016 18:37
      +1

      PageSpeed Insights считает что все подключаемые скрипты и прочая лабуда важны на странице. Текст поста говорит об обратном. А оценка лишь показывает насколько этот мусор удобен для загрузки девайсами. Конкретно на примере соседнего вашего комментария: можно выиграть на сжатии JS около 55,8 КБ из 1.6MB общего веса. Это добавит 5 баллов, но поможет ли?


      1. sefus
        31.03.2016 18:42

        Я к тому, что раз уж решили разгонять, то можно было бы и неважные скрипты сократить в два раза.


        1. Denai
          31.03.2016 18:50

          Неважные скрипты можно бы и совсем убрать, но PageSpeed сотку всё равно не даст. tools.pingdom.com в данной ситуации более корректный инструмент т.к. показывает ещё и вес и число запросов, а не просто даёт рекоммендации. Я не говорю что гугл советует что-то плохое. Вы верно заметили что помимо лишнего кода на сайте ещё и неоптимизированный код есть, а также другие проблемы, с которыми следует бороться.
          Хорошая страничка после всех оптимизаций должна весить ~300КБ включая графику и набирать 80+ в том же PageSpeed. Но этого в посте нет и не планировалось.


  1. Al_Azif
    31.03.2016 18:37
    +7

    Скажите, а воровство контента с ютуба с приклеиванием «Lenta.ru» в первые 10 секунд у вас тоже автоматически?


  1. and7ey
    31.03.2016 20:09
    +9

    Это, конечно, все здорово. Но ленту кто-то еще читает?


    1. mezastel
      31.03.2016 21:24
      +2

      1. and7ey
        31.03.2016 21:25
        +1

        Медуза — это понятно. Но в статье-то речь про "новую" ленту.


    1. d1st
      31.03.2016 21:41
      +3

    1. Suvitruf
      31.03.2016 23:09

      Боты.


    1. exfizik
      01.04.2016 11:45
      +1

      А почему бы ее не читать?


      1. and7ey
        04.04.2016 19:59
        +1

        Вот как раз картинка в тему появилась. Интересно, про панамские офшоры вы что-нибудь уже слышали? (хотя мы уже в глубокий офтоп уходим)


  1. Hint
    01.04.2016 15:54

    Сделайте, пожалуйста, ссылку на комментарии в мобильной версии. И еще не обрезайте картинки в галереи в той же мобильной версии (лучше добавьте белые полосы, но не обрезайте головы людям).


  1. Lends
    02.04.2016 22:20
    +1

    AMP сильно упрощает жизнь тем, кто часто читает новости на мобилке не через приложения. Можно просто ввести название ресурса в хроме и просто пролистать карусельку, даже не заходя на сайт, тем самым сэкономив время и трафик. BBC, Lenta, Meduza… да хоть RT. И другие подтягиваются потихоньку.
    Печалит только ограничение Googl'а «только новостные ресурсы».


  1. Methos
    04.04.2016 22:11

    При чём тут AMP вообще?
    Страница стала 1 Мб вместо 8 Мб, 23 запроса вместо 400, КОНЕЧНО она будет загружаться быстрее =)))


    1. ianbrode
      05.04.2016 09:05

      Не только из-за этого. Есть ещё гугловский кеш.


      1. Methos
        05.04.2016 22:02

        Ну это давно уже используется, такие проксирующие кеши были начиная с самого рождения интернета =)


        1. ianbrode
          06.04.2016 01:00

          Конечно. Только обычно это мемкеш или что-то подобное. А тут локальный гугловский cdn играет эту роль, и вам не надо тащить данные с другого континента.


          1. ayurganov
            07.04.2016 16:13

            memcache тут ни при чем.

            или в ленте про geo-cdn не слышали?


            1. ianbrode
              07.04.2016 17:06

              тут готовое решение, развернуть которое — это изменить вёрстку и пару скриптов добавить. в обмен вы получаете гугловские cdn без необходимости лезть в nginx и что-то настраивать дополнительно.


              1. ayurganov
                08.04.2016 02:38

                вы конечно не обижайтесь, но вы выражаетесь в стиле «слышу звон, да не знаю где он»

                пусть прозвучит как реклама cloudflare, но там вообще не надо лезть в настройки nginx. только поменять ns-сервера.

                Взамен, из коробки, например, можно получить автоматическое сжатие картинок или combine js&css.

                Нет, безусловно, спасибо вам за описание AMP, и здорово, что вы так быстро ее внедрили и получаете больше трафика от гугла, но почитайте вот еще ссылки выше, да и вообще про доставку контента юзерам.

                Peace ;-)


                1. ianbrode
                  08.04.2016 11:45

                  По ссылкам известные и не очень новые вещи. :) Спасибо что нагуглили.

                  Мобильную оптимизацию cloudflare даёт только на платном тарифе и никакие стандарты на код не налагает и подсказывает что и где поправить.