jpeg

Attention over time

7-day rolling share of analyzed posts/comments mentioning this entity · 90 daily points ending 2026-10-15

Final complete day: 2026-10-15. Attention was 0.2% — this entity appeared in 5 of 2,852 analyzed posts/comments in the seven days ending that day (7 mentions).

Each point is a seven-day rolling window of complete UTC days; a point is comparable only when at least 100 analyzed posts or comments fall inside it. A day with no analyzed records counts as zero; missing coverage is marked and never shown as zero. The series ends at the latest complete analyzed day — it never extends into the current incomplete day. How attention is measured.

Recent mentions

1. 2026-10-14 06:40 UTCComment

   Client-side compression is a solid choice here, and plenty of image-heavy apps do exactly this. A few things that made it work well for me: 1. Resize first, format second. Capping the long edge at \~2048px with quality around 0.8 does most of the work. A 12 MP phone photo usually ends up at 300–600 KB as JPEG, so WebP vs JPEG matters much less than people think. 2. Don't assume WebP encoding works everywhere. Call canvas.toBlob(cb, 'image/webp', 0.8) and check blob.type in the callback. If the browser silently gave you a PNG instead, fall back to 'image/jpeg'. That covers older Safari without any user-agent sniffing. 3. Upload straight to R2 with presigned URLs so the file never touches your Next.js server. Still enforce a max size on that side (e.g. reject anything over 2 MB). Never trust the client completely. 4. On Expo, expo-image-manipulator does the same resize + compress before upload. 5. Bonus for a P2P marketplace: re-encoding through canvas strips EXIF data, including GPS. Otherwise sellers can leak their home location in listing photos. If you later want fancier variants (thumbnails, crops), look at an on-the-fly image transformation service instead of doing it in your serverless functions. Check current pricing, but small volumes are often free or very cheap.

