Русский
Русский
English
Статистика
Реклама

Статические сайты

Из песочницы Рендеринг на клиенте, на сервере и генерация статических сайтов

06.11.2020 20:04:29 | Автор: admin

Приветствую всех профессионалов и любителей сайтостроения! Предлагаю вашему вниманию перевод статьи "Client-Side Rendering vs Server-Side Rendering vs Static-Site Generation" от Malcolm Laing.


Фронтендеры часто используют эти термины для описания своих приложений. Однако людей, хуже знакомых с веб-технологиямм, эти понятия часто вводят в заблуждение. Если вам сложно понять различия между рендерингом на стороне клиенте, рендерингом на стороне сервера и генерацией статических сайтов эта статья для вас!


Рендеринг на стороне клиента


Рендеринг на клиенте стал популярен с расцветом технологии Single Page Application (Spa). Этот подход применяется во многих JavaScript фреймворках, например AngularJS, ReactJS, Backbone.JS и др. В приложениях с генерацией на клиенте сервер отправляет JS файлы и статичный HTML на сторону клиента. Затем клиент выполняет вызовы API в количестве, достаточном для того, чтобы получить исходные данные, и уже после этого приложение рендерится.


<!DOCTYPE html><html lang="en">  <head>    <meta charset="utf-8" />    <title>React App</title>  </head>  <body>    <noscript>You need to enable JavaScript to run this app.</noscript>    <div id="root"></div>  </body></html>

Как видно на примере выше, отданный сервером статичный HTML это пустая страница. Если открыть этот HTML с отключенным JS, результатом будет пустой экран с ворнингом, записанным в теге noscript. Когда клиент получает HTML и подгружает JS, в div с ID root отрендерится React-приложение.


Преимущества рендеринга на клиенте


  1. Приложения легко разрабатывать и хостить
    Вам не нужен сервер для приложений, рендерящихся на стороне клиента. Можно просто разместить свое приложение на любой CDN или файловом хостинге вроде Амазон. Есть множество бесплатных способов размещения.
  2. Не нужно полностью перезагружать страницы
    Пользователи могут переходить по страницам без серии обращений к серверу. Из-за этого создаётся ощущение высокой скорости работы, почти как у нативного приложения.

Недостатки рендеринга на клиенте


  1. Проблемы с SEO
    Приложения с рендерингом на клиенте часто сложно продвигать в поисковиках. Хотя Google заявляют, что индексируют сайты, рендерящиеся с помощью JS, они ранжируют эти сайты очень низко. Если ваш сайт загружается слишком долго, он может быть проиндексирован как пустая страница.
  2. Плохой UX на медленных устройствах
    На медленных ноутбуках и мобильных устройствах рендеринг на клиенте может замедлить загрузку на несколько секунд. Это может раздражать пользователей, и в результате они покинут страницу не дождавшись окончания загрузки.
  3. Долгая загрузка
    Приложения с рендерингом на стороне клиента выполняют дополнительный запрос к серверу с API для рендеринга. Соответственно, ваш сайт будет загружаться дольше, чем аналогичное статичное приложение или приложение с рендерингом на стороне сервера.

Рендеринг на стороне сервера


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


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


Преимущества рендеринга на стороне сервера


  1. Ускоренная загрузка
    Приложения с рендерингом на стороне сервера, загружаются быстрее, чем похожие приложения, которые рендерятся на клиенте. А поскольку сервер выполняет наиболее затратную часть работы, они также быстро загружаются на менее производительных устройствах.
  2. Намного лучшее SEO.
    Преимущества рендеринга на стороне сервера для SEO хорошо документированы. Google награждает сайты, которые загружаются быстрее, более высоким рейтингом страниц. У Google и других поисковых роботов не возникнет проблем с индексированием ваших веб-сайтов, отображаемых на стороне сервера.

