Это были абстрактные цифры, потому и написал, что в вакууме.
Не важно сколько весят все шаблоны, важно то, что при генерации страниц, зря занимается дискове место на сотни, а то и тысячи файлов, что тоже рождает свои проблемы, по деплою, перегенерации
Вот только проблема в том, что html-разметка в размере большинства сайтов занимает, наверное, второе место с конца. Сразу после robots.txt
Вот представьте, у вас магазин, в нем 10 000 товаров. Какой-то менеджер делает импорт товаров, новых, 2 000 и изменяет еще 1 000 старых, нужно просто так, сделать генерацию 3-х тысяч шаблонов + шаблоны связанных страниц.
3 тысяч страниц по одному шаблону. Вы же сами говоите, что это миллисекунды занимает. Если так уж не нравится, подождать целых 10 секунд, то можно и отложенный рендеринг сделать — при первом обращении.
Скрыть товар из продажи, что, дропать HTML шаблон?
Шаблон-то зачем? Одну страницу. Удалять или обновлять (ставить метку «нет в продаж»), или просто в подгружаемой цене это выдать — как угодно.
Он будет держать в кеше страницы, которые пользователи посещали, и сбрасывать кеш по необходимости, когда он протухает, это не требует никаких вычислительных мощностей для сервера и никак не замедляет работу деплоев и тд
Откуда он может знать, когда страница протухла, если это происходит в момент обновления данных в базе, о которой NGINX ни сном, ни духом? Разве что если делает каждый раз запрос к серверному коду для проверки, но тогда мы опять получаем, что и сервер нагружен, и логика какая-то дополнительная нужна (мы же не будем на каждый запрос заново генерировать страницу, верно? Иначе какой смысл в кэше)
Изменись у вас 1 атрибут, цена, артикул, да что угодно, вам нужно перерендерить 100500 шаблонов с этими данным. Это затратно по времени и в целом N+1 операция.
Как у товара может поменяться артикул? Какие 100500 шаблонов мне вдруг придётся менять при изменении одного товара?
В то время, когда кешируются данные (подготовленные к рендерингу, в нужном формате и тд) рендеринг занимает миллисекунды и выполняется только при необходимости, по факту
Ага, только скажите, что у вашего сайта случается чаще — обновление основной информации на странице или просмотр? Если просмотров хотя бы не в 100 раз больше, чем обновлений, то да, подход не для вас.
А подход по напихиванию 100500 динамических элементов в рендереную на сервере страницу я видел на реддите — настолько у них всё «отлично», что там даже комментарии одной страницей не посмотреть, а местами и вообще не больше 2-3 за раз.
Это неоптимально и в корни неверно. Кешировать надо данные, а не полный HTML страницы. Если прям очень хочется, можно включить кеширование на Nginx
…и он будет точно так же держать в кэше срендеренные файлы, только теперь вы ещё и контроль над инвалидацией потеряете.
P.S. Кстати, во многих серверных движках/CMS пре-рендеринг уже встроен. Причём, в достаточно динамических, вроде движков имиджборд.
Сам факт того, что данные размещены в БД делает их строго динамическими. Сколько бы раз в минуту/час/год данные не обновлялись, с точки зрения сайта они обновляются в непредсказуемый момент времени.
У вас сайт отдельно от CMS существует, что ли? Или пользователи руками в базе записи в таблицах правят? Почему вдруг этот момент непредсказуемый, если вы сами этот момент в своём приложении и обрабатываете, когда данные ы БД пишете? У вас же сайт, наверное, не простой интерфейс к чьей-то чужой БД?
Это как раз таки не правильно, потому что если хранить уже конечный результат выходит огромное дублирование и оверхед.
Дублирование чего? Если вы раз за разом отдаёте одно и то же, то ЭТО — дублирование и оверхед.
Не нужно складывать все в одну корзину, рендиринг это одна функция, данные другая, рендерить данные быстро, а получать данные нет, потому кеширование и оптимизацию решают проблему получения.
Ну, так и рассматривайте пре-рендеринг как прогретый файловый кеш с ручной инвалидацией, что не так?
Ради чего «предгенерация» ради названия товара и цвета шапки?
Ради название, описания, артикула, характеристик, хлебных крошек, меню, хедера, футера, разметки под эти и остальные блоки, карты магазинов, ссылок на скрипты и стили, аналитики и т.д…
Комментарии и отзывы, кстати, всё равно, обычно, предмодерируются, а цены меняются не руками в базе, а через CMS, которая вполне может запускать перегенерацию страницы. (А если прямо хочется руками в базе править, то можно повесить триггеры, помечающие данные «грязными»).
Если же вы про отдельные цены с персональными скидками, то такие чаще показываются уже в корзине. Которая рисуется джаваскриптом поверх готовой страницы.
Да, серверный код останется, но только там, где он нужен, а не на каждой странице, перерисовывая с нуля всю разметку на каждый запрос.
Именно, что если уж хранить все данные, на основе которых строится представление, то почему бы сразу не хранить представление? Если перевод данных в отображение — чистая функция, то нет смысла хранить отдельно функцию, а отдельно заранее аргументы её.
Нет, такое поведение было в Android 8, но уже начиная с Android 9 можно было включить рандомизацию и для подключений, а начиная с Android 10 случайный MAC-адрес для подключения к сети включен по умолчанию:
Spoiler header
Starting in Android 8.0, Android devices use randomized MAC addresses when probing for new networks while not currently associated with a network. In Android 9, you can enable a developer option (it's disabled by default) to cause the device to use a randomized MAC address when connecting to a Wi-Fi network.
In Android 10, MAC randomization is enabled by default for client mode, SoftAp, and Wi-Fi Direct.
MAC randomization prevents listeners from using MAC addresses to build a history of device activity, thus increasing user privacy.
Additionally, MAC addresses are randomized as part of Wi-Fi Aware and Wi-Fi RTT operations.
стесняюсь спросить, а как получить данные из api или бд, во время генерации, если нет серверного приложения с логикой и данными?..
Так приложение у вас будет, но оно будет генерировать статические страницы при билде, а не обрабатывать запросы клиентов.
мне кажется описан подход SPA(singe page application), где приложение можно самим с сервера отдавать как статику или в cdn положить.
Reply
В SPA страница одна (Single page), т.е., один HTML-файл, а вся разметка генерируется или подменяется динамически на клиенте. Тут же предлагают всю разметку генерировать заранее. Соответсственно, страниц может быть много.
перекладывать нагрузку на браузер, не самое оптимальное решение, в случае слабого интернета
Во-первых, по сравнению с SPA, тут нагрузка перекладывается на билд. Во-вторых, не наоборот ли, в случае слабого интернета как раз меньше запросов придётся делать?
у меня другое мнение и опыт. Сколько раз в публичных местах просил перестать материться — никто в драку не лез, в основном материться переставали.
Знаете, если вы о чём-то просите постороннего, и он вам без возражений оказывает эту услугу, то, может, это вовсе не такое уж не быдло, как вы описываете?
Я лично не хочу, чтобы рядом со мной какое-то быдло свободно разговаривало матом.
А если рядом с вами интеллигентный человек, профессор изящной словесности будет свободно разговаривать матом — то можно? Или вы всех, кто думает не как вы, заранее окрестили быдлом?
«Свобода одного заканчивается там, где начинается свобода другого», и проблема именно в том, где проходит граница между этими свободами. Вы хотите свободы не слышать мат, а ваш собеседник хочет свободы говорить матом. Чья свобода должна «кончаться» раньше?
Вот у нас нагрузка на сервер уже и не нулевая…
Вот просто один в один то же самое, что просто дёрнуть рендеринг. Только ещё и две прослойки лишних в виду редиса и кеша nginx.
3 тысяч страниц по одному шаблону. Вы же сами говоите, что это миллисекунды занимает. Если так уж не нравится, подождать целых 10 секунд, то можно и отложенный рендеринг сделать — при первом обращении.
Шаблон-то зачем? Одну страницу. Удалять или обновлять (ставить метку «нет в продаж»), или просто в подгружаемой цене это выдать — как угодно.
Ага, только скажите, что у вашего сайта случается чаще — обновление основной информации на странице или просмотр? Если просмотров хотя бы не в 100 раз больше, чем обновлений, то да, подход не для вас.
А подход по напихиванию 100500 динамических элементов в рендереную на сервере страницу я видел на реддите — настолько у них всё «отлично», что там даже комментарии одной страницей не посмотреть, а местами и вообще не больше 2-3 за раз.
P.S. Кстати, во многих серверных движках/CMS пре-рендеринг уже встроен. Причём, в достаточно динамических, вроде движков имиджборд.
Ну, так и рассматривайте пре-рендеринг как прогретый файловый кеш с ручной инвалидацией, что не так?
Комментарии и отзывы, кстати, всё равно, обычно, предмодерируются, а цены меняются не руками в базе, а через CMS, которая вполне может запускать перегенерацию страницы. (А если прямо хочется руками в базе править, то можно повесить триггеры, помечающие данные «грязными»).
Если же вы про отдельные цены с персональными скидками, то такие чаще показываются уже в корзине. Которая рисуется джаваскриптом поверх готовой страницы.
Да, серверный код останется, но только там, где он нужен, а не на каждой странице, перерисовывая с нуля всю разметку на каждый запрос.
В SPA страница одна (Single page), т.е., один HTML-файл, а вся разметка генерируется или подменяется динамически на клиенте. Тут же предлагают всю разметку генерировать заранее. Соответсственно, страниц может быть много.
«Свобода одного заканчивается там, где начинается свобода другого», и проблема именно в том, где проходит граница между этими свободами. Вы хотите свободы не слышать мат, а ваш собеседник хочет свободы говорить матом. Чья свобода должна «кончаться» раньше?