Компьютерное

Очень часто при разработке сайта забывают о его оптимизации для печати. В чем же она заключается? По сути, в ней две составляющих: сделать так, чтобы лист использовался рационально, и убрать все то, что на бумаге бесполезно:

• навигационное меню
• формы для поиска по сайту и комментариев
• рекламные блоки, виджеты соцсетей и кнопки «поделиться»
• различные всплывающие и накладывающиеся поверх основного контента элементы (например, на этом сайте это ссылка «Задать вопрос» справа)
• облако тегов
• «подвал» сайта

Но не переусердствуйте! Обязательно оставьте видимыми «хлебные крошки», название и логотип сайта, а также контактные телефоны и Email, если они есть на сайте.
Кроме того, следите, чтобы при печати использовалась вся ширина листа, то есть не было бы жестко заданной ширины в пикселях для сайта в целом или для основного блока с контентом.
Как это сделать технически? Некоторые CMS позволяют создавать отдельные страницы для печати. Но это плохое решение: с точки зрения поисковых систем получаются дубли страниц, причем иногда версия для печати индексируется лучше, чем основная, и пользователи из поисковых систем, попадая на нее, не могут понять, как перейти на основной сайт. Поэтому лучше использовать средства CSS — media-запрос print, переопределив с его помощью CSS-свойства элементов на основной странице. Читать далее…

Возможно, еще не всем известно, что на этой неделе Яндекс окончательно отменил ТИц и вместо него ввел новый показатель — индекс качества сайта (ИКС), который учитывает не только ссылочную массу, но и еще ряд факторов. Я собрал информацию по своим сайтам и получил следующие данные: Читать далее…

Современные сайты слишком активно стали обвешивать всякими ненужными скриптами: то онлайн-консультанты, то обратные звонки, то надоедливые предложения подписаться, закрывающие контент в самый неподходящий момент. Не говоря уж о том, что это дополнительное время загрузки и дополнительный расход памяти. В результате я все чаще и чаще задумывался о том, что JavaScript должен быть по белому списку, то есть только на тех сайтах, где он действительно нужен, и где я разрешил его явно. К тому же это устраняет часть потенциальных угроз, с которыми можно столкнуться на просторах Интернета.
Но увы, каждый раз лезть в настройки Opera и явно включать JavaScript для каждого сайта штатными средствами Opera очень неудобно. Стал задумываться об установке стороннего дополнения. Хотел было использовать NoScript, которым когда-то пользовался под Firefox, но под Opera его нет.  Есть одноименное расширение от других разработчиков, но с ужасным интерфейсом и весьма неудобное.
Стал искать другие варианты и наткнулся на ScriptSafe. Понравилось сразу: и интерфейс приятный, и есть возможность в два щелчка мыши разрешить или запретить загрузку JavaScript как для основного домена сайта, так и по отдельности для каждого из сторонних доменов, что дает возможность заблокировать сторонние скрипты типа социальных виджетов или тех же обратных звонков. Любителям приватности также пригодится множество опций для защиты от отслеживания.
Единственная проблема, которую я на данный момент выявил — неудобно производить оплату картой онлайн, так как при этом происходит несколько редиректов между сайтами (сайт магазина, сайт платежной системы, сайт банка), каждый из которых приходится добавлять в белый список, чтобы скрипты сработали.

