Поддержка Плагины отложенная загрузка без плагинов

  • Решено tstas

    (@tstas)



    Здравствуйте!
    Пытаюсь реализовать отложенную загрузку изображений без плагинов, на тестовом сайте wordpress. Сделал следующее:
    Поставил jquery.min.js в хейдер в первую очередь, далее скрипт отложенной загрузки jquery.lazyload.min.js
    Разместил маленький скрипт в футуре на инициализацию.
    В функционал темы добавил следующее:

    
    // Атрибуты для изображений внутри поста
    
    function rudr_custom_html_template($html, $id, $caption, $title, $align, $url, $size, $alt) {
    
    $loader = plugins_url('/loading-rect.gif', __FILE__);
    
    list( $img_src, $width, $height ) = image_downsize($id, $size);
    $hwstring = image_hwstring($width, $height);
    
    $image_thumb = wp_get_attachment_image_src( $id, $size );
    
    if($url){ // if user wants to print the link with image
    $out .= '<a href="' . $url . '">';
    }
    $out .= '<img data-original="'. $image_thumb[0] .'" src="'.$loader.'" alt="'.$alt.'" title="'.$title.'" '.$hwstring.' class="align'.$align.' size-'.$size.' wp-image-'.$id.' lazy"/>';
    if($url){
    $out .= '</a>';
    }
    return $out; // the result HTML
    }
    
    add_filter('image_send_to_editor', 'rudr_custom_html_template', 1, 8);
    

    Впринципе работает, но кривовато, не выводит с отложкой адаптивные изображения.
    Если кто знает, подскажите, как вставить в код функцию wp_get_attachment_image_srcset()
    чтоб срабатывало на изображениях с адаптивной версткой.
    Заранее спасибо.

    Страница, с которой нужна помощь: [войдите, чтобы увидеть ссылку]

Просмотр 5 ответов — с 16 по 20 (всего 20)
  • Огромное спасибо Otshelnik-Fm!!!
    Вот это действительно ответ!
    А не флуд!!!!
    Еще раз спасибо!

    Модератор SeVlad

    (@sevlad)

    wp.me/3YHjQ

    Со всем согласен с Otshelnik-Fm кроме «Стили все в одном стилевом файле — зло» (если речь про кастомные стили).

    Стили — они для темы прежде всего. При её смене фтопку идёт всё скопом.
    Кроме того — нужно юзать комментарии в css и тогда особых проблем не будет.
    Несколько файлов нужно для какого-то особого случая, а большинству этого не надо. Не надо «учить плохому» 🙂

    Несколько файлов нужно для какого-то особого случая

    я написал что css разрастается и путается достаточно быстро. Зомби css (unused css) — это реальные случаи. Его вычислить сложно (трудозатратно по времени). А когда сайт растёт — это частый случай.

    А еще все стили в одном style.css на странице как правило не нужны.

    Я определяю (по ситуации, пунктов может быть больше-меньше):
    I фронтенд
    II бекенд
    Ну и для первого:
    1. css для первого экрана — критичный css (в header)
    2. css для остального (модалка например) — в подвал.
    3. css для гостя — блок-призыв: «как тут классно — регайся» — зачем он в основном css? Или кастомная форма регистрации. Или если посетитель закрыл окно (подписка на новости сайта к примеру), поставилась кука и по кукам видно что не надо его показывать. css этого окна — также мертвый груз.
    4. css для комментариев (а на страницах или записях они могут быть запрещены) — зачем это в общем css?
    5. css отдельно для записи.
    6. Ну и общий css
    —————————
    Аналогично с js.

    — условий много. Все пихать в один css не надо. И именно разрабатывая по модулям — я по условию пишу: что где надо, что критично — а что в подвал. ВП же знает handle стилей/скриптов что нужно загрузить на определенную страницу — вот тебе и уникальный хэш. По нему вызывается бандл всего двух css для страницы: критичный (в шапке) и не важный для первого экрана (грузится в футере). Аналогично js — только 2 файла.

    Я упомянул:

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

    Выход, как и писал выше — объединять в один и минимизировать (учитывая конечно — критичный для первого экрана css в шапку, остальное в футер). Если используется webpack — делается на автомате для проекта, но грубо. Но можно и на php класс написать для этого (им и пользуюсь — внутри WP-Recall он). Ну или на край заюзать нелюбимый мною Autoptimize плагин (вернее не я его не люблю, а пользователи его неверно настраивают. С css проблем нет, а вот js они ломают регулярно своими бездумными переносами в подвал и рушат зависимости и доставляют меня).

    В теме должны быть стили только для темы. Все должно лежать по «коробкам» (внутри плагинов), а пакером уже соединять воедино — чтобы уменьшить кол-во http запросов.

    Фронтенд оптимизация отдельного сайта занимательная штука.

    —————————

    Первый раз я пожалел, что тут нет кнопки «Like»

    Спасибо.

    —————————

    Топикстартер в одной из тем упомянул pagespeed и прочие сервисы… Ну ориентироваться на них можно, но не фанатично (запусти по ним же сами гугловские сервисы — всё пропало). Я давно ими не пользуюсь — т.к. отличный профайлер в хроме (audits вкладка. Он же Lighthouse) — там все круче можно вытянуть для себя, производительность, ограничение сети/устройств. Ну и доступность посмотреть, контрасты.

    По картинкам — надо знать своего посетителя. А вдруг к вам заходят чтоб открыть страничку и вернуться к ней потом. А картинок нет. А инет (wi-fi, 3g уже недоступен)
    не во всех ситуациях lazy load нужен.

    Интересная тема. Я могу только сказать, что:
    1. WordPress — это cms для юзеров. Поэтому тяжелый и не оптимальный, но зато можно делать сайты без умений писать коды.
    2. Чтобы допиливать WordPress, надо уметь читать чужие коды. Если есть такое умение, то зачем тебе WordPress? Делай без cms или на самописной системе управления.

    Модератор SeVlad

    (@sevlad)

    wp.me/3YHjQ

    я написал что css разрастается и путается достаточно быстро.

    Можно подумать все так и правят стили ежемесячно 🙂
    Большинство годами не трогает не только стили… Хорошо, если просто обновляют ВП и компоненты.

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

    Зомби css (unused css) — это реальные случаи. Его вычислить сложно (трудозатратно по времени).

    Есть такое. Ну и что? Была бы речь о сотнях кб — ещё можно было бы говорить. А несколько неиспользуемых байт (на этой странице, но используемых на других) погоды не сделают. Куда затратнее вылизывать такое — и бесполезная трата времени/сил/денег и ресурсы сервера на обработку всяких услових. Да и в большинстве случаев просто неосуществимая мечта на универсальном движке.

    Повторю — я говорю про обычных пользователей. Не гиков, с завышенным ЧСВ, которые считают что тема непременно должна быть уникальна, а в оф каталоге один хлам. Обычный, нормальный юзер берёт тему из оф каталога и через дочку изменяет те же стили.

    И я говорю только про «необходимость css в куче файлов». Всё остальное полностью поддерживаю.

Просмотр 5 ответов — с 16 по 20 (всего 20)