Ускоряем загрузку сайта

WP01 знает, как ускорить ваш WordPress-сайт, и не только это

11.06.2021 21:01:02 |

Автор: admin

Здравствуйте, уважаемые читатели блога7j.ru. Больно это признавать, но судьба всех интернет-проектов зависит от воли поисковых систем. Именно они устанавливают SEO-стандарты, которым должны соответствовать сайты и платформы для их создания. В том числе и Вордпресс.

Вот только не всегда движок успевает подстроиться под новые эталоны. И чаще всего ему не хватает скорости. Но есть один проверенный способ как ускорить WordPress.

Один плагин решит все проблемы!

Скорость – не единственная проблема, с которыми сталкиваются владельцы площадок на Вордпресс. Но WP01 способен решить большинство из них:

Подробная техническая информация о сайте (версии CMS, PHP, MySQL).
Инструкции для создания резервных копий.
Инструменты и описания ручных методов ускорения сайта.
Средства и руководства по борьбе со спамом.
Информация по SEO-оптимизации.
Подбора плагинов.

А теперь посмотрим, как перечисленный выше функционал смог уместиться в один бесплатный плагин. И оценим, насколько он эффективен в деле, а не на словах. Но для начала добавим немного дегтя в идеальный портрет CMS.

Неужели такой медленный?

Ускоряться придется каждому, кто заботится о ТОПе поисковой выдачи, ведь в середине июня текущего года стартует один из важных апдейтов – Core Web Vitals. Но популярные движки не готовы к предстоящему обновлению, о чем свидетельствуют данные ежегодного отчета HTTP Archive.

Core Web Vitals является комплексным фактором ранжирования, состоящим из трех показателей: LSP, FID и CLS. Все они связаны со скоростью работы ресурса. И по данным исследования, WordPress и другие движки соответствуют только одному эталонному показателю – FID (задержка после первого ввода). По остальным двух параметрам движки в пролете. Поэтому накануне запуска Core Web Vitals просто кровь из носа важно уметь и знать, как ускорить сайт на Вордпресс. Надеемся, что в этом нам поможет WP01…

Проверка в боевых условиях

Чтобы скачать расширения, перейдите на его страницу в официальном репозитории WordPress. После его установки в боковой панели административной панели движка появляется пункт «Улучшения от WP01».

*при клике по картинке она откроется в полный размер в новом окне

Функционал, входящий в состав инструмента для ускорения сайта на WordPress, можно использовать пошагово («1») или сразу перейти к нужному инструменту, кликнув по соответствующему пункту выпадающего списка («2»).

На первом шаге отображаются технические характеристики составляющих движка («3»):

Версию CMS.
PHP.
MySQL.
Доступный лимит оперативной памяти.
Путь к файлам движка на хостинге.

В Вордпресс эта информация разбросана по всей админке, а некоторых данных CMS и вовсе не предоставляет. Поэтому приведенные в разделе «Общая информация» сведения позволяют сэкономить время на их поиске.

В правом верхнем углу страницы указана ссылка на инструкцию по созданию резервных копий («4»). Особенно в ней нуждаются не искушенные опытом пользователи.

На втором шаге расширение предоставляет справочную информацию о резервировании данных площадки и базы данных MySQL.

*при клике по картинке она откроется в полный размер в новом окне

В первом блоке слева приводятся общие инструкции по созданию бэкапов с помощью специализированных расширений, скриптов, панели управления хостингом и т.д. («1»). Ниже размещен список руководств по резервированию данных через FTP и созданию копий MySQL («2»).

Справа отображается подсказка, поясняющая новичкам, что такое резервное копирование и как оно происходит («3»). Под ней расположен список основных параметров MySQL: имя БД, логин пользователя, пароль и т.д. («4»).

Плагин предоставляет не просто перечень ссылок на документацию о том, как перед ускорением сайта на WordPress осуществить резервное копирование, но и сами инструкции.

*при клике по картинке она откроется в полный размер в новом окне