Иногда при написании скриптов требуется узнать, сколько времени скрипт выполняется. Для этого есть несколько способов. Во-первых, можно воспользоваться стандартной для Unix-систем утилитой time:
time script.sh time python script.py time php script.php
Она выдаст что-то вроде
real 0m0.012s user 0m0.004s sys 0m0.000s
Здесь нас интересует первое значение: real. Оно показывает, сколько реального времени заняло выполнение скрипта. User и sys показывают потраченное процессорное время в режиме пользователя и режиме ядра, которое, даже суммарно, может быть меньше реального из-за простоя и ожидания.
Но утилита time замеряет полное время выполнения, с учетом затрат на запуск интерпретатора, загрузку скрипта и т.п., что не всегда желательно.
Поэтому иногда бывает целесообразнее использовать средства самого языка программирования. В PHP для этого используется функция microtime:
$start_time = microtime(true); // true — получать данные в // какой-то код $time = microtime(true)-$start_time; // в переменой $time будет время в секундах, // которое потрачено на выполнение кода
В Python все аналогично, только необходимо подключить модуль time:
import time start_time = time.time() # какой-то код time = time.time()-start_time  // время выполнения также будет в секундах
В JavaScript это выглядит чуть иначе — необходимо использовать объекты Date:
let start_time = new Date; # какой-то код time = (new Date -start_time)/1000  // разность между двумя объектами Date измеряется в милисекундах, // поэтому делим ее на тысячу

В Интернете есть примеры асинхронной загрузки CSS через setTimeout или манипуляции с media, но есть более красивое и современное решение — через rel=preload. Выглядит оно так:
<link type="text/css" href="style.css" rel="preload" as="style" onload="this.rel='stylesheet'" /> <noscript> <link type="text/css" href="style.css" rel="stylesheet" /> </noscript>
Однако следует помнить, что если вы асинхронно загружаете основной CSS без выноса его критической части в тег style непосредственно в HTML, то получается довольно неприятный эффект — сначала страница отображается без стилей вообще, потом тут же перерисовывается заново. Поэтому такую асинхронную загрузку лучше применять только к вспомогательным CSS.

Я уже не раз писал в этом блоге о приемах для ускорения отображения сайтов. Это и отложенная асинхронная загрузка, и условная загрузка по имени класса, и запуск inline JavaScript-кода после загрузки внешнего файла по событию.
Теперь же я сделал библиотеку-загрузчик, которая упрощает и автоматизирует их применение, а также позволяет собрать список всех используемых на сайте библиотек в одном месте. Называется она CondiLoader, скачать ее можно на GitHub или же установить через npm:
npm install condiloader
Работает CondiLoader следующим образом: вы передаете скрипту список объектов для загрузки, он дожидается события DOMContentLoaded. После этого для каждого объекта проверяет, необходимо ли загружать его для данной страницы. Если да, приступает к загрузке, после чего вызывает функцию инициализации, либо пользовательское событие с указанным именем. Все объекты загружаются параллельно, и ошибка при загрузке одного из них на остальные не влияет. Читать далее…

Недавно столкнулся с вопросом, почему пропадают PHP-сессии при высокой нагрузке. Как известно, что по умолчанию сессии PHP хранятся в обычных текстовых файлах. В Debian/Ubuntu эти файлы располагаются в /var/lib/php/sessions/, в других дистрибутивах путь может отличаться. Сами файлы по размеру невелики, но если сессия открывается при каждом обращении к сайту, то когда на сайт заходит поисковый робот, таких файлов может создаваться весьма большое количество. Как этого избежать, я описывал в одном из предыдущих сообщений.
Теперь же рассмотрим ситуацию, когда сессию создавать действительно надо, но она не создается. Вероятная причина подобного — нехватка свободных inodes. Inodes — это записи в файловой системе, используемые для описания, где находится файл, и для каждой сессии PHP требуется как минимум один свободный inode. Если они заканчиваются, то создавать файлы становится невозможно, даже если на диске еще много свободного места. Количество inodes ограничено либо настройками файловой системы (на выделенных серверах и VDS под Xen), либо тарифным планом (на shared-хостинге и VDS под OpenVZ). Кроме того, на shared-хостингах обычно также существуют лимиты на количество файлов, не связанные с inode.
Проверить количество свободных inodes можно с помощью команды
df -i
 в командной строке, а посмотреть лимит на создание файлов — в панели управления хостингом. Для нормальной работы необходимо, чтобы запас и того, и другого составлял хотя бы десять тысяч.