2. 2026-10-13 09:00 UTCPost

   .co.uk/ and .co.uk/index.html appear different depending on route taken - So basically, im running my web server on AWS lightsail, i wrote my own https server code and URL ending in .co.uk/ and .co.uk/index.html both direct to /index.html but when i go to .co.uk/ it appears smaller than if i was to type .co.uk/index.html and i cant figure out why. I have done all the usual scanning whats listening to ports 443 and 80 and its just the webindex.js file im talking about, so there is nothing else getting in the way, i already disabled PM2 since i run a different server that monitors my apps servers and kicks them back up via ssh when they go down. Anyway, i checked the main things, i just cant understand why its serving the webpage smaller when routing via .co.uk/ and .co.uk/index.html is the correct size/scale. const https = require('https'); const fs = require('fs'); const path = require('path'); const WebSocket = require('ws'); const mysql = require('mysql'); const { v4: uuidv4 } = require('uuid'); const { format } = require('date-fns'); const http = require('http'); // Load SSL key and certificate const privateKey = fs.readFileSync( path.join(__dirname, 'newcerts/key.key'), 'utf8' ); const certificate = fs.readFileSync( path.join(__dirname, 'newcerts/certificate.crt'), 'utf8' ); const credentials = { key: privateKey, cert: certificate }; // Helper function to serve static files const serveFile = (res, filePath, contentType) => { fs.readFile(filePath, (err, data) => { if (err) { console.error(`Error loading file ${filePath}:`, err); res.writeHead(500, { 'Content-Type': 'text/plain' }); return res.end('Error loading file'); } res.writeHead(200, { 'Content-Type': contentType }); res.end(data); }); }; // Redirect HTTP traffic to HTTPS http.createServer((req, res) => { const host = req.headers.host || 'localhost'; const url = req.url || '/'; res.writeHead(301, { Location: ` }); res.end(); }).listen(80, () => { console.log('HTTP server running on port 80, redirecting to HTTPS.'); }); // HTTPS server const server = https.createServer(credentials, (req, res) => { let pathname; try { let requestUrl = req.url || '/'; // Remove multiple leading slashes requestUrl = requestUrl.replace(/^ \/ +/, '/'); // Parse the request URL safely pathname = new URL( requestUrl, ` || 'localhost'}` ).pathname; } catch (err) { console.warn('Rejected malformed request:', req.url); res.writeHead(400, { 'Content-Type': 'text/plain' }); res.end('Bad Request'); return; } // Redirect the root URL to the main homepage if (pathname === '/') { res.writeHead(301, { Location: '/index.html' }); res.end(); return; } // Serve the main homepage if (pathname === '/index.html') { const htmlPath = path.join(__dirname, 'index.html'); serveFile(res, htmlPath, 'text/html'); // Serve app-ads.txt } else if (pathname === '/app-ads.txt') { const adsTxtPath = path.join(__dirname, 'app-ads.txt'); serveFile(res, adsTxtPath, 'text/plain'); // Serve privacy policy } else if (pathname === '/privacypolicy.html') { const privacyPolicyPath = path.join( __dirname, 'privacypolicy.html' ); serveFile(res, privacyPolicyPath, 'text/html'); // Serve FAQ } else if (pathname === '/faq.html') { const faqPath = path.join(__dirname, 'faq.html'); serveFile(res, faqPath, 'text/html'); // Serve contact page } else if (pathname === '/contactus.html') { const contactPath = path.join(__dirname, 'contactus.html'); serveFile(res, contactPath, 'text/html'); // Serve how it works page } else if (pathname === '/howitworks.html') { const howItWorksPath = path.join(__dirname, 'howitworks.html'); serveFile(res, howItWorksPath, 'text/html'); // Serve advertise with us page } else if (pathname === '/advertisewithus.html') { const advertisePath = path.join( __dirname, 'advertisewithus.html' ); serveFile(res, advertisePath, 'text/html'); // Serve sitemap } else if (pathname === '/sitemap.xml') { const sitemapPath = path.join(__dirname, 'sitemap.xml'); serveFile(res, sitemapPath, 'application/xml'); // Serve robots.txt } else if (pathname === '/robots.txt') { const robotsPath = path.join(__dirname, 'robots.txt'); serveFile(res, robotsPath, 'text/plain'); // Serve JPG images } else if (pathname.toLowerCase().endsWith('.jpg')) { const imagePath = path.join( __dirname, pathname.replace(/^ \/ +/, '') ); serveFile(res, imagePath, 'image/jpeg'); // Handle unknown routes } else { res.writeHead(404, { 'Content-Type': 'text/plain' }); res.end('Not Found'); } }); // Start HTTPS server const port = process.env.PORT || 443; server.listen(port, () => { console.log(`Server running at });

3. 2026-10-12 14:21 UTCComment

   Worth noting the decoder is jxl-rs, a pure Rust implementation, which I suspect did a lot of the work in making the security case for a new codec in the renderer. Practically I'd treat it as one more `<picture>` source rather than an AVIF replacement: the Chrome post itself recommends testing both, with JXL most useful for high-fidelity, lossless, or progressive cases, and lossless JPEG recompression is the low-risk place to start for an existing photo library.

4. 2026-10-12 07:58 UTCComment

   I love the idea of JPEG XL and I'm already testing the savings vs an oxipng compression pass in a project that requires lossless images, but we have to admit that the name is so bad that it's hurting adoption and causing misunderstandings like this for anyone seeing it for the first time. Devs see "JPEG" and think of blocky compression artifacts. End users see "XL" and think about the bandwidth or storage requirements on their mobile device vs "normal JPEG". I really believe that the name has set adoption back years. If Apple was involved in the branding and called the format something like "Magic Pix Pro (.mpix)", it probably wouldn't have taken this much time to get where we are now.

5. 2026-10-11 23:02 UTCComment

   It's smaller than existing files... > It offers 30-50% better compression than JPEG, lossless compression, built-in HDR support, lossless JPEG transcoding, and more.