--- # System prepended metadata title: SPA e PWA — Single Page Application e Progressive Web App --- # 📘 SPA e PWA — Single Page Application e Progressive Web App ## Material Completo para Concursos — Estilo IDECAN > **Banca:** IDECAN | **Área:** Tecnologia da Informação | **Nível:** Analista > > ⚡ **Perfil da Banca:** Citado literalmente no edital UNILAB 2026. Prioridade **média** no Bloco 1 (Dev Core). A IDECAN cobra diferenças conceituais SPA×MPA×PWA, os 3 componentes obrigatórios do PWA, ciclo de vida do Service Worker e estratégias de cache por cenário. --- ## 📋 Índice 1. [MPA — Multi-Page Application](#1-mpa--multi-page-application-modelo-tradicional) 2. [SPA — Single Page Application](#2-spa--single-page-application) 3. [MPA vs SPA — Comparativo](#3-mpa-vs-spa--comparativo) 4. [SSR, SSG e Hydration](#4-ssr-ssg-e-hydration) 5. [Client-Side Routing e Code Splitting](#5-client-side-routing-e-code-splitting) 6. [PWA — Progressive Web App](#6-pwa--progressive-web-app) 7. [Service Worker — Ciclo de Vida](#7-service-worker--ciclo-de-vida) 8. [Web App Manifest](#8-web-app-manifest) 9. [Estratégias de Cache](#9-estratégias-de-cache) 10. [Pegadinhas e Pontos-Chave da IDECAN](#10-pegadinhas-e-pontos-chave-da-idecan) 11. [Questões Comentadas no Estilo IDECAN](#11-questões-comentadas-no-estilo-idecan) --- ## 1. MPA — Multi-Page Application (modelo tradicional) ### Como funciona No modelo **MPA**, cada navegação gera uma requisição HTTP ao servidor, que responde com uma página HTML **completa**. O navegador descarrega a página atual e carrega a nova inteiramente. ``` Usuário clica em link → Requisição HTTP ao servidor → Servidor gera e retorna HTML completo → Navegador recarrega a página inteira (flash branco) → Nova página é exibida ``` ### Características - Cada URL corresponde a um arquivo/rota no servidor que retorna HTML completo - Recarregamento total a cada navegação - SEO **nativo** — o servidor entrega HTML pronto para os crawlers - Mais simples de desenvolver para casos básicos - **Exemplos:** sistemas em PHP + Blade, JSP, Django templates, Ruby on Rails --- ## 2. SPA — Single Page Application ### Como funciona No modelo **SPA**, uma única página HTML é carregada na primeira visita com todo o JavaScript da aplicação. Navegações subsequentes são feitas via **JavaScript** (AJAX/Fetch) — só os dados mudam, a página **não é recarregada**. ``` Primeira visita: → Baixa app completa (HTML + JS bundle + CSS) → Renderiza UI inicial Navegações seguintes: → JS intercepta o clique no link → Busca apenas os dados necessários (JSON via API) → Atualiza apenas as partes do DOM que mudaram → URL muda via History API (sem req. ao servidor) ``` ### Frameworks SPA Populares - **React** (Meta/Facebook) — biblioteca de UI, Virtual DOM - **Angular** (Google) — framework completo, TypeScript - **Vue.js** — framework progressivo, MVVM - **Svelte** — compila para JS puro (sem Virtual DOM em runtime) ### SPA e Back-end — Separação de Responsabilidades ``` ┌─────────────────────────────┐ API REST/GraphQL ┌──────────────────────────┐ │ Front-end SPA │ ←────────────────────→ │ Back-end (API) │ │ React / Vue / Angular │ JSON via Fetch │ Spring Boot / Laravel │ │ - Renderiza UI │ │ - Retorna JSON │ │ - Gerencia estado │ │ - NÃO gera HTML │ │ - Roteamento no cliente │ │ - Reutilizável │ └─────────────────────────────┘ └──────────────────────────┘ ``` O back-end torna-se uma **API pura** — o mesmo back-end pode servir a SPA, apps mobile e terceiros. --- ## 3. MPA vs SPA — Comparativo | Característica | MPA | SPA | |---|---|---| | **Carregamento inicial** | Rápido (só a página atual) | Lento (baixa app inteira) | | **Navegação posterior** | Lenta (recarrega tudo) | Rápida (só dados JSON) | | **SEO** | Nativo (HTML pronto no servidor) | Desafiador (HTML gerado no cliente) | | **Experiência do usuário** | Flash a cada navegação | Fluida, sem recarregamento | | **Complexidade back-end** | Alta (gera HTML completo) | Baixa (só retorna JSON) | | **Complexidade front-end** | Baixa | Alta (framework JS obrigatório) | | **Roteamento** | Servidor | Cliente (History API) | | **Estado da aplicação** | No servidor (sessão) | No cliente (Redux, Zustand) | | **Exemplos** | PHP + Blade, JSP, Django | React, Angular, Vue | > ⚠️ **IDECAN cobra:** No SPA, o carregamento **inicial** é mais **lento** (baixa toda a aplicação JS). As navegações **subsequentes** são mais rápidas. O SEO é o principal **desafio** das SPAs — o HTML inicial está quase vazio, dificultando indexação por buscadores. --- ## 4. SSR, SSG e Hydration ### Por que existem — O problema de SEO do SPA O HTML inicial de uma SPA é quase vazio: ```html
``` Os crawlers de busca (Google, Bing) têm dificuldade para indexar conteúdo gerado por JavaScript. ### SSR — Server-Side Rendering O servidor **pré-renderiza** o HTML da SPA antes de enviar ao cliente. O usuário vê o conteúdo imediatamente e o JS assume o controle depois (hydration). ``` Cliente solicita /produto/123 → Servidor executa React/Vue no servidor → Gera HTML completo com os dados do produto → Envia HTML pronto ao cliente (SEO + velocidade) → JS do cliente faz hydration (torna a página interativa) ``` **Frameworks SSR:** Next.js (React), Nuxt.js (Vue), Angular Universal, SvelteKit ### SSG — Static Site Generation O HTML é gerado em **build-time** (não a cada requisição). Arquivos estáticos servidos por CDN — muito rápido. ``` Build: npm run build → gera /produto/1.html, /produto/2.html... Deploy: arquivos estáticos no CDN Requisição: CDN retorna HTML pré-gerado instantaneamente ``` **Ideal para:** blogs, documentação, landing pages (conteúdo que muda raramente). ### Hydration Processo onde o JavaScript do framework "ativa" o HTML estático pré-renderizado pelo servidor, tornando-o **interativo**. ``` 1. Servidor envia HTML pré-renderizado (página visível imediatamente) 2. Navegador recebe e exibe o HTML 3. JS da aplicação é baixado e executado 4. Framework "hidrata" — vincula eventos ao HTML existente 5. Página torna-se interativa (cliques, formulários funcionam) ``` > ⚠️ **IDECAN cobra:** SSR resolve o problema de SEO das SPAs gerando HTML no servidor. Next.js é o framework SSR mais cobrado no contexto de React. --- ## 5. Client-Side Routing e Code Splitting ### History API — Roteamento no Cliente ```javascript // O SPA usa a History API do navegador para mudar URLs sem recarregar // Adiciona uma entrada no histórico de navegação history.pushState({ pagina: 'produtos' }, '', '/produtos'); // Substitui a entrada atual (sem criar nova entrada no histórico) history.replaceState({ pagina: 'home' }, '', '/'); // Evento disparado ao clicar "Voltar"/"Avançar" no navegador window.addEventListener('popstate', (event) => { console.log('Navegou para:', event.state); }); ``` ### React Router — Roteamento em React ```jsx import { BrowserRouter, Routes, Route, Link } from 'react-router-dom'; function App() { return ( {/* Link não recarrega a página — usa pushState internamente */} Produtos Sobre } /> } /> } /> } /> ); } // Ao clicar no Link, a URL muda mas a página NÃO é recarregada ``` ### Code Splitting — Dividindo o Bundle **Problema:** SPAs podem ter bundles JS enormes (MBs), tornando o carregamento inicial muito lento. **Solução:** dividir o código em partes (chunks) que são baixadas **sob demanda**. ```jsx import React, { lazy, Suspense } from 'react'; // Carregamento lazy — o módulo só é baixado quando a rota é acessada const DetalheProduto = lazy(() => import('./pages/DetalheProduto')); const Relatorios = lazy(() => import('./pages/Relatorios')); function App() { return ( Carregando...}> } /> } /> ); } // DetalheProduto.js só é baixado quando o usuário navega para /produto/... ``` --- ## 6. PWA — Progressive Web App ### O que é PWA **PWA (Progressive Web App)** é um conjunto de **tecnologias e padrões** que permitem que uma aplicação web ofereça experiência similar a um app nativo: funciona offline, pode ser instalada na tela inicial e recebe notificações push. Termo cunhado por Alex Russell (Google) em 2015. ### Os 4 Pilares do PWA | Pilar | Descrição | |---|---| | **Confiável** | Funciona offline ou com rede instável. Service Worker cacheia recursos essenciais. | | **Rápido** | Responde imediatamente às interações. Assets cacheados localmente. | | **Envolvente (Engaging)** | Instalável na tela inicial. Push Notifications. Fullscreen. Experiência app-like. | | **Segura** | HTTPS obrigatório. Service Worker só funciona em origens seguras. | ### Os 3 Componentes Obrigatórios do PWA ⭐ ``` PWA = HTTPS + Service Worker + Web App Manifest ``` 1. **HTTPS** — obrigatório para segurança; pré-requisito para o Service Worker funcionar 2. **Service Worker** — script em background que habilita offline e cache 3. **Web App Manifest** — arquivo JSON que permite instalação e define aparência > ⚠️ **IDECAN cobra:** Os 3 componentes são **HTTPS + Service Worker + Web App Manifest**. A ausência de qualquer um impede que a aplicação seja classificada como PWA completo. HTTPS é pré-requisito para o Service Worker funcionar. ### PWA vs App Web vs App Nativo | Característica | App Web | PWA | App Nativo | |---|---|---|---| | **Funciona offline** | Não | Sim | Sim | | **Instalável** | Não | Sim (tela inicial) | Sim (App Store) | | **Push Notifications** | Não | Sim | Sim | | **Distribuição** | URL | URL (sem App Store) | App Store / Play Store | | **Atualização** | Automática | Automática | Manual (aprovação) | | **Acesso a hardware** | Limitado | Parcial (câmera, GPS) | Completo | | **Performance** | Menor | Boa | Máxima | > ⚠️ **IDECAN cobra:** PWA **não precisa** de App Store/Play Store para ser instalado — é instalado diretamente pelo navegador a partir da URL. Esta é uma das principais vantagens sobre apps nativos. --- ## 7. Service Worker — Ciclo de Vida ### O que é Service Worker Script JavaScript que roda em uma **thread separada** da página (background), **sem acesso ao DOM**. Atua como um **proxy de rede** — intercepta todas as requisições feitas pela aplicação e decide o que fazer: buscar da rede, retornar do cache, ou combinar ambos. ### Características Importantes - Roda em **background**, mesmo com a página fechada - **Não tem acesso ao DOM** — usa `postMessage` para comunicar com a página - Só funciona em **HTTPS** (exceto localhost para desenvolvimento) - É um Worker baseado em **eventos** (event-driven) - Tem acesso à **Cache API** para armazenar requisições/respostas ### Ciclo de Vida Completo ⭐ #### Fase 1 — Registration (Registro) ```javascript // Na página principal (index.html ou App.js) if ('serviceWorker' in navigator) { navigator.serviceWorker .register('/sw.js') // caminho para o arquivo do SW .then(reg => console.log('SW registrado, escopo:', reg.scope)) .catch(err => console.error('Falha no registro:', err)); } ``` #### Fase 2 — Install (Instalação) — momento do pre-caching ```javascript // Dentro do arquivo sw.js const CACHE_NAME = 'meu-app-v1'; const ARQUIVOS_PARA_CACHE = [ '/', '/index.html', '/app.js', '/styles.css', '/icons/logo.png' ]; self.addEventListener('install', event => { console.log('SW: instalando...'); event.waitUntil( caches.open(CACHE_NAME) .then(cache => { console.log('SW: realizando pre-caching dos arquivos essenciais'); return cache.addAll(ARQUIVOS_PARA_CACHE); }) ); // self.skipWaiting() força ativação imediata (pula a espera) }); ``` #### Fase 3 — Activate (Ativação) — momento da limpeza ```javascript self.addEventListener('activate', event => { console.log('SW: ativando...'); event.waitUntil( caches.keys().then(nomesDeCache => Promise.all( nomesDeCache .filter(nome => nome !== CACHE_NAME) // caches de versões antigas .map(nome => { console.log('SW: removendo cache antigo:', nome); return caches.delete(nome); }) ) ) ); // self.clients.claim() faz o SW assumir controle imediatamente }); ``` #### Fase 4 — Fetch (Operação Normal) — interceptação de requisições ```javascript self.addEventListener('fetch', event => { event.respondWith( caches.match(event.request) .then(respostaDoCche => { if (respostaDoCche) { return respostaDoCche; // retorna do cache } return fetch(event.request); // busca na rede }) ); }); ``` ### Outros Eventos do Service Worker | Evento | Quando dispara | Uso | |---|---|---| | `push` | Mensagem push recebida do servidor | Exibir notificação push | | `notificationclick` | Usuário clica na notificação | Abrir URL específica | | `sync` | Conexão restabelecida | Background Sync — enviar dados enfileirados offline | | `message` | Página envia postMessage | Comunicação bidirecional com a página | ### Resumo do Ciclo de Vida ``` Register → Install (pre-caching) → Activate (limpar caches antigos) ↓ Fetch (interceptar requisições) Push (notificações) Sync (background sync) ``` > ⚠️ **IDECAN cobra:** A ordem é **Register → Install → Activate → Fetch**. O evento **install** é para **pre-caching**. O evento **activate** é para **limpeza de caches antigos**. O evento **fetch** intercepta requisições em operação normal. --- ## 8. Web App Manifest ### O que é Arquivo **JSON** (`manifest.json`) que fornece informações sobre o PWA ao navegador e ao SO: nome, ícones, cores, modo de exibição. Permite que o usuário **instale o app** na tela inicial com aparência nativa. ### Exemplo Completo ```json { "name": "Meu App Completo", "short_name": "MeuApp", "description": "Aplicação PWA de exemplo para concurso", "start_url": "/", "scope": "/", "display": "standalone", "orientation": "portrait", "background_color": "#ffffff", "theme_color": "#1D9E75", "lang": "pt-BR", "icons": [ { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png", "purpose": "any maskable" }, { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png" } ], "shortcuts": [ { "name": "Novo Pedido", "url": "/pedidos/novo", "icons": [{ "src": "/icons/new.png", "sizes": "96x96" }] } ] } ``` ### Propriedade `display` — Modos de Exibição ⭐ | Valor | Descrição | Uso | |---|---|---| | **`standalone`** | Remove barra de endereço. Mantém barra de status do SO. Parece app nativo. | **Mais comum em PWAs** | | `fullscreen` | Remove toda a UI do navegador e do SO. Tela inteira. | Jogos | | `minimal-ui` | Controles mínimos de navegação (voltar, recarregar). Sem barra de endereço. | Intermediário | | `browser` | Abre no navegador normalmente, com interface completa. | Padrão — sem experiência app-like | > ⚠️ **IDECAN cobra:** O modo **`standalone`** é o que dá a experiência "app-like" ao PWA — remove a barra de endereço do navegador. É o valor mais cobrado. `fullscreen` é para jogos e remove absolutamente tudo. ### Como Referenciar no HTML ```html ``` --- ## 9. Estratégias de Cache ### Cache API — Armazenamento de Requisições ```javascript // Abrir/criar um cache pelo nome const cache = await caches.open('meu-cache-v1'); // Armazenar uma resposta manualmente await cache.put(request, response); // Buscar e armazenar automaticamente await cache.add('/pagina.html'); await cache.addAll(['/app.js', '/styles.css', '/logo.png']); // Buscar no cache const resposta = await cache.match(request); // Remover um item await cache.delete(request); // Listar todos os caches existentes const nomesDosCaches = await caches.keys(); // Deletar um cache inteiro await caches.delete('meu-cache-v1'); ``` ### As 5 Estratégias de Cache ⭐ #### 1. Cache First (cache → rede) Busca no cache primeiro. Se não encontrar, vai à rede. Ideal para assets **estáticos** que raramente mudam. ```javascript self.addEventListener('fetch', event => { event.respondWith( caches.match(event.request).then(cached => { return cached || fetch(event.request).then(response => { // opcional: salvar no cache ao buscar da rede caches.open(CACHE_NAME).then(cache => cache.put(event.request, response.clone())); return response; }); }) ); }); ``` **Quando usar:** imagens, fontes, CSS, JS da aplicação, ícones. #### 2. Network First (rede → cache) Tenta a rede primeiro. Se falhar (offline), usa o cache como fallback. ```javascript self.addEventListener('fetch', event => { event.respondWith( fetch(event.request) .then(response => { // salva a resposta no cache para uso offline const responseClone = response.clone(); caches.open(CACHE_NAME).then(cache => cache.put(event.request, responseClone)); return response; }) .catch(() => caches.match(event.request)) // fallback offline ); }); ``` **Quando usar:** feeds de notícias, dados de perfil, conteúdo dinâmico que precisa estar atualizado. #### 3. Stale While Revalidate Retorna do cache **imediatamente** (rápido) e, em paralelo, atualiza o cache com a versão mais recente da rede. Na próxima requisição, o conteúdo já estará atualizado. ```javascript self.addEventListener('fetch', event => { event.respondWith( caches.open(CACHE_NAME).then(cache => cache.match(event.request).then(cached => { // atualiza o cache em segundo plano const networkFetch = fetch(event.request).then(response => { cache.put(event.request, response.clone()); return response; }); // retorna o cache imediatamente (se existir) ou aguarda a rede return cached || networkFetch; }) ) ); }); ``` **Quando usar:** avatares de usuário, páginas que mudam com frequência moderada, APIs que toleram dados ligeiramente desatualizados. #### 4. Cache Only Sempre usa o cache. Nunca vai à rede. Para recursos **pre-cacheados** no install que não mudam. ```javascript self.addEventListener('fetch', event => { event.respondWith(caches.match(event.request)); }); ``` **Quando usar:** app shell (HTML/CSS/JS core), assets de versão fixada. #### 5. Network Only Sempre usa a rede. Nunca cacheia. Para requisições que **não devem** ser cacheadas. ```javascript self.addEventListener('fetch', event => { event.respondWith(fetch(event.request)); }); ``` **Quando usar:** analytics, pagamentos, dados em tempo real críticos, requisições POST de escrita. ### Tabela de Decisão — Qual Estratégia Usar? | Cenário | Estratégia Recomendada | |---|---| | Imagens, fontes, CSS, JS | Cache First | | Feed de notícias, dados dinâmicos | Network First | | Perfil do usuário, thumbnails | Stale While Revalidate | | HTML/CSS do app shell (core) | Cache Only | | Pagamentos, analytics, POST | Network Only | | Offline + dados mais recentes possíveis | Network First | | Velocidade máxima + eventual atualização | Stale While Revalidate | > ⚠️ **IDECAN cobra:** Questões apresentam cenários e pedem qual estratégia aplicar. "Usuário offline, precisa ver último conteúdo" → **Network First**. "Assets estáticos, raramente mudam" → **Cache First**. "Equilíbrio velocidade + atualização" → **Stale While Revalidate**. ### Workbox — Biblioteca do Google para Service Workers ```javascript import { registerRoute } from 'workbox-routing'; import { CacheFirst, NetworkFirst, StaleWhileRevalidate } from 'workbox-strategies'; import { ExpirationPlugin } from 'workbox-expiration'; // Imagens — Cache First com expiração de 30 dias registerRoute( ({ request }) => request.destination === 'image', new CacheFirst({ cacheName: 'imagens', plugins: [new ExpirationPlugin({ maxAgeSeconds: 30 * 24 * 60 * 60 })] }) ); // API REST — Network First registerRoute( ({ url }) => url.pathname.startsWith('/api/'), new NetworkFirst({ cacheName: 'api-cache' }) ); // CSS e JS — Stale While Revalidate registerRoute( ({ request }) => request.destination === 'style' || request.destination === 'script', new StaleWhileRevalidate({ cacheName: 'assets' }) ); ``` --- ## 10. Pegadinhas e Pontos-Chave da IDECAN ### ❌ Afirmações FALSAS (distratores clássicos) 1. ~~"No SPA, o carregamento inicial é mais rápido que no MPA"~~ → **FALSO**. O carregamento **inicial** do SPA é mais **lento** (baixa toda a aplicação JS). As navegações **subsequentes** são mais rápidas. 2. ~~"Um PWA precisa ser publicado na App Store ou Google Play para ser instalado"~~ → **FALSO**. PWA é instalado **diretamente pelo navegador** a partir da URL, sem loja de apps. 3. ~~"O Service Worker tem acesso direto ao DOM para manipulá-lo"~~ → **FALSO**. Service Worker **não tem acesso ao DOM** — roda em thread separada. Para comunicar com a página usa **`postMessage`**. 4. ~~"Service Workers podem ser registrados em origens HTTP simples"~~ → **FALSO**. Service Workers **só funcionam em HTTPS** (exceto localhost para desenvolvimento). 5. ~~"O evento 'install' do SW é o momento para limpar caches antigos"~~ → **FALSO**. Limpeza de caches antigos deve ocorrer no **'activate'**. O **'install'** é para **pre-caching** dos arquivos essenciais. 6. ~~"O modo 'fullscreen' no manifest é o mais usado para dar experiência app-like"~~ → **FALSO**. O modo mais comum em PWAs é **'standalone'**. `fullscreen` é para jogos. 7. ~~"Cache First é ideal para APIs REST com dados dinâmicos"~~ → **FALSO**. Cache First é para **assets estáticos**. Para APIs dinâmicas usa-se **Network First** ou Stale While Revalidate. 8. ~~"SPA e PWA são a mesma coisa"~~ → **FALSO**. São conceitos **independentes e complementares**. SPA = arquitetura de navegação. PWA = conjunto de tecnologias para offline/app-like. Um SPA pode ou não ser um PWA. 9. ~~"O carregamento SSR é exclusivo de MPAs — SPAs não podem usar SSR"~~ → **FALSO**. **Next.js** e **Nuxt.js** fazem SSR de SPAs React e Vue, respectivamente, resolvendo o problema de SEO. 10. ~~"Service Worker é um componente opcional do PWA"~~ → **FALSO**. Service Worker é um dos **3 componentes obrigatórios** — sem ele não há offline e a aplicação não é um PWA completo. ### ✅ Afirmações VERDADEIRAS (fixe!) 1. Os 3 componentes obrigatórios do PWA são **HTTPS + Service Worker + Web App Manifest**. 2. O ciclo de vida do Service Worker é **Register → Install → Activate → Fetch**. 3. O evento **`install`** é o momento do **pre-caching** (cachear assets essenciais). 4. O evento **`activate`** é o momento de **limpar caches antigos**. 5. O modo **`standalone`** no manifest remove a barra de endereço e dá experiência app-like. 6. SPA tem SEO desafiador porque o HTML inicial está quase vazio — conteúdo é gerado por JS no cliente. 7. **Next.js** resolve o SEO das SPAs React usando SSR (Server-Side Rendering). 8. **Stale While Revalidate**: retorna do cache imediatamente E atualiza o cache em segundo plano. 9. PWA não requer App Store — é instalado pelo navegador diretamente a partir da URL. 10. Service Worker só funciona em **HTTPS** (ou localhost para desenvolvimento). 11. **Code splitting** divide o bundle JS em chunks carregados sob demanda — reduz tempo de carregamento inicial do SPA. 12. No Web App Manifest, o campo **`start_url`** define qual URL abre quando o usuário lança o app instalado. --- ## 11. Questões Comentadas no Estilo IDECAN --- ### Questão 1 **Qual é a principal diferença entre SPA e MPA no carregamento de páginas?** - A) No SPA, cada navegação gera uma requisição HTTP que retorna HTML completo do servidor. - B) No SPA, uma única página HTML é carregada inicialmente e o JS atualiza o DOM com dados via AJAX; no MPA, cada navegação recarrega a página completa do servidor. - C) SPA e MPA são equivalentes — a diferença é apenas o framework utilizado. - D) No SPA, o SEO é mais eficiente que no MPA porque o conteúdo é gerado no cliente. - E) No MPA, o JavaScript controla toda a navegação sem recarregar páginas.
🔎 Ver resposta e comentário **✅ Resposta: B** **Comentário:** No SPA, uma única página HTML é carregada com todo o JavaScript. Navegações subsequentes atualizam apenas partes do DOM via AJAX/Fetch, sem recarregar a página. No MPA, cada clique gera uma requisição HTTP ao servidor que retorna HTML completo — a página recarrega inteiramente. O SEO é o principal **desafio** (não vantagem) do SPA, pois o HTML inicial está quase vazio.
--- ### Questão 2 **Quais são os 3 componentes obrigatórios para que uma aplicação seja classificada como PWA completa?** - A) React.js, Service Worker e localStorage - B) HTTPS, Service Worker e Web App Manifest - C) Service Worker, WebSocket e IndexedDB - D) Web App Manifest, Push Notifications e HTTPS - E) Angular, Service Worker e Cache API
🔎 Ver resposta e comentário **✅ Resposta: B** **Comentário:** Os 3 componentes obrigatórios são: (1) **HTTPS** — obrigatório para segurança e pré-requisito do Service Worker; (2) **Service Worker** — proxy de rede que habilita offline e cache; (3) **Web App Manifest** — arquivo JSON que permite instalação e define aparência app-like. React, WebSocket, Push Notifications e IndexedDB são opcionais. A alternativa D troca Service Worker por Push Notifications, que é apenas uma funcionalidade do SW.
--- ### Questão 3 **Sobre o Service Worker, assinale a alternativa CORRETA:** - A) O Service Worker tem acesso direto ao DOM para atualizar elementos da página. - B) O Service Worker pode ser registrado em origens HTTP simples para facilitar o desenvolvimento. - C) O Service Worker roda em thread separada, sem acesso ao DOM, e intercepta requisições de rede. - D) O Service Worker substitui o localStorage para armazenamento persistente offline. - E) O Service Worker é executado na mesma thread da página, compartilhando o contexto JavaScript.
🔎 Ver resposta e comentário **✅ Resposta: C** **Comentário:** O Service Worker roda em uma thread separada (background), completamente independente da página. **Não tem acesso ao DOM** — usa `postMessage` para comunicar com a página. Intercepta requisições de rede (evento `fetch`) e decide o que retornar (cache ou rede). Só funciona em **HTTPS** (exceto localhost). Não é substituto do localStorage — é um proxy de rede com Cache API.
--- ### Questão 4 **No ciclo de vida do Service Worker, em qual evento deve ser realizado o pre-caching dos arquivos essenciais da aplicação?** - A) No evento `register` — antes de instalar o SW - B) No evento `install` — quando o SW é instalado pela primeira vez - C) No evento `activate` — quando o SW assume o controle das páginas - D) No evento `fetch` — quando a primeira requisição é interceptada - E) No evento `push` — quando uma notificação push é recebida
🔎 Ver resposta e comentário **✅ Resposta: B** **Comentário:** O evento **`install`** é disparado quando o Service Worker é instalado pela primeira vez — é o momento ideal para o **pre-caching** dos arquivos essenciais (HTML, CSS, JS, ícones) usando `event.waitUntil()` com `caches.addAll()`. O evento **`activate`** é para limpar caches de versões anteriores. O evento **`fetch`** é para interceptar requisições durante o uso normal.
--- ### Questão 5 **Uma aplicação de notícias deve exibir conteúdo atualizado sempre que online, mas também mostrar as últimas notícias quando offline. Qual estratégia de cache é mais adequada?** - A) Cache First — retorna do cache, nunca vai à rede - B) Cache Only — usa apenas o cache pré-definido - C) Network First — tenta a rede primeiro, usa o cache como fallback quando offline - D) Stale While Revalidate — retorna do cache e atualiza em segundo plano - E) Network Only — sempre usa a rede, sem fallback
🔎 Ver resposta e comentário **✅ Resposta: C** **Comentário:** **Network First** é a estratégia correta para conteúdo dinâmico (notícias) que precisa estar atualizado quando online, mas disponível offline. O SW tenta a rede primeiro — com conexão, retorna dados frescos e atualiza o cache. Sem conexão, usa o cache como fallback. Cache First priorizaria dados antigos mesmo com internet. Stale While Revalidate retornaria o cache imediatamente (possivelmente desatualizado) mesmo estando online.
--- ### Questão 6 **Sobre o campo `display` no Web App Manifest, qual valor remove a barra de endereço do navegador e dá ao PWA aparência de aplicativo nativo?** - A) `fullscreen` — remove toda a UI do navegador e do sistema operacional - B) `browser` — abre no navegador com interface completa - C) `standalone` — remove a barra de endereço mas mantém barra de status do SO - D) `minimal-ui` — exibe apenas controles básicos de navegação - E) `native` — emula completamente a experiência de app nativo
🔎 Ver resposta e comentário **✅ Resposta: C** **Comentário:** **`standalone`** é o modo mais usado em PWAs — remove a barra de endereço do navegador, dando experiência app-like, mas mantém a barra de status do SO (horário, bateria). `fullscreen` remove **toda** a UI (inclusive SO) e é usado em jogos. `browser` é o padrão sem experiência app-like. `minimal-ui` mantém controles básicos de navegação. `native` não é um valor válido do manifest.
--- ### Questão 7 (Certo/Errado — estilo IDECAN) *"SPA e PWA são conceitos equivalentes — uma SPA é necessariamente uma PWA, pois ambas dispensam o recarregamento de página e oferecem experiência similar a aplicativos nativos."*
🔎 Ver resposta e comentário **✅ Resposta: ERRADO** **Comentário:** SPA e PWA são conceitos **independentes e complementares**, não equivalentes. **SPA** é uma arquitetura de navegação — uma página HTML com roteamento no cliente via JavaScript. **PWA** é um conjunto de tecnologias (HTTPS + Service Worker + Manifest) que adiciona capacidades offline, instalação e notificações push. Uma SPA pode ser um PWA (Twitter Lite, por exemplo), mas não necessariamente. Uma MPA tradicional também pode ser um PWA se adicionar Service Worker e Manifest. São dimensões diferentes: SPA descreve *como a navegação funciona*; PWA descreve *quais capacidades a aplicação possui*.
--- ### Questão 8 (Certo/Errado) *"O evento `activate` do Service Worker é o momento recomendado para limpar caches de versões anteriores, pois nesta fase o SW já assumiu o controle das páginas e é seguro remover recursos que não serão mais usados."*
🔎 Ver resposta e comentário **✅ Resposta: CERTO** **Comentário:** Afirmação correta. O evento `activate` é disparado após o SW ser instalado e estar pronto para assumir o controle. É o momento ideal para remover caches de versões anteriores (ex: `meu-app-v1` quando a versão atual é `meu-app-v2`), garantindo que o espaço de armazenamento não seja desperdiçado com recursos obsoletos. O evento `install` (fase anterior) é para criar o novo cache com os arquivos da versão atual. Tentar deletar caches antigos no `install` pode causar problemas de concorrência com o SW anterior ainda em execução.
--- ## 📌 Resumo Visual — Comparativo Final ``` SPA PWA ┌──────────────────┐ ┌──────────────────┐ │ Uma página HTML │ │ HTTPS obrigatório│ │ Roteamento no JS │ │ Service Worker │ │ AJAX para dados │ │ Web App Manifest │ │ React/Vue/Angular│ │ Offline-first │ │ Desafio: SEO │ │ Instalável │ └──────────────────┘ └──────────────────┘ ↑ ↑ └──────────┬────────────────┘ │ Podem ser usados juntos (SPA + PWA) ou separadamente ``` --- ## 📚 Tabela de Referência Rápida | Conceito | Resumo | |---|---| | SPA | Uma página HTML + JS atualiza DOM via AJAX — sem recarregamento | | MPA | Cada navegação = nova requisição HTTP + HTML completo do servidor | | SEO no SPA | Desafiador (HTML inicial vazio) — solução: SSR com Next.js/Nuxt | | SSR | Servidor pré-renderiza HTML da SPA — combina SEO + experiência SPA | | Code Splitting | Divide bundle JS em chunks carregados sob demanda | | PWA | HTTPS + Service Worker + Web App Manifest | | Service Worker | Proxy de rede em thread separada, sem acesso ao DOM, só HTTPS | | SW — install | Pre-caching dos arquivos essenciais | | SW — activate | Limpeza de caches de versões antigas | | SW — fetch | Interceptação de requisições em operação normal | | Cache First | Cache → rede. Para assets estáticos. | | Network First | Rede → cache (fallback offline). Para dados dinâmicos. | | Stale While Revalidate | Cache imediato + atualiza em background. Para equilíbrio. | | manifest display | `standalone` = app-like (sem barra de endereço) | | PWA instalação | Via navegador, sem App Store / Play Store | | Workbox | Biblioteca Google que abstrai Service Worker e estratégias de cache | --- *Material elaborado com base no perfil de cobrança histórico da banca IDECAN (2006–2026).* *Última atualização: 2026*