Если стало ясно, что проблема не в inodes, проверьте, что в php.ini корректно выставлены параметры session.gc_maxlifetime, session.gc_probability и session.gc_divisor. И что ни в одном из скриптов, выполняемых на сервере они не меняются через функцию ini_set. Также имеет смысл заглянуть в crontab (на shared-хостинге он может называться «планировщик заданий»), и проверить, что там нет никаких скриптов, которые могли бы очищать каталог с сессиями.

Некоторое время назад на SbUp.Com наткнулся на тему «каким должен быть идеальный сайт» с технической точки зрения, и решил изложить свою точку зрения по этому вопросу. На мой взгляд, идеальным сайтом можно назвать тот, который максимально похож на статику. Для некоторых типов сайтов (блог и простой магазин) лучше вообще генерировать в админке статические страницы с основными данными, например, текстом сообщения или карточкой товара, а часто меняющиеся второстепенные данные — содержимое корзины, список последних постов — подргружать через AJAX. (Я такой подход называю StaJAX, от static+AJAX, но, к сожалению, он не так распространен, как хотелось бы.)
Кроме этого, идеальный сайт должен обладать такими признаками:

• Быть сверстан вручную, без всяких bootstrap и тому подобного, с минимально возможным количеством тегов и короткими именами css-классов.
• 100%-валидный HTML и CSS.
• Полностью асинхронная загрузка JavaScript после события DOMready.
• Полная оптимизация всех картинок, настройка сжатия GZIP для HTML, JS, CSS и их минификация.
• Использование разметки хлебных крошек — тоже обязательно.
• Короткие и заданные вручную HURL, желательно, на английском, а не транслитом (то есть адреса вида /first-post.htm вместо /eto-pervaya-zapis-v-bloge.htm) и уж точно никакой кириллицы (исключением могут быть только словари и wiki-проекты).
• Иметь правильную иерархию URL, то есть адреса вида /название-категории/имя-товара.htm вместо /categories/название-категории.htm и /products/имя-товара.htm.

В общем, у идеального сайта скорость загрузки и экономия траффика должны быть на первом месте (после самого контента, конечно). Ещё полное отсутствие всплывающих блоков, которые закрывали бы контент (типа «закажите обратный звонок» или «подпишитесь на нас в социальных сетях»). И небольшой субъективный момент: не должно быть «обрезанных» URL без / или .html на конце. Выглядит просто отвратительно!

Вчера узнал, что Goolge Pay теперь можно использовать не только в приложениях, но и на Web-сайтах, и решил разобраться, как это делать. Как выяснилось, с технической точки зрения там все достаточно просто. Подключение состоит из трех этапов:

1. выбрать платежный шлюз — либо один из тех, которые сотрудничают с Google, либо какой-то сторонний, и получить от него merchantID, и, возможно, другие параметры для подключения. В случае проведения оплат через сторонние шлюзы также потребуется их публичный ключ.
2. добавить на страницу оплаты контейнер для кнопки оплаты и необходимые скрипты, и проверить работу Google Pay в тестовом режиме,
3. подать заявку в Google на проверку и подключение сайта. После ее прохождения поменять в скриптах некоторые настройки с тестовых на рабочие.

Рассмотрим подробнее второй этап. Читать далее…

Недавно я уже давал несколько рекомендаций, как делать резервное копирование баз данных. К этому хотелось бы добавить совет не хранить backup на том же сервере, что и основные данные. Но как быть, если сервер всего один? На помощь могут прийти облачные хранилища, которые работают по протоколу WebDAV, например Яндекс.Диск. Загрузить туда файл можно обычным HTTP-запросом с помощью утилиты curl из командной строки или bash-скрипта. Делается это так:

curl -T локальный_файл https://webdav.yandex.ru/удаленный_файл --user логин:пароль

При необходимости у имени удаленного файла можно указать и путь, например, Backups/daily.gz, но тогда все каталоги в пути должны уже существовать на сервере.