Третий этап («Ускорение загрузки») – один из самый объемных. В самом начале раздела размещена таблица с сервисами для измерения скорости ресурса и их кратким описанием. Справа от нее – подсказка с краткой инструкцией.

*при клике по картинке она откроется в полный размер в новом окне

Ниже расположена таблица со списком плагинов для оптимизации работы движка. Рассмотрим эту таблицу более подробно:

*при клике по картинке она откроется в полный размер в новом окне

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

*при клике по картинке она откроется в полный размер в новом окне
Степень важности.
Управление модулем – установка или его запуск.
Инструкция по инсталляции плагина.

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

*при клике по картинке она откроется в полный размер в новом окне

Четвертый шаг позволяет вебмастеру полностью защитить свой ресурс от взлома и распространения спама. Для этого предлагаются сервисы для проверки («1»), специализированные плагины («2») и ручные внедрения.

*при клике по картинке она откроется в полный размер в новом окне

В пятом шаге описывается поисковая оптимизация площадки с помощью сервисов и плагинов.

*при клике по картинке она откроется в полный размер в новом окне

А также собственными усилиями и с помощью функционала движка.

*при клике по картинке она откроется в полный размер в новом окне

Шестой раздел содержит сведения о дополнительных инструментах, которые можно применять после того, как ускорите WordPress.

*при клике по картинке она откроется в полный размер в новом окне

На седьмом шаге можно связаться с разработчиками расширения – командной компании WP01, оценить инструмент и поставить ему в репозитарии пять звезд.

*при клике по картинке она откроется в полный размер в новом окне

Уникальное решение

WP01 – это не просто учебник по улучшению сайта на WordPress. Плагин является справочником по расширениям и кодовой их заменой. При этом предоставляемая плагином информация достаточно ценная. Конечно, ее можно получить и самостоятельно. Но для этого придется перелопатить сотни технических статей (в большей степени англоязычных) и выжать из них суть. A в рассматриваемом расширении эти сведения доступны в чистом виде и бесплатно.

Функционал, реализуемый плагином, уникален. С его помощью можно разогнать, защитить или подготовить к SEO свой сайт и сделать это всего лишь за пару часов. Часть инструментов, входящих в состав модуля, ранее были доступны только в платных расширениях за сотни долларов. Поэтому плагин еще и значительно экономит ваши деньги.

Избавьтесь от медленного WP. Сделайте его более быстрым и желанным для поисковиков и пользователей с помощью WP01!

Скачать плагин WP01: https://ru.wordpress.org/plugins/wp01/

Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru Подробнее..

Категории: Ускоряем загрузку сайта

Page Experience, Core Web Vitals (LCP, FID, CLS) — что это, как набрать 100 баллов в PageSpeed и почему это вам не поможет

16.03.2021 00:01:02 |

Автор: admin

Главная / Вебмастеру / Ускоряем загрузку сайта

Приветствую, уважаемые читатели. Мой очередной раунд борьбы за скорость работы сайта начался примерно год назад (где-то в мае 2020 года). Там был большой апдейт Гугла и у моего блога здорово порезало трафик (графики не хочу приводить, поверьте уж на слово).

К сожалению, у меня в тот период не было особо много свободного времени, чтобы искать причины и исправлять что-то прямо по горячим следам. Начал работать над сайтом только летом, да и то урывками. Причина была в том, что мы переехали жить из города в деревню, а это повлекло много работы по дому (ее и сейчас еще очень много осталось не переделанной).

100 балов в PageSpeed для мобильных и компьютера

Что мне тогда бросилось в глаза, так это очень плохие показатели PageSpeed (кто не знает, это такая оценочная система Гугла, которая выдает не только синтетические тесты скорости и удобства пользования сайтов, но и реальные данные из браузера Гугл Хром). Особенно просели показатели для мобильной версии сайта (почти все страницы были в красной зоне).

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

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

Как набрать 100 баллов в PageSpeed для мобильных и компьютеров

Собственно, скриншот приведен в начале статьи. Иногда вместо 100 вылазит 97, 98 или 99 для мобильных устройств. Для компьютеров обычно всегда 100, но я далеко не все страницы проверял, а посему может где и меньше.