Недостатки рендеринга на стороне сервера


  1. Дорого хостить
    По сравнению с приложениями, которые рендерятся на стороне клиента, хостинг приложений с серверным рендерингом стоит дороже. В результате каждого запроса к вашему серверу он должен будет выполнять вызовы API, а затем рендерить HTML перед его передачей на сторону клиента.
  2. Более сложная разработка
    Самостоятельная настройка рендеринга на стороне сервера с использованием React может оказаться непростой задачей. Однако это становится намного проще, если использовать один из предназначенных для этого фреймворков, например NextJS.

Генерация статических сайтов


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


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


Gatsby и NextJS два наиболее известных генератора статических сайтов, основанных на React. Hugo еще один пример чрезвычайно популярного генератора статических сайтов.


Преимущества создания статических сайтов


  1. Быстрая загрузка
    Поскольку HTML-файлы уже скомпилированы и готовы к использованию, статические сайты загружаются быстрее, чем сайты, с рендерингом на стороне клиента, и сайты с рендерингом на сервере. Вы можете (Примечание переводчика: в оригинальной статье предложение внезапно обрывается).
  2. Дешевый хостинг
    Поскольку ваш сайт просто состоит из множества HTML-файлов, вы можете использовать CDN или разместить свой сайт на любом файловом хостинга.

Недостатки создания статических сайтов


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

Лучшее из обоих миров NextJS


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

Подробнее..

Из песочницы Как я за вечер написал быструю CMS для статических сайтов по правилам бизнес-логики в одном файлике

15.10.2020 22:20:39 | Автор: admin

Не Wordpress-ом единым


Не Wordpress-ом единым

Рынок CMS длительное время оставался местом, где Wordpress, Joomla, Drupal тройка абсолютных лидеров. Эти прекрасные времена уже постепенно проходят, хотя WP, сбавляя в динамике появления новых сайтов, все ещё сохраняет лидерство. Не мудрено: активное сообщество, огромное количество плагинов. Но, эта статья вовсе не будет посвящена восходящим звёздам рынка систем управления контентом (привет, решениям на базе Laravel). Скорее даже, объектом нашего внимания будет черная материя, которая находится несколько в стороне. А именно барабанная дробь

Статические сайты


CMS для статических сайтов

Кому нужна статика в 2k20?


Рациональный вопрос! Казалось бы, времена телефонного интернета и Windows95 уже прошли, но спрос на статическую генерацию html кода вновь начинает набирать обороты. И всему виной корпорация добра, разумеется. Google PageSpeed тот самый великий и могучий Урфи В общем, именно этот измеритель производительности веб-страниц стал и двигателем прогресса мирового интернета, и головной болью всех веб-разработчиков, а уж тем более фрилансеров. Результаты измерений сего инструмента базируются на стандартах Google, а далече известно, что онные положено в основу ранжирования. Да и объективно, загрузка страницы более трёх секунд увеличивает количество отказов автоматически. Таким образом, статика становится одним из альтернативных решений на смену или в дополнение к динамической сборке страниц силой любой CMS, фреймворка либо самописных вариантов.

Хьюстон, у нас проблемы или мой случай


По долгу службы я занимаюсь обслуживанием множества проектов, среди которых есть парсеры, но и также решения в сфере e-commerce. На жизнь не жалуюсь, но возникла задачка не из разряда 2 класс, начальная школа. Я, как разработчик, и менеджер (а управление своим маленьким делом, как известно, требует навыков и из этой сферы), как это на польском dostaem si do martwego kta (попал в глухой угол, одним словом). Условие следующее: нужно написать в течение нескольких дней решение, которое должно просто устанавливаться и обслуживать любое количество статических страниц. Более того, администратор должен иметь возможность быстро удалять и добавлять такое решение на любой проект через FTP/SFTP соединение или даже если у него нет доступа к FTP/SFTP. С другой же стороны условием было то, что минимальная версия это PHP 5.6 и она должна поддерживаться также прекрасно, как и каждый более современный вариант.

