Auth User Super Fast — Login → dashboard in one round trip

​

Status per step (19/10/2026)

​

0. TL;DR

​

Table of contents

0. TL;DR
1. What happens today (traced and measured)
2. Target sequence
3. The plan, ranked by gain per effort
4. Rollout order and compatibility
5. How to measure before / after
6. Deliberately not in this plan
7. Files touched
8. Optional task — student cold load: the four ideas, evaluated

​

1. What happens today (traced and measured)

​

1.1 The sequence, file by file

login_screen.dart            ElevatedButton / onFieldSubmitted
  └─ LoginProvider.loginUser()                         login_provider.dart
       ├─ POST /auth/login                              (Turnstile token when the widget produced one)
       ├─ SecureStorage.saveToken()  →  TokenProvider.setToken()
       └─ AppService.authUserAndRole()                  app_service.dart  ← the SAME method as the F5 boot
            ├─ Future.wait([ initAppLanguage(), handleCompanyTheme() ])
            │     └─ GET /platform/theme?company_id=1   (already fetched at boot, before the form was shown)
            ├─ helper.isMobileDevice(DeviceInfoPlugin)  (platform channel; already known from boot)
            ├─ GET /auth/user                           slim payload (Update 125), ≤ 30 SQL queries
            └─ handleUserRole() → handleStudentRole()
                  ├─ fires GET /dashboard/user/{id}/progress   (statistics, for the activity chart)
                  ├─ fan-out into 7 providers (cards, exams, lessons, certificates, cart badge, bell)
                  └─ await statistics   ← the spinner waits for this too
       notifyListeners()  →  GoRouter refreshListenable  →  redirectionHandler()  →  initHomeLocation
  isLoading = false  (button spinner stops only here)

student_statefulshell.dart   Selector5 → initAllTrainingWithProgress / initializeValidatedLessons
overview_screen.dart         Selector4 → stat cards, Continue learning, GetStarted, activity chart
leaderboard_card_widget.dart postFrame  →  GET /progress/leaderboard?limit=10   (after first paint, OK)
student_appbar_widget.dart   first login only: language dialog (400 ms delay) + nav tour (by design)

​

1.2 Every HTTP request between the click and the dashboard

​

1.3 Measured cost of one round trip (19/10/2026)

 #1 OPTIONS login        150
 #2 POST login           170 + bcrypt 250 (+ Turnstile 100–300 in prod)   =  420–720
 #3 OPTIONS theme        150
 #4 GET theme            180
 #5 OPTIONS auth/user    130
 #6 GET auth/user        170 + ~28 queries ≈ 60–150                        =  230–320
 #7 OPTIONS progress     150
 #8 GET progress         180 + 4 grouped queries                           ≈  200
                                                                            ─────────────
 before the dashboard route is built                                        ≈ 1 610–2 070 ms
 + shell / dashboard build, then leaderboard (2 more trips, after paint)

​

1.4 Small things that are fine (don’t spend time on them)

• SecureStorage.saveToken() on web (WebCrypto + localStorage): a few ms.
• ThemeProvider.setPrimaryColor() → two SharedPreferences writes: a few ms.
• User.fromJson + the student fan-out on a ~6–20 KB payload: a few ms on the UI thread.
• The dashboard Selector4 / shell Selector5 recompute progress on every build; with card-level progress from the backend this is a loop over 2–10 items, negligible.
• The first-login language dialog + nav tour intentionally delay the dashboard by 400 ms once per user; not a performance bug.

​

1.5 The app’s first load, before the login form (measured 19/10/2026)