Да, я понимаю, что это синтетика (на данный момент используется Lighthouse 7.1.0). Зачастую 100 баллов в синтетике не дают реальной картины и со скоростью загрузки может быть все плохо. Однако, современный PageSpeed это не только Lighthouse, но и Core Web Vitals (вот эти четыре зелено-желто-красных полоски сразу под цифровой оценкой).

А вот Core Web Vitals говорит о многом, ибо это реальные данные полученные из реальных браузеров пользователей, посещающих мой сайт (само собой, что только из Хрома и Хромиума). На них можно ориентироваться и именно их значения нужно брать за основу, ибо синтетика часто не видит реальных проблем.

Тут главное — слово «ОТВЕЧАЕТ», написанное зеленными буквами. Собственно, это и есть общая оценка сайта. Противоположный вариант слово «НЕ ОТВЕЧАЕТ», написанное красными буквами. У меня такое наблюдается пока в результатах для компьютера, но проблема уже решена и описана ниже. Осталось подождать недельки три, когда обновятся данные.

Более детально можно посмотреть по цвету точек рядом с каждой строкой параметров. Про них мы поговорим чуть ниже, а пока о том, что лично я сделал для получения такого результата.

Из того, что сделал и что осталось в памяти (если нужно будет подробнее, то пишите в комментах — попробую вспомнить):

Сократил размер структуры DOM с 2500 до 1400 на самых больших по объему содержимого страницах (основное количество блоков там создавали комментарии). Как это сделал? Ну, например, посмотрел структуру комментариев и убрал лишнюю вложенность блоков (если комментов сотни, то и снижение DOM структуры происходит на сотни). То же проделал с сайдбаром.
Сделал постзагрузку счетчиков и прочего обвеса с задержкой относительно основного контента страницы. Это дало самый ощутимый эффект. Реальное время загрузки стало меньше на секунды. Как это сделать? В сети описаны разные способы с разными тригерами (по времени, по первому скролу и т.п.). Для разных вещей я использовал разные способы, но конкретики уже, к сожалению, не помню. Надо было записывать, но я как-то не верил, что это сработает.
Применил описанный в сети способ настройки четырех популярных плагинов для Вордпресса (LiteSpeed Cache + Hyper Cache Extended + Autoptimize + Speed Up — по ссылке найдете описание нужных настроек для каждого из них), использование которых в связке решило сразу несколько проблем:
1. Полностью убралась подгрузка внешнего файла CSS стилей. Эти стили интегрировались в Html код (в область Head с помощью тела Style). К сожалению, по умолчанию туда набилось много лишнего CSS кода (например, из админки Вордпресса, который во фронтэнде без надобности). Но путем внесения исключений в плагин, который за это отвечал, удалось от этих огрехов избавиться. Потом еще несколько дней ушло на то, чтобы проверить все строки CSS кода на актуальность, что позволило сократить его более чем в два раза.
2. Джава скрипт файлы тоже были объединены в один файл. Но мне особо ничего не дало.
3. Что-то еще там улучшилось, но что не помню.
Эффект от использования этой связки ощутил сразу. Реально выросла скорость загрузки (еще раза в два, наверное). Кстати, использовал для измерения скорости загрузки эти сервисы. Сразу оговорюсь, прежде чем вы стали кидаться в меня палками — ПингДом не показывает реальной картины (сильно в лучшую сторону дает результаты), но относительно предыдущих измерений и у него скорость выросла в два раза. А вот ВебПейджТест и ДжиТиМетрикс вполне себе адекватную картину формируют, на мой взгляд.
Отложенная загрузка картинок (так называемый Лези Лоуд). Штука необходимая. Дело в том, что измеряется, по сути, скорость загрузки первого экрана, но сама по себе страница может быть очень длинной и с множеством изображений. Если применить Лези Лоуд, то подгрузится только первая картинка (или несколько), попадающая на первый экран, а остальные будут подгружаться по мере прокрутки страницы.
У меня это реализовано с помощью плагина BJ Lazy Load. Вариант не идеальный, ибо для того, чтобы происходила индексация картинок поисковиками используются костыли (урлы картинок прописываются в теге noscript). Но, к сожалению, правильный вариант лези лоуда пока не реализован в виде плагина для Вордпресс (во всяком случае бесплатного и проверенного временем).

