Здравствуйте.
Занимаюсь full-stack сайтами (от дизайна до разработки, ни на что не претендую) на ВП.
Делаю сайты изменяемыми для клиентов (не просто записи, а прям вообще все, контакты, описания, блоки разные - востребовано и платят).
И не нравится мне то, что по идее концепция подразумевает сам факт наличия динамического php кода в коде страницы. Но результатом является то, что обычная html страница грузится 0.3 сек, а на вп - порядка 1-2 при прочих равных.
Можно ли как-то настроить вп на то, чтобы все страницы с динамическим кодом сохранялись в статику и подгружалась уже она?
Ведь Битрикс (который композитный) как-то же работает, а скорость там мне очень нравится :) но я понимаю, что тем не менее там динамика. Как? Куда копать?)
===
Я сейчас говорю только за "первое посещение сайта". Кэш - это круто и давно работает и без всяких "композитных сайтов" за 4000$.
===
Я может неправильно выразился. Мне очень нравится, когда я на своем ужасном мобильном интернете могу зайти на страницу за 0.4 секунды, там начинает сразу отображаться какой-то контент. Да, там потом картинки подгружаются, это мелочи. Весь прикол в том, что когда идет запрос от браузера - сервер отдает файл, а не выполняет жуткий запрос генерации страницы из php хуков wordpress'a.
Иван Украинцев: ну тогда бд mysql изменить на монго. Но блин, смысл такое для вп проворачивать если есть фреймворки и тот же функционал там можно реализовать.
eskrano: у ВП, несмотря на все его недостатки, есть один (и самый жирный) плюс - сообщество. Именно оно позволяет "вылизывать" конечный продукт до состояния "бери и пользуй". Это и нужно конечному потребителю. Да, Ларавелька и Симфони - просто бальзам на душу для программиста, но только если сайт нужен самому программисту. Почему же выбирают ВП? Лично по моему опыту - в подавляющем большинстве случаев только из-за того, что "все привычно и понятно".
1. Установить nginx + php-fpm
2. Настроить в nginx выдачу всех страниц, которые генерятся в PHP через файлы habrahabr.ru/post/124684
не кэшировать, если пользователь авторизовался или оставил комментарий через внутреннюю систему комментариев. Если комменты через Disquss, то с ними сам Disquss разберётся.
3. Подключить плагины к Wordpress, которые работают с memcached.
навскидку: Supercacher и W3 Total Cache
4. Настроить сборку всех JS и CSS в кучу, сжатие и выдачу в минифицированном виде.
Я уже раньше отвечал по поводу оптимизации VPS под быструю работу именно WP. Можете порыться в моих старых ответах. Но там все конечно в общих чертах. Сейчас как раз готовлю серию статей по этому поводу - от сетапа системы и пакетов, до оптимизации самого WP и кастомного кода. В принципе, могу достаточно детально проинструктировать, но писать тут сейчас такой объем лень :) Если хотите - стукните в личку (см. профиль).
Если кратко:
На shared хостинге разве что плагины кеширования, disk cache и тд. Чтобы добиться максимума, нужно:
VPS
нормально настроенная система, особенно дисковые и сетевые операции, включая tcp congestion control и прочие няшные твики
Nginx, можно с fastcgi_cache, для хардкора есть модуль для прямой работы с memcached
HHVM c фоллбеком на PHP-FPM (с opcache)
Memcached / Redis
MariaDB
WordPress
плагин/класс объектного кеширования на уровне WP
минификация и конкатенация скриптов и стилей
оптимизация изображений
грамотный код (в том числе использование объектного кеша, transients / wp_cache)
грамотное использование функционала ядра WP и архитектурные решения
и еще огромная тележка мелких нюансов
зы: такой хардкор касается не только WP но и любой другой платформы, если надо "быстро"
ззы: а еще уже вышел HTTP/2 модуль под Nginx, сейчас как раз тестирую. Шустрая штука (кстати, снимает небольшую часть задач перечисленных выше)
Александр Таратин: ну если взять в учёт только актуальные версии браузеров, то не умеют лишь opera mini, uc browser, android browser. Первые два умеют обновляться.
evnuh: именно поэтому я дописал "ззы" :) Все же, установка и настройка HTTP/2 пока что штука для более-менее продвинутых - это и кастомная сборка Nginx, и покупка сертификата, и его установка на сервере.
Александр Таратин: свежие версии умеют, поэтому, можно смело считать, что на данный момент покрывается все кроме IE на винде ниже 10, оперы мини и андроида. Опера скоро обновится, задержка была именно в стабильной реализации протокола на стороне серверов (Apache, Nginx etc). Остальные - не паримся особо, так как HTTP/2 с обратной совместимостью, то есть при отсутствии его поддержки работа идет по стандартному HTTP/1.1. Минифицировать и гзиппить будем все равно, остается только минификация. Вангую в очень разумные сроки появление тулзы для оптимизации / автоматизации этого процесса. Возможно, на уровне сервера будет проверяться поддержка и на лету делаться конкатенация и складываться в кеш. По крайней мере для Nginx сделать такое не проблема, а для Apache можно по условной логике подключать модуль PageSpeed, который в том числе и клеит файлы. Или сам PageSpeed обновится с таким функционалом - если HTTP/2 клиентом подддерживается, то будет отдаваться в обычном режиме, если нет - склеенные файлы.
С другой стороны, вреда от склеенных файлов для HTTP/2 вообще никакого, так что можно и смело оставлять склейку.
Ну и про 5 лет - это вы слишком загнули. HTTP/2 - это тот апгрейд, который реально полезен всем, ибо экономит и время, и ресурсы, и деньги. Вполне возможно, что даже вечно отстающие от обновлений шаред-хостинги достаточно быстро введут поддержку, так как это не только снизит их расходы (смогут больше оверселить), но и добавит новый апсел ко всем услугам - SSL-сертификаты. А с запуском https://letsencrypt.org/ и бесплатными сертификатами для всех распространение HTTP/2 заметно ускорится в 2016. Учитывая нарастающую паранойу по поводу шифрования данных - это только плюс.
Александр Таратин: IE8? Ну это разве что у вас в клиентах какой-то совсем бедный/жадный корпоративный сектор. Покрытие в мире - 2.36% за последний календарный год. В РФ (и среднем по всему рунету) - и того меньше, всего 1.87%. Андроид 2.3 - нафталин 5-летней давности. Все версии андроида - 6.84% мир и 3.73% рунет. Разбивки по версиям у меня нет, но уверен, что подавляющее большинство - минимум 4.0, в основном сендвич, джелли, киткат и лоллипоп. Если есть пруф обратного - буду рад увидеть (сам подробную статистику найти не смог).
Александр Таратин: так а вы сайт для него одного делаете (нафталинового дебила ценителя антиквариата), или все же для пользователей, которые будут на его сайт ходить? Покажите ему ссылки которые я вам скинул. Убеждать клиентов и предлагать им разумные решения - тоже часть нашей работы. Я понимаю, если у вас проект уже в разгаре, но в целом, советую делать так - изначально при переговорах уточняете, нужен ли ИЕ8 (ну и так по всем спорным браузерам / версиям), если да - почему. Пытаетесь выяснить истинную причину, и объясняете (с графиками и статистикой, как по ссылкам), что это: 1) никому не нужно, 2) адаптация под старые версии это дополнительная работа, что = дополнительное время (сроки) и деньги. В 9 случаях из 10 клиента можно легко переубедить, если оперировать реальной статистикой и вкратце объяснить, что добавить поддержку старых браузеров будет стоить ему копеечку, которую лучше потратить на что-то более полезное. Сроки и бюджет - это элементы модели "неизбежных продаж", на этих аргументах клиента убедить достаточно легко.
Игорь Воротнёв:
> установка и настройка HTTP/2 пока что штука для более-менее продвинутых - это и кастомная сборка Nginx, и покупка сертификата, и его установка на сервере.
1.Ставим из mainline, то есть у нас команда на добавление репозитория и команда на установку
2. Сертификаты бесплатные от WoSign
3. Инструкции по установки есть такие, что даже полный дебил поймет
Игорь Воротнёв: > и вкратце объяснить, что добавить поддержку старых браузеров будет стоить ему копеечку
Для меня это равнозначно потере клиента. Конкуренция огромна.
Александр Таратин: Вы на каком-то другом рынке работаете? У вас клиенты какие-то не такие как у остальных? Если ваше конкурентное преимущество - это поддержка старых ИЕ, то у вас большая проблема, и рано или поздно (скорее рано), клиентов вы потеряете все равно. Без обид.
Oioraen:
1. да, 1.9.5 с http/2 уже можно установить без сборки вручную, что лишний раз подтверждает всеобщее желание получить http/2.
2. Ну не знаю, китайские сертификаты мне не внушают доверия. Сайт у них грузится через раз и медленно. Мне лично наличие Великого Китайского Файрвола между моими посетителями и certificate authority нафиг не нужны. Хочется совсем бесплатно - есть StartSSL. А вообще у нормальных сервисов часто сертификаты идут "почти бесплатно" в виде бонуса. К примеру, покупая домены у Namecheap и используя ежемесячную скидку, вы по стандартной цене домена получаете и домен, и нормальный SSL-сертификат, и WHOIS Guard.
3. Установка через какую-то хостинг-панель - просто и понятно. Ручками через командную строку - как ни объясняй, а если человек не дружит с терминалом и не понимает как оно все на сервере устроено - быть беде.
eskrano: посты не динамические, нет, значит пихаем, может в них есть много лишних запросов к базе, на кол-во просмотров и прочего, что может подождать часок.
Виджеты динамические, скорее всего да, но можно их сетить во время публикации в админке, это уберет лишние запросы к базе.
Так же кешим прочие мульти-запросы. На выходе имеем увеличение памяти в 2+ раз, но и прирост в скорости
eskrano: Амм, так мемкеш то можно запихать и в WP, в чем проблема? Просто написать плагин, который повесить на определенные хуки. Делов то на строчек 20
Я расскажу свой опыт.
Интернет-магазин на Woocommerce из 400 товаров.
В 2014 покупал (на деньги клиента) платную топовую версию плагина WeboSpeedup + настройку у них заказывал. В сумме вышло по 20 000р. Можно и самому настроить, если разбираться. Плагин даёт здоровенную кучу настроек.
А в 2015 году они же выпустили облачный сервис кэширования Айри.рф. К нему подключились.
Вроде шустро всё.
Расходы 2500 в месяц. Я 3 сайта подключил и с каждого по 1000р. беру.
По деньгам - там для вебмастеров есть возможность взять с 50% скидкой тариф для 10 сайтов. 2500 в месяц.
Оговорюсь. Я не профессионал в технической части. Поэтому в ньюансах не разбираюсь. Было бы здорово найти какое-то решение, чтобы без заморочек и без регулярных платежей. Чтобы поставил и получил ракету )
Иван Украинцев: Тогда у меня есть для вас решение WP Super Cache, лучший из бесплатных плагинов. Если у вас VPS хостин то он закеширует все, если виртуальный то сможет закешировать в основном только сам движок wp, так на таком хостинге нет доступа к настройкам сервера.
То есть мы грузим например главную и 24 часа у нас в кеше она будет хранится в готовом, скомпилированом виде, в случае обновления страницы в браузере или при заходе другого пользователя она просто высылается клиенту, без перерасчетов. Это лучший из бесплатных плагинов по кешированию, создан на основе платного собрата.
WP Rocket и WP FFPC шустрее WP Super Cache. Но свой максимум все они выдают на VPS / Dedicated. На shared хостингах все сложнее, геморнее, и в результате - все равно медленнее.
Игорь Воротнёв: Согласен, однако WP Rocket не бесплатный, от 40 долларов. А Super Cache конечно медленней, но бесплатен. На shared хостингах нельзя настраивать серверные настройки, поменять максимальный размер файлов и то нужно делать через админов, а следовательно мы не можем настроить кеширование со стороны сервера или предоставить эту возможность плагину.
Про WP FFPC не знаю.
Александр Голубев: на shared основная, самая главная проблема - отсутствие Memcached / Redis, которые радикально меняют ситуацию. Все остальное - вторично. А таже там Apache, который сам по себе тормоз, но самая большая его беда - в работе с PHP. Но перейти на Nginx на shared вы тоже не сможете. Поэтому, для скорости даже самый простой VPS за 5$ в месяц, но настроенный нормально, будет лучше чем самый шустрый и дорогой shared
Игорь Воротнёв: У mchost на shared стоит Apache/Nginx у меня проблем не возникало, хотя может потому что посещаемость около 200 человек в день, это очень мало для проверки. Я на веб разработке не зарабатываю, поэтому от VPS временно отказался.
Хотя за 5$ в месяц, вы меня заинтересовали, не будет реферной ссылки на такой хостинг?
Александр Голубев: Apache + Nginx это бред, хотя и очень популярный. Фокус в том, что статику (картинки, стили и тд) будет отдавать Nginx - быстро. И это хорошо. Но, как только нужна динамика - тот же WordPress с его PHP, Nginx отправит запрос на Apache, поднимется его процесс, который вместе с собой поднимет PHP... Здравствуйте, тормоза.
Как уже многие до меня высказались -- действительно, есть плагины для кэширования, тот же W3 Total Cache очень хорош. Но ко всему этому я бы посоветовал Varnish, эдакий реверс-прокси с кэшированием, заточенный под HTTP.
Иван Украинцев в сети куча статей о том как ускорить работу сайта на WP. Неужели не нашли не одного? Относительно недавно читал статью на хабе об оптимизации, к сожалению нету этой ссылки под рукой что бы поделиться с вами. Расскажу "в двух словах". Сжимаете все картинки, сжимаете все css и javascript файлы, опускаете загрузку скриптов в самый низ документа (в том числе и jQuery). И отключаете несколько функций ядра WP, которые не нужны, как минимум на фронтэнде.
1. jQuery вниз - только если совсем осторожно, он же есть dependency. К тому же, спустить его вниз корректно - это уже advanced technique.
2. Все перечисленное вами - исключительно фронтенда касается. А есть еще долгая задержка между запросом и получением всего этого фронтенда с сервера.
3. Раз уж зашла речь о плотной оптимизации фронтенда, то давайте еще рефаткорить JS. Убирать все ненужное из document.ready, выбрасывать ненужные и медленные либы, менять jQuery на ванильный javascript etc
4. "И отключаете несколько функций ядра WP, которые не нужны, как минимум на фронтэнде" - это вы что такое интересное имеете в виду?
Игорь Воротнёв: 1. Так вроде весь jQuery подключается через файл functions.php с помощью wp_enqueue_script, тогда он по умолчанию будет в самом низу страницы. Подключать как то по другому скрипты и стили не имеет смысла.
И на самом деле скорость загрузки страницы в WP сильно зависит от php кода. Например темы перебирают очень много аргументов, увеличивая время загрузки иногда на 0.2-0.8 сек, чем если бы это была индивидуальная верстка. Не считая еще кривых циклов вывода постов.
У меня страница на сайте полностью загружается от 0.5 до 0.9 сек (зависит от страницы, 0.9 это галереи изображений в высоком разрешении).
Недавно было обновление WP которое увеличило скорость загрузки моего сайта на 0.3 сек.
Это я не имею доступа к серверным настройкам и кешированию изображений, так как у меня виртуальный хостинг.
Александр Голубев: вот в этих 0.5 секундах и проблема. Почему у меня статика грузится за .2-.3 сек?
Я хочу, чтобы вп делал слепок всей динамики в статику, чтобы пользователь "первого посещения" качал 1 .html файл и всё. Мы сейчас не говорим за контент частотой чаще месяца даже.
Также по поводу минификации - зачем это здесь рассказывать, как раз когда это всё спокойно "гуглится". Мне важно именно вот это узкое горлышко, когда вп новому пользователю дает не заранее готовую статику, а генерит все с нуля (а переменных php бывает много да, но они мне нужны для того чтобы клиент мог редактировать сайт).
Александр Голубев:
> Так вроде весь jQuery подключается через файл functions.php
jQuery поставляется вместе с WP, он уже подключен с помощью wp_register_script именно в head, где ему и место. Для подключения jQuery достаточно в enqueue вашего скрипта указать его в аргументе "dependency". А вот чтобы перенести в подвал - придется выпилить это все и зарегистрировать заново, по своему. Что чревато последствиями, так как много других библиотек и скриптов действительно зависят от jQuery, а потому рассчитывают на его наличие в head.
> скорость загрузки страницы в WP сильно зависит от php кода
От PHP зависит скорость генерации страницы на сервере. Скорость загрузки страницы от этого зависит лишь частично, так как это лишь один из этапов загрузки страницы.
> темы перебирают очень много аргументов, увеличивая время загрузки иногда на 0.2-0.8 сек, чем если бы это была индивидуальная верстка
Простите, но вы вообще не понимаете о чем говорите. "Перебор аргументов" происходит быстрее, чем браузер парсит ваш CSS. Задержка, которую вы получаете из-за генерации динамической страницы, возникает из-за необходимости провести кучу вычислений и сборок - запустить интерпретатор языка, считать из файловой системы кучу файлов-скриптов, проанализировать их и скомпилировать в машинный код, выполнить его, а уж потом - распарсить урл, запросить данные из БД, выполнить массу рассчетов, собрать страничку из шаблонов и тд. Это свойственно не только WordPress, а и любой динамической платформе, на любом языке. Это неизбежность. Сравнивать с чистым HTML некорректно, так как в этом случае никакой обработки данных нет, сервер просто отдает готовый файл. Чтобы получить этот же результат от динамических платформ, используется Full Page Caching - кеширование страниц целиком.
> Это я не имею доступа к серверным настройкам и кешированию изображений, так как у меня виртуальный хостинг.
У вас там много уже есть. Это и гзип, и корректные заголовки для кеширования статики и тд. Все, к чему доступа вы не имеете - требует специальных знаний, которых у вас нет.
Иван Украинцев:
> Почему у меня статика грузится за .2-.3 сек
см. выше. Потому что для статики не надо интерпретатор поднимать, парсить файлы и все это дело исполнять, брать данные из БД и файловой системы etc. Для статики просто - взяли файл и выплюнули его в ответ.
> чтобы вп делал слепок всей динамики в статику, чтобы пользователь "первого посещения" качал 1 .html файл и всё
Вам нужен Full Page Cache. Страница генерится один раз и сохраняется в виде статики. Можно хранить как в файловой системе, там и непосредственно в памяти (Memcached, Redis, родной fastcgi_cache у Nginx) - это быстрее. Это делают многие плагины - FFPC (Fast Full Page Cache), WP Super Cache, Batcache и тд. Ищите тот плагин, который позволяет делать pre-caching - генерить заранее, чтобы при первом визите люди сразу получали страницу из кеша. Мой любимый плагин - https://wordpress.org/plugins/wp-ffpc/
> переменных php бывает много да, но они мне нужны для того чтобы клиент мог редактировать сайт
Люди, перестаньте нести чушь про переменные, почитайте хоть основы PHP. Количество переменных (как и их наличие вообще) ничего не решает, это вообще не влияет на скорость обработки кода на сервере. Для того, чтобы переменными на что-то повлиять, это надо сильно постораться наговнокодить так, чтобы были утечки памяти, чтобы рекурсии без выхода шли и тд. В остальных, стандартных случаях, количество ваших переменных в шаблонах WP вообще не имеет значения. Даже для крупных платформ это входит в сферу "микро-оптимизации", а для небольших сайтов - просто выбросите это из головы.
Повторяю еще раз, основные потери идут на запуск интерпретатора, считывание всех необходимых файлов (скриптов), их анализ и компилирование кода, выполнение запросов к файловой системе и базе данных, внешних http-запросов и тп. Это все ресурсоемкие задачи. А работа с вашими переменными - это только маленькая часть одного из этих этапов.
Игорь Воротнёв: ну, я заметил, что страницы, в которых идет вычисление в 50-100 строках php разных там цен, почасовок и тд (на основе 10-15 переменных) - грузятся дольше, чем если бы я их жестко прописывал в html шаблоне данной страницы.
Игорь Воротнёв:
>jQuery поставляется вместе с WP, он уже подключен с помощью wp_register_script именно в head, где ему и место.
Правда, я сам переносил jQuery конец страницы, но не предал этому значения и проблем у меня не возникло.
>От PHP зависит скорость генерации страницы на сервере. Скорость загрузки страницы от этого зависит лишь частично, так как это лишь один из этапов загрузки страницы.
>Простите, но вы вообще не понимаете о чем говорите. "Перебор аргументов" происходит быстрее, чем браузер парсит ваш CSS.
Боюсь я не ясно изъяснился, под аргументами я имел виду кастомные переменные разных тем, которых нет если верстать страницу без дополнительных полей редактирования темы. Бекраунд, цвета, ширина и т.д., которые пользователь может менять в форме редактировании темы.
Конкретно тема Namo имеет очень много их, и много сторонних файлов которые подключаются в зависимости от выбранных параметров в админке.
Что касается скорости загрузки, я подразумеваю под ней время от клика до полного отображения, туда входит и генерация страницы. Почему я выбрал Namo? Потому, что имею достоверные данные о влиянии темы на производительность.
На хостинге 2 сайта с одинаковой посещаемостью, один с темой Namo, другой с версткой от меня. Ниже скриншот нагрузки на сервер за сегодня:
Иван Украинцев: и это правда, хотя это часто отрицают или не учитывают. Но пожалуй самая сильная нагрузка идет когда подключаются новые файлы, например страница может формировать из 4 файлов (например header.php page.php sidebar.php footer.php), а может из 30 и это тоже сильно влияет на скорость.
+ у каждой функции есть время ее выполнения, некоторые имеют 0.01 сек, это достаточно много.
Игорь Воротнёв:
> Для того, чтобы переменными на что-то повлиять, это надо сильно постораться наговнокодить так, чтобы были утечки памяти, чтобы рекурсии без выхода шли и тд.
А если эти переменные парсятся по нескольким другим php файлам? Например этих файлов 10.
После получения переменной сервер начинает парсить еще 30 файлов для получения php, wp функций и html разметки? Очень много тем построено таким образом.
Это не просто ЕСЛИ, так часто верстают темы на продажу.
Не говоря о том, что некоторые темы сразу подгружают весь CSS и JS вне зависимости от их использования.
Александр Голубев: Александр, я не буду писать подробности, достаточно отправить вас читать основы PHP. Вы говорите про каких-то 10 файлов, про какие-то переменные, но это все - микропоспические нюансы. Во время выполнения 1 запроса PHP загрузит несколько сотен (!) файлов WordPress, тем, плагинов, ваши 3-4, или 20-30 шаблончиков, из которых собирается страничка вообще НИКАКОЙ погоды не делают. Что реально влияет на скорость генерации страницы на сервере - так это количество запросов в БД, количество обращений по внешним http-запросам, количество обращей к файловой системе. Но тут такое количество нюансов, что все это не так просто - правильно настроенная серверная ОС кеширует дескрипторы файлов и целые файлы если надо, правильно настроенная БД существенно снижает нагрузку и тормоза, а при наличии объектного кеширования, большинство запросов до БД вообще не доходят и тд. То, что вы уперлись в количество настроек темы и количество шаблонов вообще никак не влияет на скорость. Ну, влияет, но микроскопически, не парьтесь об этом. То, что могут быть криво написанные "настройки темы", которые будут дергать постоянно базу данных и не кешировать запросы - вот это другая история. То есть, проблема не в самих настроках (по-вашему "переменных") и их количестве, не в количестве шаблонов, а в общем качестве кода.
Иван Украинцев: это маловероятно, разве что для вычисления значения этих переменных берутся из БД (мимо кеша) или по http-протоколу с других серверов (например, по АПИ получается курс валют и тд). Если речь просто о 10-15 переменных, значения которых корректно определены, то такой код в 100-150 строк и на 10-15 переменных выполнится в мгновенье ока.
Ребята, вы делаете 2 ключевые ошибки:
- сравниваете теплое с горячим (статику и динамику)
- не понимая как работает PHP (да и любой серверный язык) делаете выводы на основании только того, что вы видите перед глазами
Александр Голубев: А вот с этим я и не спорю, полностью согласен :) Просто причина не в переменных/шаблонах, а в кривости рук, в говнокоде, в использовании тяжелых, непродуманных архитектурных решений и тд. Мне доводилось "допиливать" эти платные темы "все-в-одном", это ад.
Александр Голубев: смотрите лицензию. Если чистый GPL на все (включая CSS) - можете делать что хотите. Если split license (часть GPL, часть охраняется) - тогда надо смотреть что нельзя использовать. Но это если вы являетесь законным обладателем лицензии. Если это платная тема, которую вы не покупали, то не уверен, что можно использовать. Надо у юристов спросить.
Игорь Воротнёв: Должен быть какой то файл лицензии приложен к теме?
"защитить свой дизайн"
на themeforest.net/category/psd-templates продаются psd исходники, кода там нет, только визуальный дизайн. Если кто-то использует эти исходники не оплатив, это вообще можно как то отследить? И предъявить иск?
Александр Голубев: да, лицензия в самом архиве с файлами, и на страничке товара будет указана.
> Если кто-то использует эти исходники не оплатив,
а откуда тогда исходник взяли? он же не лежит в открытом доступе
> можно как то отследить? И предъявить иск?
Автоматически как-то - вряд ли. Но в принципе можно и отследить, хотя сложно. Предъявить иск - да, можно. Но долго и муторно, дорого (по расходам). Из-за плагиата дизайна странички никто не будет заморачиваться. Разве что вы этот дизайн впарите какому-то очень крупному клиенту. Тогда потягаться по судам будет иметь смысл.
> я могу сделать ее репродукцию по скриншоту и продать клиенту, это вообще законно?
Юридически это называется плагиатом, нарушением авторских прав. Так что не совсем законно.
Александр Голубев: Вы не совсем понимаете как работает лицензирование. Посмотреть в полном размере вы можете пример макета (JPG с фотографиями и какими-то текстами). Сам макет (PSD) вы можете получить только заплатив за него денег. И только когда вы заплатили, на вас распространяется действие лицензии. Если же вы просто берете JPG и на ее основе рисуете свой дизайн - это в любом случае нарушение авторских прав и плагиат. Незаконно. Другой вопрос, что шансы быть пойманным не очень велики. С другой стороны, риск все-таки есть, и если вдруг автор обнаружит воровство (или кто-то другой обнаружит и сообщит ему) - тогда автор просто свяжется с вашим клиентом чтобы уточнить, естьли у него купленная лицензия. Клиент задаст этот вопрос вам. И вы сядете в лужу. Клиенту гемор и суды не нужны, поэтому ему придется либо снять этот дизайн, либо заплатить автору неустоечку. В любом случае, для вас это нехорошо - клиент вряд ли будет рад такому развитию событий.
Александр Голубев: самое важное, что у нас люди не понимают - любая картинка в интернете из-за того, что она в открытом доступе, автоматически не является "бесплатной". Как раз наоборот - все по определению охраняется законом об авторском праве, если только обратное прямо не указано и не сопровождается соответствующей лицензией (Creative Commons, MIT, Apache, GPL и тд).
Игорь Воротнёв: Меня это интересует с точки зрения защиты, если я опубликую в своем портфолио например по типу Behance или dribbble, это будет является подтверждением моего авторства?
О себе вот тут такой рассказ. Бит среди терабайтов
Мне очень нравится, когда я на своем ужасном мобильном интернете могу зайти на страницу за 0.4 секунды, там начинает сразу отображаться какой-то контент. Да, там потом картинки подгружаются, это мелочи. Весь прикол в том, что когда идет запрос от браузера - сервер отдает файл, а не выполняет жуткий запрос генерации страницы из php хуков wordpress'a.
А причём тут пхп к генерации страницы на клиенте?)
На пхп это решается кэшем, а на клиенте полным отключением JS , минимумом всякой х-ни в виде переливающихся кнопочек на css. и загрузкой изображений после хтмл, это делается либо в css либо в html5
>чтобы все страницы с динамическим кодом сохранялись в статику и подгружалась уже она
поставьте плагин кэширования.
будет переводить все в статику и подгружать ее.
дальше копать в сторону оптимизации сервера/плагинов/шаблона. в интернете на эту тему огромное количество информации. одним комментарием не охватить.
разбейте задачу на более мелкие, задавайте вопросы конкретно по этим мелким задачам
Простой