• Flutter web downloads every font listed in FontManifest.json before the first frame. initializeEngineServices awaits Future.wait([initializeRenderer, _downloadAssetFonts]), and loadAssetFonts fetches all families of the manifest in parallel (canvaskit/fonts.dart). There is no lazy loading per page: the login page pays for every font the whole app declares, and so does the admin dashboard. The manifest is the app’s pubspec.yaml fonts: plus every font declared by a dependency (syncfusion_flutter_pdfviewer adds RobotoMono, font_awesome_flutter three files, syncfusion_flutter_datagrid two, cupertino_icons one).
• Poppins is 6 × ~153 KB because the files carry Devanagari. Poppins-Regular.ttf has 1 059 glyphs for 471 code points: 308 Latin, 94 Devanagari, 69 other; the Devanagari conjunct glyphs are most of the file. A Latin + Latin-Extended + punctuation subset of the same file is 25 KB (measured with pyftsubset, kerning kept), 14 KB once Brotli-compressed. Arabic is not in Poppins today either (the engine already falls back to Noto Sans Arabic from gstatic for ar).
• The frontend vhost serves font/ttf uncompressed (content-encoding absent on every font, while .js / .json arrive as Brotli): the nginx brotli_types / gzip_types list of the Plesk vhost does not include font types. Brotli alone would take Poppins-Regular from 158 KB to 63 KB, MaterialIcons from 44 to 21 KB, RobotoMono from 87 to 48 KB. Fonts also carry no cache-control header (the warm run still served them from the heuristic cache).
• Roboto (62 KB) comes from gstatic on every cold load because the engine always downloads its default fallback unless the manifest declares a Roboto family (loadAssetFonts, loadedRoboto).
• Any emoji on screen triggers a 709 KB download (Noto Color Emoji subset 0 from gstatic, font_fallback_data.dart). The staff first-login tour strings carry 👋 / 👉 (tourWelcomeTitle, tourClickNextHint), so the admin dashboard’s first paint after a first login pulls 709 KB that the whole dashboard does not otherwise need; the AI-assistant welcome (aiAssistantWelcome) does the same in the course player.
• Two more things on the boot path are not fonts but sit in the same waterfall: on web app.dart renders SizedBox.shrink() while authResult == null, so after the HTML loader is removed the user sees a white page for the whole theme round trip (0.55 s cold, 0.45 s warm; the phone shows a spinner); and the login page then downloads a 5120 × 2880 JPEG for a panel of ~800 px and a 979 × 512 PNG for a 24 px flag.

​

2. Target sequence

login_screen.dart  →  LoginProvider.loginUser()
  ├─ OPTIONS /auth/login          only the FIRST time in 2 h (preflight cached, step 1)
  ├─ POST /auth/login             → { token, two_factor_enabled, user: <same shape as GET /auth/user> }
  │                                  server: Turnstile verify overlapped with bcrypt (step 5)
  ├─ saveToken / setToken
  └─ AppService.applyAuthUser(user)   role switch + fan-out, NO theme / device / language work (step 2)
       └─ fires GET /dashboard/user/{id}/progress, NOT awaited (step 3)
  notifyListeners() → redirect → dashboard builds from the providers (all data already there)

after first paint, in parallel:  statistics (chart), leaderboard, images

​

3. The plan, ranked by gain per effort

// config/cors.php
'max_age' => 7200,

# --- existing block, keep as is (CanvasKit images, Update 19) ---
location ^~ /storage/ {
    add_header Access-Control-Allow-Origin "*" always;
    try_files $uri =404;
}

# --- CORS preflights answered by nginx: no Apache hop, no Laravel boot ---
# `if` in server context cannot carry add_header, so route the request to a
# named internal location that can. Nothing else changes for non-OPTIONS requests
# (Plesk's own proxy location to Apache keeps handling them).
if ($request_method = OPTIONS) {
    rewrite ^ /__cors_preflight last;
}
location = /__cors_preflight {
    internal;
    add_header Access-Control-Allow-Origin  $http_origin always;   # same as Laravel: origin reflected
    add_header Access-Control-Allow-Credentials "true" always;
    add_header Access-Control-Allow-Methods "GET, POST, PUT, PATCH, DELETE, OPTIONS" always;
    add_header Access-Control-Allow-Headers "Authorization, Content-Type, Accept, Accept-Language, X-Requested-With" always;
    add_header Access-Control-Max-Age 7200 always;
    add_header Vary "Origin, Access-Control-Request-Method, Access-Control-Request-Headers" always;
    add_header Content-Length 0 always;
    return 204;
}

// app_service.dart (sketch)
bool _bootstrapped = false;

/// Language, company theme, device class, onboarding flag: once per app lifetime.
Future<void> bootstrapOnce(BuildContext context) async {
  if (_bootstrapped) return;
  _bootstrapped = true;
  await Future.wait([initAppLanguage(), handleCompanyTheme(context: context)]);
  isMobileDevice = await helper.isMobileDevice(DeviceInfoPlugin());
  initOnboarding(isMobileDevice);
}

/// Cold boot / F5 (app.dart) and sign-out: unchanged behavior.
Future<bool> authUserAndRole(BuildContext context) async {
  await bootstrapOnce(context);
  final token = context.read<TokenProvider>().token;
  if (token == null) { authUser = null; notifyListeners(); return true; }
  try {
    final user = await apiClient.authUser();
    if (context.mounted) await applyAuthUser(context, user);
  } catch (error, stacktrace) { debugPrint('$error'); debugPrint('$stacktrace'); }
  return true;
}

/// Everything that depends on WHO is logged in. Also the target of step 4.
Future<void> applyAuthUser(BuildContext context, User? user) async {
  authUser = user;
  context.read<UserProvider>().updateUser(user);
  // restricted roles on mobile: the existing block, unchanged
  // ...
  await handleUserRole(context, user!, isMobileDevice);
  notifyListeners(); // → GoRouter refreshListenable → redirectionHandler → initHomeLocation
}