Вы мне скажите, что я дурак и уже давно есть атрибут Lazy Load для тега IMG (так называемый, нативный лези лоуд). Да есть, но прямое его применение не дает ровно никакого результата (даже наоборот, на мобильных устройствах все картинки будут грузиться при открытии первого экрана). Есть способ это побороть с помощью CSS свойства content-visibility, но у меня не получилось это реализовать на своем сайте (да и ютуб ролики, как я понимаю, в этом случае не будут работать с отложенной загрузкой).
Добавил ко всем изображениям атрибут decoding="async". Что он делает? Если кратко, то помогает ускорить сайт за счет асинхронной загрузки изображений. Стоит ли его добавлять, если об этом никто не пишет? Стоит, ибо реально есть прибавка в скорости. Как добавил? Через файл функшион.пхп, но деталей не помню. Если кто сам не найдет способ — попробую покопаться в этом файле, чтобы вспомнить.
Убрал все изображения из шаблона. Дело в том, что каждое из изображений прописанных в CSS (например, фоновые картинки, значки соцсетей, галочки, полочки, линии и тп.) создает отдельный запрос при загрузке страницы, что влияет на общую скорость. Причем Лези Лоуд на них не действует. Изначально (несколько лет назад) у меня формировалось около семи десятков запросов при загрузке страницы. Сейчас их только несколько (html страница, заглавная картинка, фавикон, объединенный джаваскрипт-файл и джиквери)
Убрал CLS (Cumulative Layout Shift). Не сразу обратил внимание и разобрался что такое CLS. Оказалось, что под этой аббревиатурой скрывает так называемый суммарный сдвиг шаблона. Он напрямую говорит об удобстве пользования сайтом, хотя его вес в калькуляторе Core Web Vitals весьма скромен на сегодняшний день (5 процентов).
Суть такая. После загрузки страницы на ней ничего не должно дергаться и смещаться в какую-либо сторону. Сами знаете, открылась страница, вы только хотели нажать на кнопку, а она раз и ускакала после подгрузки какого-то припозднившегося элемента (картинки, для которой не было заранее зарезервировано место, виджета соцсети, рекламного баннера). Если таких сдвигов не будет, то CLS будет равен нулю.

Сначала я прописал для всех картинок высоту и ширину (через функшион.пхп) и поменял метод прикрепления верхнего меню (ранее было через джава-скрипт, а стало через css позиционирование). Потом в настройках автоматических объявлений Адсенса (они у меня все автоматом расставляются) исключил все места на первом экране. Делается это через меню Объявления — настройки вашего сайта — удаление нежелательного места размещения.

Это решило проблему с большим CLS (более 0.3 был). Но в начале этого года опять начал расти CLS, но только «для компьютеров». Вот честно, сломал голову, ибо не мог понять в чем дело. Визуально никаких сдвигов на первом экране не наблюдалось. Хоть тресни.

Спасибо ребятам, которые выпустили размещенный ниже ролик.

Оказывается, с начала этого года Гугл стал считать CLS не только на первом экране, а на всем протяжении общения пользователя со страницей.

К тому же они привели ссылку на отличный плагин для Хрома, который позволяет в реальном времени отследить изменения Cumulative Layout Shift при прокрутке страницы.

Причиной стал так называемый плавающий сайдбар (реклама в блоке внизу сайдабара, которая остается зафиксированной при прокрутке страницы ниже сайдбара). Она фиксировалась с помощью джаваскрипта (подменой позиционирования relative на fixed при прокрутке страницы ниже сайдбара).