Администратор должен


  1. удалять/добавлять/изменять страницы при помощи админки;
  2. глобально и быстро искать в контенте страниц (учитывая разные кодировки, языки;
  3. искать по названиям файлов;
  4. удалять/вставлять/изменять на всех страницах нужные элементы одним кликом из админки;
  5. решение должно быть простым как в установке, так и в удалении.

Cекьюрность не должна позволять использовать SQL инъекции либо какие-либо другие попытки вмешательства в работу.

Дополнительным обязательством была бы возможность использовать админ панель и все ее функции через API. Грубо говоря, при наличии таких админок на 50+ доменах, должен быть доступ к ним удалённо путем возможности делать запросы.

Чехия, вечер, лето, кофе


Крайне спокойные вечера в Крконошах только способствуют лени. Но, как говорит старая пословица, кто не работает

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

И да, чёрт возьми, я решил перенести в один файл уже устоявшийся подход в большинстве фреймворков ООП и MVC концепцию.

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

  • не забудем об аспекте роста потребностей клиента и параллельной надобности добавлять новые возможности к интерфейсам нашего веб-приложения;
  • проблемы с ментальным состоянием программиста хоть я и был согласен мириться с тем, что всё будущее этого проекта будет возложено исключительно на мои могучие плечи, но вряд ли я бы морально перенёс бесконечное усложнение процедурного решения и отсутствие внятной бизнес логики;
  • потребность возможной публикации проекта для всенародных масс такая надобность к моменту публикации сего опуса становится актуальной, поэтому лучше когда руки развязаны и будущую документацию можно оснастить вполне понятными даже не функциями, а структурами объектно-ориентированного мышления и разделения зон ответственности приложения на ярко выраженный фронт-энд, бэк-энд.

От баз было принято решение пока что отказаться по причине отсутствия какой-либо надобности, поэтому термин модель во всём, что выше это нереализованная концепция в моей архитектуре. Нереализованность здесь услужила хорошую службу, ведь SQL инъекция перестаёт быть возможна в принципе.

Структурирование


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

Каково же решение?


Интуитивно: файл разбиваем на структурные части вида: базовые системные классы в самом верху, контроллеры пониже, виды еще ниже, но и весь балет закрывают роуты. Каждая часть получила шапку из комментов с объяснением, дабы через время не забыть что здесь:

/** This is the part for routing*Additional information...*/

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

Попытка описать всё что можно не скажу, что соответствовал этому намерению до самого конца разработки, в конце концов, я лавировал между быстротой и читабельностью кода, но ключевые решения мне удалось сопроводить комментариями вида //to get static html.

Как сделан роутинг?


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

Исходя из упомянутой выше проблемы, я сделал класс для роутинга достаточно примитивным, но функциональным. Роутинг работает при помощи GET запросов конечно, не совсем эстетично, но сиюминутную потребность в быстрой реализации решает на 100%. Роутер стал единственной точкой входа для веб-приложения, что, как по мне, идеальное решение для простоты разработки. В этом классе происходит сборка фронт-энда и бэк-энда апликации и вывод return-ом сформированного HTML.

Вопрос: написал ли я велосипед?


Я склонен к подозрению, что подобные решения уже написаны в прошлом, но на момент июля 2020 ни английский, ни польский, ни чешский, ни русский с украинским не помогли мне найти что-то стоящее и применительное к моему случаю. Поэтому во мне включился создатель, и я от всей души проектировал решение актуальных задач бизнеса. Ведь, если есть проблема её нужно решить максимально быстро и экономно, да ещё и про качество не позабыть.

Наглядный пример производительности


Одна крайне известная CMS, имя которой не принято называть:



Моё решение:



Очевидно, что скорость получения первого байта также выше, как и все прочие показатели, связанные со скоростью загрузки, даже не буду демонстрировать количество запросов на front-end в классических CMS и в этом мини-решении.

Будет ли продолжение?


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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru