Я, как разработчик одного из плагинов оптимизации для WordPress, могу сказать, что по моим внутренним тестам, наилучшие показатели PageSpeed Insights имеют следующие три плагина (упорядочены по алфавиту, а не по результату):
- Hummingbird
- LiteSpeed Cache (его уже упоминали выше)
- PageSpeed Ninja
Попробуйте, надеюсь один из них вам поможет. Главное правило - плагин оптимизации должен быть только один, иначе они или мешают друг другу, или увеличивают TTFB и остальные метрики.
Во всех браузерах можно вызвать окно печати через window.print(); а там уже пользователь может выбрать Save as PDF в качестве принтера. Других вариантов (кроме разной степени глючности скриптов для конвертации html в pdf) я не знаю.
FastSpring тоже сейчас не работает с Россией (по причине, дословно, "due to sanctions placed by our payment partners"). Подозреваю, что PayPro Global тоже вряд ли сейчас работает с Россией.
Скорее всего в AdMob не дураки работают, и для подсетки, из которой приходят запросы от тестов Google Play, либо выдается реклама-пустышка, либо не засчитываются клики. Иначе эта проблема уже давно была бы у всех на слуху.
Еще как вариант - сохраните XML в файл и считайте его через simplexml_load_file, тогда в случае ошибки можно внимательно изучить содержимое файла. Пока ошибка выглядит как будто данные были почему-то обрезаны еще до вызова simplexml_load_string.
Как вариант, задать position:relative для внешнего контейнера (.uk-grid, как я понимаю) и убедиться, что он не задан у самих блоков, а потом всплывающий текст позиционировать через position:absolute;left:0;right:0 (без указания top/bottom).
Александр, Если не ошибаюсь, PHP линкуется с libwebp статически, поэтому нужно либо обновить libwebp И пересобрать PHP из исходников, либо обновить PHP до бинарной сборки, основанной на последней версии libwebp. Правда, я посмотрел changelog у libwebp и не нашел ничего, похожего на такую ошибку. С другой стороны, в модуле gd в PHP логика тоже самая простая - записываем в файл все данные, которые вернула libwebp, и там вроде бы нет возможность потерять дополнительный байт.
Вы на какой версии PHP наблюдаете эту ошибку? Было бы интересно попробовать ее воспроизвести.
Скорее всего, проблема в том, что по спецификации размер webp файла должен быть четным числом, и если это не так, в конце должен идти дополнительный нулевой байт. Так как PHP сам webp не кодирует и полагается на libwebp, то скорее всего проблему нужно искать где-то там.
fursanton1986, Обычно браузеры в смартфонах с экраном шириной 720 "реальных" пикселей используют CSS-ширину либо 360px (devicePixelRatio=2), либо 412px (devicePixelRatio=1.75), так что в любом случае стили из @media(max-width:453px) будут применены.
fursanton1986, От dpi зависит только сколько реальных пикселей содержится в единице измерения px в CSS. Для всех CSS правил это внутренние детали реализации, т.к. все абсолютные величины измерения приводятся к px через стандартный набор множителей. И в итоге браузер на лету преобразует ваше @media(max-width:20cm) в @media(max-width:756px) и ничто не мешает задать этот размер сразу в пикселях. При изменении масштаба меняется размер базовой единицы px и, как следствие, всех привязанных к ней остальных единиц измерений (можете для проверки сделать тестовую страницу с блоком width:1cm;height:1cm и посмотреть, как он будет менять размер при изменении масштаба).
К сожалению, они удалили старый вариант из исходников. Можно пожаловаться через Help->Report an issue (что я и сделал), но вряд ли это на что-то повлияет.
Можно генерировать случайный токен и отправлять запрос на site.ru/json?token=0123456789abcdef с небольшим временем жизни токена (например, 30 секунд). Это не даст пользователю обратиться к /json напрямую, хотя никто не помешает скачать и пропарсить исходную страницу в поисках ссылки, включающей токен.
- Hummingbird
- LiteSpeed Cache (его уже упоминали выше)
- PageSpeed Ninja
Попробуйте, надеюсь один из них вам поможет. Главное правило - плагин оптимизации должен быть только один, иначе они или мешают друг другу, или увеличивают TTFB и остальные метрики.