Пришлось потратить пару часов и заменить джава логику относительно новым CSS способом позиционирования через position sticky. Время ушло на то, чтобы понять, почему это не работает. Оказалось, что мешает overflow:hidden родительского элемента (это недокументированая фича). Пришлось заменить overflow:hidden новым CSS свойством display: flow-root, как посоветовал один замечательный товарищ в этой ветке.

Пока CLS для компьютеров у меня достаточно высокий, но этот показатель обновляется долго (сбор идет из реальных браузеров посетителей сайта), поэтому будем подождать. Рад, что нашлась причина, ибо начинал уже биться головой об стену в ее поисках.
Обновил компоненты сервера (ОС, Php, веб-сервер) и исправил ошибки. Все это вкупе дало малую прибавочку в скорости (особенно при формировании страниц еще не закешированных плагином, для которых на лету производится рендеринг) и повысило безопасность сайта (HSTS, убрал версии некоторых компонентов сервера из общего доступа), что тоже может быть оценено поисковиками.
Конечно же, моих куцых мозгов на это бы не хватило. Поэтому пришлось обратиться к специалисту. Сайт у меня размещен в облаке Инфобокса (в принципе, все очень и очень устраивает, кроме невозможности заказать у них сейчас проведение работ на сервере, ибо сильно загружены они работой).

Обратился через Кворк к спецу с хорошими (отличными) отзывами. Прикольно, что когда указал ему сайт, то оказалось, что мы уже сотрудничали. В 2009 году мой блог размещался на бесплатном хостинге окснул.нет и этот товарищ был там администратором. Много мне помогал и даже запомнил мой сайт. Работу он сделал очень быстро и недорого. Классный специалист, рекомендую.

Из того, что еще не реализовано. Хотелось бы прикрутить нативный лези лоуд к сайту и отказаться от подгрузки джиквери. Не знаю, получится ли. Но пока это поставил на паузу. Вдруг что-то появится по теме и можно будет самому не ломать голову.

Что такое Page Experience, Core Web Vitals (LCP, FID, CLS) и зачем это все нужно

Ну, по идее, это то, что уже должно было сейчас учитываться в полной мере при ранжировании сайтов в Гугле, но из-за пандемии было перенесено на первую половину этого года. Хотя, еще не факт что это будет что-то грандиозное и переворачивающее всю выдачу Гугла с ног на голову.

Однако, вокруг этих относительно новых метрик идут оживленные дискуссии и, думаю, что соответствовать новым требования должны стремиться любые сайты. Почему? Ну, потому что этот тренд будет активно продвигаться и лобироваться Гуглом до тех пор, пока все не очухаются от спячки.

Примерно так было с переходом на Https (собственно, Page Experience включает в себя этот фактор) — сначала рекомендовали, а сейчас без Https ранжироваться высоко стало сложнее.

Все дело в том, что число сайтов в сети растет в геометрической прогрессии. Однако пропускные возможности оборудования сети интернет выросли не столь значительно. Уже реально сложно становится Гуглу индексировать такое количество сайтов, тем более, когда они еще и тормозят по-страшному. Гугл не Яндекс, его индекс на пару порядков побольше будет, и играться с ПФ, как наш поисковик, мировой гигант не может.

По этой же причине Гугл начал активно продвигать семантическую верстку (во многих выступлениях представителей поиска это звучит). Поиск уже не может тратить время на выявления значимых областей контента (содержания), ибо на это не хватает времени и мощностей. Будьте любезны сами с помощью семантических тегов указать ему, что и как учитывать. Иначе будут проблемы с ранжированием и даже индексацией.

Точно так же и с Page Experience, Core Web Vitals. Новые факторы ранжирования позволят провести быстрый и несложный анализ, чтобы понять какие сайты ориентированы на удовлетворение пользователей (сделать им «быстро и удобно»), а какие нет (жрите, что дают). Отсеев тех, кто не с нами, будет проще формировать релевантную выдачу из быстрых и удобных ресурсов.

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

Что входит в Page Experience (анализ удобства страницы):

Как видите, тут и удобство просмотра сайта на мобильных (кто еще об этом не задумался — самое время, ибо около 70% пользователей заходят в сеть с мобилок), и безопасность для пользователей (отдельно от Https), и, собственно, Https.