$token = $user->createToken('Personal Access Token')->plainTextToken;

// Same relations auth_user() loads, same builder: identical shape to GET /auth/user.
$user->load(['image', 'company.companyImage', 'role.permissions']);

return response()->json([
    'error'              => false,
    'message'            => trans('messages.login_success'),
    'token'              => $token,
    'two_factor_enabled' => (bool) $user->two_factor_enabled,
    'user'               => app(AuthUserPayloadService::class)->build($user),
], 200);

pip3 install --target /tmp/pyft fonttools brotli      # tool only, not a project dependency
cd LMS_Frontend/assets/fonts/poppins
for w in Light Regular Medium SemiBold Bold ExtraBold; do
  PYTHONPATH=/tmp/pyft python3 -m fontTools.subset "Poppins-$w.ttf" \
    --unicodes="U+0000-024F,U+02BB-02BC,U+02C6,U+02DA,U+02DC,U+2000-206F,U+20A0-20CF,U+2122,U+2190-2199,U+2212,U+2215,U+FEFF,U+FFFD" \
    --layout-features='*' --name-IDs='*' --notdef-outline --output-file="Poppins-$w.ttf"
done

# Fonts arrive as font/ttf and font/otf today, uncompressed; .js/.json are already Brotli.
brotli_types font/ttf font/otf application/font-sfnt application/x-font-ttf application/octet-stream;
gzip_types   font/ttf font/otf application/font-sfnt application/x-font-ttf application/octet-stream;
# Optional: the font files only change on a deploy that also changes their bytes.
location ~* ^/assets/.*\.(ttf|otf)$ { expires 7d; add_header Cache-Control "public"; }

​

3.1 Optional: paint the dashboard before the login response lands

​

4. Rollout order and compatibility

1. Step 1 (CORS max_age + nginx preflight block): no app change. 1a is a backend deploy; 1b is pasted into the Plesk nginx directives of backend-test first, measured, then dev and prod. Preflight responses are cached per browser, so there is nothing to invalidate; if it ever has to be rolled back (remove the block, or max_age back to 0), old cache entries expire within 2 h.
2. Steps 2 + 3 (frontend): work with any backend, web and mobile. Ship as one Update in major_code_updates.md with the before/after numbers of §5.
3. Step 4: backend first (the extra user key is ignored by current app builds), then the frontend (which falls back to GET /auth/user when user is missing, so a stale backend keeps working). The docs page follows the backend commit.
4. Step 5 items are independent; do 5.1 (opcache / optimize) first, it is the biggest and needs no code.

​

5. How to measure before / after

• the count of rows between auth/login and the first dashboard image (today 8 before the route, target 1–2);
• the Waterfall column: the gap from the POST auth/login start to the GET progress/leaderboard start is “click → dashboard built”. Record it 3 times, take the median.

B=https://backend-test.theteam.com.tn/api; O=http://localhost:5000
F='code=%{http_code} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n'
for i in 1 2 3 4 5; do curl -s -o /dev/null -w "$F" -X OPTIONS -H "Origin: $O" \
  -H "Access-Control-Request-Method: GET" -H "Access-Control-Request-Headers: authorization,content-type" "$B/auth/user"; done
for i in 1 2 3 4 5; do curl -s -o /dev/null -w "$F" -H "Origin: $O" -H "Accept: application/json" "$B/platform/theme?company_id=1"; done

​

5.1 Before / after, phase by phase

​

6. Deliberately not in this plan

• Flutter renderer / wasm: excluded by the user for now. Nothing above depends on it.
• The Dart bundle (main.dart.js, 12.4 MB raw / 3.3 MB Brotli) and its 0.5 s compile. The only app-side lever is code splitting with deferred imports (import '…' deferred as): the student shell would stop loading the admin / instructor / content-manager / super-admin pages, the Syncfusion grids and the editors on first load. It is a routing refactor with its own test pass, so it is a separate plan, not a step here. Numbers to decide with: the bundle is 1.05 s of the 3.7 s cold load on a fast link and 5.1 s of the 8.6 s at 8 Mbit/s.
• Caching the login payload in localStorage for F5 boots (the old §7.9 idea): a different path (cold boot, not login) and a stale-data risk; revisit only if the F5 path is still slow after steps 1 and 5.
• A service worker / HTTP cache for API JSON: the payload is per-user and changes with every lesson; not worth the invalidation rules.
• Lowering bcrypt rounds: listed in 5.5 as a decision, not a recommendation.
• Removing Turnstile from login: no; 5.2 hides its cost instead.
• Skeleton dashboard before the response (§3.1): would reintroduce pop-in.

