HTML だけで Shadow DOM を構築するための宣言型 Shadow DOM 2024.10.19 宣言型 Shadow DOM は `<template>` 要素を使用して Shadow DOM を構築する方法です。宣言型 Shadow DOM を使用することで、従来の JavaScript を使用した Shadow DOM の構築方法と比較して、サーバーサイドレンダリング（SSR）に対応しているため、パフォーマンスの向上や SEO 対策に期待されます。 Shadow DOM は Web Components を構成する 3 つの技術の 1 つです。Shadow DOM はコンポーネントのカプセル化を実現します。Shadow DOM で定義されたスタイルは Shadow DOM の外部に影響を与えず、また外部のスタイルの影響を受けません。 Shadow DOM は再利用可能なコン
MERJ and Vercel's research to demystify Google's rendering through empirical evidence. Understanding how search engines crawl, render, and index web pages is crucial for optimizing sites for search engines. Over the years, as search engines like Google change their processes, it’s tough to keep track of what works and doesn’t—especially with client-side JavaScript. We’ve noticed that a number of o
本記事は2022年11月に開催した「Tech-Verse 2022」で発表したセッションを要約したものです。アーカイブ動画を文末に掲載しています。質疑応答の様子も収録されていますのでぜひご覧ください。 ヤフーショッピングのフロントエンドを支える共通配信技術について、「共通UI配信サービス誕生までの経緯」と「共通UI配信サービスを支える技術」の2部構成で紹介します。 共通UI配信サービス誕生までの経緯 ヤフーショッピングには、トップ、検索、商品詳細、カート、レビュー、問い合わせ、製品、キャンペーン、ランキング、注文履歴などさまざまな画面があり、それに合わせてさまざまな開発チームが存在しています。 各チームでアプリケーションは独立していて、それぞれリンクで接続されています。共通UIのHTMLもアプリケーションが異なれば、それぞれに記述されます。同じアプリケーション内で共通UIを実装するのは簡単
The Future (and the Past) of the Web is Server Side Rendering When servers were in Swiss basements, all they had to serve was static HTML. Maybe, if you were lucky, you got an image. Now, a webpage can be a full-blown app, pulling in data from multiple sources, doing on the fly manipulations, and allowing an end-user full interactivity. This has greatly improved the utility of the web, but at the
Next.js x Relay な GraphQL 環境で Render-as-you-fetch の良さを最大限生かしつつ SSR にも対応したいあなたへRelayGraphQLNext.js はじめに 最近 Next.js ベースのプロジェクトに GraphQL クライアントとして Relay を導入したのですが、これが端的に言ってめちゃくちゃ大変だったので記事にしました。 チームの試行錯誤の結果を余すところなく伝えたいと張り切りすぎた結果死ぬほど長くなってしまったので、「いいからコードはよ」という方は 最終的にこんな実装になりました (コード編）をご覧ください。 謝辞 愛するチームメンバーのみんな。これまでの道のりで私を支え、愛してくれたみんながいなければ、この記事は完成できなかったと思う。 また、この記事が世に出せたのは、スーパーテクニカルアドバイザーである koichik さんの
この記事は Cloudflare Workers and micro-frontends: made for one another のブログを理解するためのに Qwik の基本的な概念について理解することを目的とした記事です。 上記ブログに関しては、@laiso さんがわかりやすく解説してくれています。 本記事が、これらの記事やブログを読んで Qwik に付いて深堀りしたくなった方のお役に立てれば幸いです。 また、後日私の方でも、上記記事の解説や補足を何かしらの方法でまとめたいと思っています。 2022/10/26 追記 上の宣言通り、スクラップにまとめました。 What is Qwik ? Qwikは builder.io によって作られた、フロントエンドライブラリです。 SSRをデフォルトとし、Cloudflare Workers などでのエッジレンダリングにも対応しています。 js
こんにちは。ソウゾウの Software Engineer の hiroppy です。「連載：「メルカリ Shops」プレオープンまでの開発の裏側」 の最後は、Web フロントエンドの紹介をしたいと思います。メルカリ Shops は既存のメルカリアプリの中に独立した Web アプリケーションとして動いています。本記事では、どのようなライブラリを選定し、どのようにアーキテクチャを設計してきたかを解説します。 なぜ Web なのか？ アプリの上で動いているのであれば、WebView ではなくても良いと感じる人はいると思います。今回採用した 1 つの理由としては、リリースが柔軟な点が挙げられます。iOS/Android の両方に対して開発サイクルを早めることが可能であり、また機能追加やバグ修正が容易です。どのように WebView で動いているかについては、6 日目のメルカリ Shops のため
I’ve struggled to find references to this online, but heard the name used multiple times this year when describing the approach outlined here. To the best of my knowledge, the "Component Islands" pattern was coined by Etsy's frontend architect Katie Sylor-Miller during a meeting we had in 2019. The general idea of an “Islands” architecture is deceptively simple: render HTML pages on the server, an
Fresh は Deno 製の Web フレームワークです。事前のビルドを必要せず、エッジでレンダリングを提供するという特徴があります。また Islands Architecture を採用しており、デフォルトではクライアントに JavaScript が配信されることがありません。 この記事では Fresh を使用して記事投稿サービスのチュートリアルを紹介します。 完成したサイトは以下のようになります。 ソースコードは以下のレポジトリから確認できます。 インストール Fresh を始めるには Deno の v1.22.3 バージョン以降が必要です。Deno をまだインストールしたことがないのならば、installation を参考に Deno をインストールしましょう。 # Shell (Mac, Linux) $ curl -fsSL https://deno.land/install.
English version: Implementing Dynamic Rendering for Search Engines on pixiv.net - pixiv inside pixivでプロダクトマネージャーをしているmu-koです。 大規模サービスのpixivで検索エンジン向けにDynamic Rendering（ダイナミックレンダリング）を2019年から実装し始めました。Dynamic Rendering実装の経緯や検証方法、注意点などをご紹介します。 pixivとは pixivはクリエイターがイラスト・マンガ・小説を投稿し、声援をもらうことができるサービスです。 2019年9月時点で登録ユーザーは4,000万ユーザー超、投稿作品数は8,500万作品あります。また、日本からのアクセスは約60％で日本以外の国からのアクセスが約40％です。 日本国外のユーザーが作品を簡単に
uiu です。 前回の記事 『なぜ Next.js をやめたのか？』 では、Reactベースのウェブフロントエンドで、サーバーサイドレンダリング(SSR)をしない選択をすることで、アーキテクチャをシンプルに保っているという話を紹介しました。 アーキテクチャをシンプルに保つ工夫のおかげで、ウェブとアプリのコード共通化が簡単になり、1人のエンジニアが最小限の労力で複数プラットフォームに変更を入れることが可能になっています。 Dynamic Rendering はスケールしないのでは？メンテが大変なんでは？ という質問があったので、今回は実際どのように Dynamic Rendering を運用しているかについて紹介したいと思います。 結論を簡単に言うと、キャッシュが効くためサーバーコストは高くなく、またサーバーレス環境で動いてるため運用のメンテナンスコストも低いです。 サーバーコストは当然 S
Wantedly でバックエンドエンジニアをしている @izumin5210 です。 この記事は GraphQL Advent Calendar 2020 の11日目の記事として書かれました。が、7割くらいは SSR についての議論のこり3割くらいが Apollo Client の話です。 最近、Apollo Client と SSR(Server Side Rendering) を利用した Web アプリケーションのパフォーマンス改善に取り組みました。この記事では「パフォーマンスの問題にどう立ち向かったか」および「そもそも問題を起こさない構造にするために何ができるか・何をすべきでないか」の考察をしていきます。 TL;DRパフォーマンス改善は計測・可視化からライブラリが用意してくれているフック機構を上手に使って計測していこうrenderToStringWithData では、renderT
はじめに 私の仕事は、新規サービスをまるっといい感じに開発するのを委託されることがほとんどです。最近はネイティブアプリを作ることよりもブラウザで動くWebサービスを開発することが多いのですが、案件の規模感や要求によって技術選定を少し変えるようにしています。「こういうときはこう」みたいに一概には言えないのですが、普段使う構成を紹介します。誰かの参考になれば幸いです。 2022/02/10 現在での内容です。 前提 開発を委託される場合の運用費をどうするの問題があります。クライアントにクレカ登録をしてもらうか、こちらで支払って毎月請求するかになります。僕は毎月やるのがめんどくさいのでできるだけ前者に倒している関係上、あまりいろいろなSaaSを組み合わせて作ることをなるべく避けています。 規模感によらず使っているもの 私の場合、以下が使えるとめちゃくちゃ効率よく開発できます。 GCP 好きだから
Next.js + Apollo Next.js の公式リポジトリには Apollo を使用する際のサンプルコードがあるが、 これらを参考に SSR するとかなりパフォーマンスが悪い。 with-apollo with-typescript-graphql 例えば、with-typescript-graphql の/pages/index.tsx を見てみる。 ... import { useViewerQuery, useUpdateNameMutation, ViewerDocument, } from '../lib/viewer.graphql' import { initializeApollo } from '../lib/apollo' const Index = () => { const { viewer } = useViewerQuery().data! ... re
Next.js には強力な Incremental Static Regeneration がありますが、Vercel 以外にホストしている場合は使うことができません。そのとき、Cache-Control や Surrogate-Control ヘッダを用いて Fastly のような CDN にキャッシュを持たせたくなります。 このヘッダの持たせ方に少しクセがあったので備忘録的に書きます。 例えば、/articles/[id] にヘッダを持たせたいとします。 方法1. next.config.js で設定 next.config.js の headers で設定する方法です。 const cacheHeaders = [ { key: 'Cache-Control', value: 'max-age=0', }, { key: 'Surrogate-Control', value: 'pu
Your shopping website is not an SPA. I repeat: your shopping website is not an SPA. Stop trying to sculpt David with a JS chainsaw and get yourself an HTML/CSS chisel.— Alex Russell (@slightlylate) 2021年8月10日 この主張、界隈（少なくとも自分の観測範囲）では割とよく見かけるし、なんか定期的に話題になるトピックなのかなーと。 まあ持論としてもコレには概ね同意しており、会社のスタンスとも相まって、常日頃からぼんやり考えてたりすることでもある。 で、そんな折にこのツイートを発見して、さらにそれに言及してる人々を見て、ふと自分でも現状を整理しておきたいなーという気持ちになったので筆を執った次第。
概要 2021/04/22に新しいWeb Componentsライブラリ、Lit(Lit 2.0)がリリースされ、同日ローンチイベントもYouTubeで生配信されました。 それに伴いPolymer ProjectがLitに改名されロゴが刷新されました。 ウェブサイトも新しく公開されました。チュートリアルとPlaygroundが刷新され、非常に便利になりました。 実装は https://github.com/lit/lit に公開されています。 LitElementとlit-htmlのおさらい 旧Polymer Project（Lit 1.0）では、lit-html(HTMLテンプレートライブラリ)とLitElement(Web Componentsを実装するためのライブラリ)の2つのライブラリが提供されていました。 LitElementにもテンプレート機能があったので、2つとも独立したライ
isomorphic tokyo meetup http://nodejs.connpass.com/event/13363/
こんにちは。delyでフロントエンドを担当している@all__userです。 今回はkurashiruでSSR（Server Side Rendering）を導入した事例についてご紹介したいと思います。 目次 目次 要約 経緯・背景 SSRの導入 SPAのSEO対策 SSRのコスト Rendertronの採用は見送り kurashiruのSSR構成 ルートメタフィールドを利用したデータ取得の仕組み 消極的SSRから積極的SSRへ まとめ 要約 SPAにしたい。SEOのことを考えるとSSRはしておきたい でも全然リソース足りない Railsを温存しつつスモールスタートでSSRできるようにした という内容です。 経緯・背景 kurashiruはもともとRails単体のアプリケーションでしたが、フロントエンドにVue.jsを採用し、現在では多くのページがSPAへと移行しました。 SPAではSEO
ng-japan で発表した Server Side Rendering の資料です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