Первый пункт (Основные интернет-показатели) — это и есть пресловутый Core Web Vitals. Состоит он из трех составляющих:

Отрисовка самого крупного контента (LCP). Этот параметр отражает скорость загрузки. Чтобы страницей было удобно пользоваться, значение LCP должно по возможности составлять менее 2,5 с с момента начала ее загрузки. Грубо говоря, это скорость загрузки первого экрана, а точнее самого большого его фрагмента (можно посмотреть чего именно в Пейдж Спид).
Задержка после первого ввода (FID). Этот параметр отражает интерактивность. Чтобы ей было удобно пользоваться, значение FID должно по возможности составлять менее 100 мс. Грубо говоря, это скорость реакции на нажатие кнопки на сайте. Как быстро начнет все меняться. Но это сильно утрировано.
Совокупное смещение макета (CLS) отражает визуальную стабильность. Чтобы страницей было удобно пользоваться, значение CLS должно по возможности составлять менее 0,1. Высчитывается это по специально фиг кому понятной формуле. Но суть простая — чем меньше чего-то сдвигается уже после загрузки страницы, тем ниже будет этот показатель (идеально — ноль).

В PageSpeed отображается еще и параметр First Contentful Paint (FCP). Это время до первой отрисовки контента – показатель, который определяет интервал времени между началом загрузки страницы и появлением первого изображения или блока текста. Штука важная (15% по калькулятору). Хотя все эти веса, да и сами параметры входящие в Core Web Vitals еще не раз поменяются.

В формате видео все эти аббревиатуры будет, наверное, проще осознать и понять их суть. Это гости Михаила Шакина (хороший у него канал) и один из них весьма и весьма подкован в теме, при этом может пояснять в доступной форме (другой не подкован, но говорлив):

Еще раз подчеркну главное.

Core Web Vitals — это не расчетные (не синтетические), а вполне себе реальные данные, собранные в Хроме пользователей, которые заходили на ваш сайт. Это самая что ни на есть реальность. Если тут все плохо, то звоните во все колокола и бегите все исправлять, даже если PageSpeed показывает 100 баллов для мобильных и компьютеров.

Еще очень важно. Не для каждой страницы вашего сайта будут отображаться отдельные показатели Core Web Vitals. Скорее всего у вас будет написано, что:

Данные наблюдений. В отчете об удобстве пользования браузером Chrome недостаточно данных о фактической скорости загрузки этой страницы.

У меня отдельные данные по Core Web Vitals отображаются только для самых посещаемых страниц, например, этой. Чтобы увидеть средний показатель по сайту надо будет там нажать на «Показать данные об источнике».

Важно. Данные по Core Web Vitals обновляются в масштабах сайта весьма медленно. Поэтому не ждите мгновенных изменений. Запасайтесь попкорном и посидите месяцок у экрана. Для страниц, где Core Web Vitals считается отдельно, скорость обновления будет намного выше.

Еще важно. Где еще можно посмотреть реальные данные по Page Experience для вашего сайта. Конечно же, в панели для Вебмастеров. Там данные тоже обновляются не в реальном времени, но зато можно принудительно заставить поисковик их пересчитать, чтобы ускорить процесс.

Начать повторную проверку Коре Веб Виталс через панель Гугла

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

Почему это вам не поможет

Ну, не знаю. Просто мне пока не помогло (положительного результата в ранжировании от увеличения скорости не видно). Начал оптимизацию скорости я давно. Правда, через пень-колоду и много косяков было по ходу преобразования (даже пришлось проверить все страницы сайта на Html валидаторе, и не зря — нашел десятка два критических ошибок).

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

Повторять ли вам мой путь, тратить ли на это время или деньги — вопрос риторический. Однако, буду признателен вашим замечаниям и, возможно, советам (например, по реализации на практике работающего нативного лези лоуда).

За сим разрешите откланяться. Жду, однако, комментов. Кто первый?

Удачи вам! До скорых встреч на страницах блога7j.ru