​

7. Files touched

​

8. Optional task — student cold load: the four ideas, evaluated

​

8.1 “Use fewer fonts on the login / dashboard” — partly yes, after step 6a

• Per-page font loading does not exist on Flutter web: whatever is in the manifest is downloaded before the first frame (§1.5). The only “later” mechanism is FontLoader for files kept out of fonts:; at 14 KB per subset weight (after 6a) it is not worth the reflow when the late weight arrives. So “fewer fonts for the login page” has to mean fewer fonts for the app.
• Drop Light (300) and ExtraBold (800) altogether: 5 call sites each in the whole app, none on the login page or the dashboard. Replace them by 400 / 700 at those 10 sites (Flutter would snap to the nearest weight anyway) and delete the two files + their pubspec.yaml lines. Saves 2 requests and ~28 KB compressed after 6a (~300 KB today, before the subset).
• Keep 400 / 500 / 600 / 700: 1 469 call sites; the dashboard uses all four.
• Drop cupertino_icons: CupertinoIcons. has 0 uses in lib/; the package is only there from the Flutter template, and it puts CupertinoIcons.ttf (3 KB) into the manifest. Remove the dependency: 1 request fewer. (flutter_quill / Syncfusion do not declare it.)
• FontAwesomeBrands carries 2 icons (facebookF, instagram, 1.9 KB file): replacing them with two tiny SVG assets removes 1 request. Marginal; do it only if the social links move anyway.
• Result on top of step 6: the font phase goes from 9 requests / ~190 KB to 6 requests / ~150 KB (Poppins 400–700, MaterialIcons, FA solid + regular, Syncfusion grid icons, RobotoMono, and Roboto unless 6d). ≈ 0.05 s on a fast link, ≈ 0.1 s at 8 Mbit/s. Worth doing because it is also less to maintain, not because it is big.

​

8.2 “Ignore the theme endpoint on the login page, consume it after login” — no as stated, yes as “paint first, theme second”

• The login page is the branded surface: GET /platform/theme gives it the two colors, the right-side image (auth_page_image), remove_auth_image, the logo and the company name. Fetching it only after login would show every white-label company the default green login on every visit. Not recommended.
• What gives the same speed without losing branding, in this order:
  1. Cached theme (step 8): every visit after the first paints the login immediately from SharedPreferences, the call refreshes it in the background. This already removes the 0.55 s (cold) / 0.45 s (warm) wait on every return visit.
  2. First visit: render with the built-in defaults and do not wait either. handleCompanyTheme() already falls back to 119B78 / D48941 and the local authBackground.jpg; make authUserAndRole() resolve the login route before the theme call returns and let ThemeProvider.notifyListeners() recolor the page when it lands (one color flip, ~0.5 s, first visit only). The dashboard never sees this: by the time the user has typed a password the theme is in.
  3. Step 1b on the backend vhost makes that call’s preflight (376 of the 545 ms) disappear anyway, and step 2 stops the app from calling it a second time right after login.
• Net: the theme is off the critical path in every scenario; the only visible trade is a one-time color flip on a brand-new browser. If that flip is unacceptable for a given tenant, keep the current blocking behavior for the first visit only (cache miss) and you still win on every later visit.

​

8.3 “Switch the icons with other ones” — don’t

• Icon fonts are tree-shaken by the release build, so they are already small: MaterialIcons 44 KB (21 KB Brotli), Font Awesome solid + regular + brands 23 KB (~12 KB), Cupertino 3 KB, Syncfusion grid icons 3.6 KB. **74 KB and 7 requests today, ~40 KB and 5 requests after 6b
  • 8.1.**
• Switching them to SVG widgets (what heroicons already is) would trade those ~40 KB for an SVG parse per icon at build time and a code change at ~290 FontAwesomeIcons.* call sites (fa_compat.dart). No measurable gain on the cold load; a real risk of regressions. The cheap wins are the two removals in 8.1 and the compression in 6b.

​

8.4 “Compress the default login right-side image” — yes, both of them

​

8.5 Two small extras in the same waterfall

• Cropper.js CSS + JS from cdnjs on every page load (13 KB, a third origin with its own DNS + TLS, defer): it is only used by the image cropper. Load it on demand from the widget that needs it (inject the <script> when the cropper opens) and drop the two <link> / <script> tags from web/index.html. ≈ 0.1 s of parallel work and one origin fewer on the cold load; nothing on warm loads.
• AssetManifest.bin.json (22 KB) is fetched after the theme call, i.e. on the critical path of the first image. Nothing to change in the app (the engine requests it on the first rootBundle use); it just disappears behind the fonts once step 8 removes the theme wait.

​

8.6 What all of this adds up to (student, cold, fast link)